Why so many servers?

Forest Johnson forest.n.johnson at gmail.com
Sat May 2 18:41:24 UTC 2020


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?

I think there are two reasons. First of all, we can't discount the corporate
influence on technology and the internet. Servers are great for business.
You can't make money on a peer to peer product very easily.
Servers are also great for authority and having power over other people.
I think servers are the most pervasive and profound power structures
that exist in our society today.

The second reason being, servers are how everything started, and it's
simply legacy being carried forward out of habit, necessity, and laziness.

> 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...)

I think most non-technical people don't know or care about port mapping.
Port mapping is supported by pretty much every router but no product
requires the user to use it. Because any product that requires the user
to learn how to do a new thing will fail as soon as someone introduces
a competing product which doesn't require that. So all of the p2p
software that exists today (video games, voice and video chat, etc)
uses a server to establish an initial connection between two peers,
like WebRTC / STUN.

> 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.

Just to point out, this is not for restrictive networks, this is basically for
all networks behind a NAT. Which is pretty much ***all networks** these
days (except for public facing web servers.)

> 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.)

I would do this! I was meaning to start developing and prototyping a
simple p2p VPN soon. All of the the peer to peer VPNs that I have
seen require one of the nodes to have a public IP address.  I was going
to see if I could build a peer to peer VPN that uses STUN and works even
if all peers are behind a NAT. Getting a basic socket working would
certainly be a requirement for that !

> 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.

I don't think that's possible unless one person has a public IP
(no NAT). There has to be some sort of session establishment
mechanism, otherwise the router being connected to wont know
which LAN address to forward the connect packet to.

That doesn't mean there has to be a server, though.
Some peer to peer software uses things like distributed
hash tables, blockchains, etc to help coordinate connection
establishment without a server.


> Anybody have suggestions for more cool p2p software?

I don't think you can talk about p2p in 2020 without talking about IPFS.
I really like the ideas behind IPFS and I want to build software using it.

To make it even better, the IPFS project made the decision to split
a large part of their code base into a separate project called libp2p.
Because IPFS has so much p2p-focused code, and that code is
historically finicky / tricky to write, they decided to invest in
creating a solid, modern library as a foundation for their application code.

https://ipfs.io/
https://libp2p.io/

I was planning on using the go language version of libp2p to
build my p2p signaling server and p2p VPN software.

Also, while bitcoin is one of the most famous pieces of p2p
software, I think its dusty and under-appreciated cousin
namecoin is just as cool. I wrote a long blog post about
how to use electrum-nmc to register a .bit domain name:

https://sequentialread.com/how-to-register-a-namecoin-bit-domain-with-electrum-nmc/

They even fixed the main usability issue I highlighted in  the article
in the newest version of electrum-nmc!


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/


More information about the Friends mailing list