Comment by catapart
2 years ago
Ah, nice! That looks like a method I had tried, for sure. My first setup was to use .NET core to build an API that registered users with session variables and broadcast that session to new users. It required a "host" because they initiated the session and then all other users were given the host's address to negotiate their P2P connection.
That all worked fine but it required a token api, and then having to choose between "polling" and "websockets"; not a particularly appealing choice for me. So TURN servers seemed to be like the ticket, but I just couldn't find someone to say "this is what data a TURN server receives; this is how it determines its response; this is what the response data looks like". Without that, I was having a very hard time building my own TURN server. The only option seemed to be "use COTURN", which is not something I'm interested in. Not because I think it doesn't work, but because I haven't ripped it apart to know how to fix it if something goes wrong. As this is a side-project, I have the luxury of forcing myself to deeply learn each part of the data flow, so it doesn't make much sense to offload something I don't totally understand to someone's library (conversely, I've written an IndexedDB handler, so I use the Dexie library because if it completely falls apart in novel ways, I can still troubleshoot it). So I figured I would wait (it's been a couple of years now), and if no one got around to dumbing it down, I would start inspecting the data flow, myself, and try to replicate whatever COTURN is doing.
So if you can shed any light on how to make a TURN server, I am ALL ears! I do think WebRTC is the way to go so, while I appreciate a suggestion for an alternative (and one that you personally use is great, but one that you personally build AND use is pretty much the gold standards for reccs, so I really do appreciate it!), I don't think it's helpful for my intentions. My project is also web-based (first), so while I'm not averse to a wasm library implementation of TCP connections (mad stuff recently with the curl support!), it's a bridge too far, to start with. In the mean time - like you said - I'm not concerned about the cost of a TURN server. I know that most apps can get by on free-tier cloud hosting limits, when you're talking about those little chirps of data. So I'm happy to build and pay for what it takes, I just honestly don't know how to do it.
> [...] I don't think it's helpful for my intentions. My project is also web-based (first)
Yes, then it's a no-go. No excuses needed.
WebRTC is the only way to reasonably do p2p on the web. This is because of the lack of "raw" sockets and their options (just regular TCP/UDP with SO_REUSEPORT).
> So if you can shed any light on how to make a TURN server, I am ALL ears!
You'd know better in a few minutes of reading the docs, sorry. I will say, pay attention to the requirements - for instance, listening on arbitrary ports, getting the "real" port from the client, even stateful connections etc, aren't always possible on cloud services (the more "managed" the marketing, the more restricted).
> Not because I think it doesn't work, but because I haven't ripped it apart to know how to fix it if something goes wrong. As this is a side-project, I have the luxury of forcing myself to deeply learn each part of the data flow, so it doesn't make much sense to offload something I don't totally understand to someone's library
I empathize deeply with this. In fact, that's the main reason why I built rdv. WebRTC in particular is, imo, a nasty piece of over-engineering. It basically throws together a bunch of separate "protocols" into one. It has way, way too many knobs, and many things are stateful. If you do go down the route of reimplementing even a subset of WebRTC I recommend getting an insurance for your keyboard, one that covers physical violence, (but if you do, I would be very curious about your learnings).
Finally, my words of wisdom would be to avoid p2p if you have the luxury of having a small amount of messages. Just running a simple "relay" of encrypted messages is reliable and cheap. Users are still protected by e2ee.