Why so many servers?

Ian Bicking ian at ianbicking.org
Sat May 2 17:02:41 UTC 2020


I've done a fair amount with WebRTC. It's not a great experience.
Reliability of point-to-point communication is not awesome, and while
you can get something that often works pretty easily, it's very hard
to get something that works reliably enough to be a pleasant
experience. The successful companies like Zoom have to take on the
entire vertical stack to make things actually work. People who build
p2p stuff on WebRTC also report very disappointing experiences, like
you can get as far as a demo and no further. You also need TURN
servers to make anything reliable, and hosting a proxying server is
hard due to abuse. STUN doesn't accomplish much, and I don't think it
handles all the hole punching and other modern things required to
connect directly to another computer.

It feels like what you want is the p2p sort of stuff, but most of it
is not realtime, it's more storage-oriented.

You might also find IndieWeb interesting: https://indieweb.org/ – not
exactly about this topic, but people that share some similar interest
in DIY tech.

Technically Urbit tries to create a p2p networking system based on
stable but portable identities. The implementation is absurd, but I
wish I knew who else exactly was trying it. I guess predictably the
p2p community is fractured and hard to understand.

On Fri, May 1, 2020 at 11:30 PM Joe Nelson <joe at begriffs.com> wrote:
>
> I've been thinking about remote pair programming, and am wondering why
> I'm conditioned to communicate through third-party servers on the
> internet?  For instance, to do a voice chat I would typically set up a
> Murmur server and then I and my programming partner would connect our
> Mumble clients to it. Why don't our computers talk directly to one
> another instead?
>
> Same thing for screen sharing. A shared tmux session on the frostbyte
> server still requires the server. What if local code editors on two
> people's computers could do p2p collaborative editing? The closest I've
> seen is VSCode's Live Share [0] feature. Looks pretty cool, although I
> think it still hooks into a third-party Microsoft server.
>
> Maybe the root problem is that many people operate in a local area
> network that doesn't have NAT configured to expose a listening port from
> a machine to the outside world. I think we just got used to that
> situation, and even when we control our own home networks we don't take
> the time to configure the router. On my own Mikrotik router, port
> mapping [1] isn't very hard. (Or maybe people do this all the time and
> it's just me who is catching on...)
>
> For restrictive networks there appear to be two techniques to punch a
> hole through the router, and they both require a server in the outside
> world. The first is STUN, where it appears that the interested parties
> talk to the STUN server just to set up communication, and it determines
> what their public IP and ephemeral ports are and lets them take it from
> there. That technique won't work in some situations (which?), so there's
> another approach called TURN, where all communication goes through a
> relay. Then there's a test called ICE [2] that determines which
> technique you need to use.
>
> As an interesting experiment, I'm wondering if anyone wants to try
> ICE/STUN with me and see if we can open a direct TCP connection between
> our computers? We could do a basic chat using netcat [3]. We could use a
> pre-existing public STUN server [4]. (Or just configure our routers to
> set up the NAT.)
>
> As a final note, I believe that the Jitsi Meet instance [5] Jes shared
> uses WebRTC which establishes direct connections between chat
> participants through a web server. In an ideal world I wouldn't need any
> server, but could use a native chat application and "call" another
> person directly with their IP address.
>
> Anybody have suggestions for more cool p2p software?
>
> 0: https://visualstudio.microsoft.com/services/live-share/
> 1: https://wiki.mikrotik.com/wiki/Manual:IP/Firewall/NAT#Port_mapping.2Fforwarding
> 2: https://en.wikipedia.org/wiki/Interactive_Connectivity_Establishment
> 3: http://man.openbsd.org/nc#CLIENT/SERVER_MODEL
> 4: stun.stunprotocol.org powered by http://www.stunprotocol.org/
> 5: https://cafe.cyberia.club/



-- 
Ian Bicking  |  http://ianbicking.org


More information about the Friends mailing list