Show HN: P2P remote desktop – an alternative to TeamViewer / AnyDesk

Post by jeroenhd » Wed, Dec 08, 2021, 11:27 PM UTC

karteum wrote: post #70

jeroenhd wrote: post #5

This is one thing I'm surprised the open source community hasn't developed a popular alternative for: Teamviewer. The core idea is simple: a video stream from one computer to another, with mouse and keyboard controls sent the other way. Connection negotiation can be done Magic Wormhole style, via basic STUN, encryption can be done in a number of ways. Add some clipboard and P2P file transfer features and you've got m…

> This is one thing I'm surprised the open source community hasn't developed a popular alternative for: Teamviewer. That's because it's not only a matter of software but also a matter of service (STUN is not enough, TURN is required in many situations. And someone has to pay for the servers and bandwidth...). If IPv6 had succeded instead of IPv4+NAT, maybe the situation would be different. In terms of software, the o…

Post by eliaspro » Wed, Dec 08, 2021, 11:32 PM UTC

gregors wrote: post #76

apankrat wrote: post #50

The NAT traversal logic here is really basic and won't hold up well in practice. A good chunk of NAT devices will pick external port based on [src ip/port, dst ip/port] combo, not just [src ip/port], so "WAN IP/port" you get from STUN will get you nothing useful. Not by itself. STUNs should be used for discovering the pattern in NAT port overloading logic and then using it to predict which port your peer will use tow…

I loved Hamachi! What do you suggest as a learning resource for things like this? The STUN RFC's? The Stevens' networking book?

Post by MayeulC » Thu, Dec 09, 2021, 2:04 PM UTC

Shish2k wrote: post #59

apankrat wrote: post #50

The NAT traversal logic here is really basic and won't hold up well in practice. A good chunk of NAT devices will pick external port based on [src ip/port, dst ip/port] combo, not just [src ip/port], so "WAN IP/port" you get from STUN will get you nothing useful. Not by itself. STUNs should be used for discovering the pattern in NAT port overloading logic and then using it to predict which port your peer will use tow…

Anyone know if there are any open-source libraries which wrap this all into a usable `get_{tcp,udp}_connection(peer_id)` API, preferably with fallback to a relay server? I feel like there really should be, but nearly all the tools I’ve seen with this functionality are closed source, and the few open-source things all do their own custom logic rather than a shared library :/

Post by trenchgun » Thu, Dec 09, 2021, 4:07 PM UTC

apankrat wrote: post #50

The NAT traversal logic here is really basic and won't hold up well in practice. A good chunk of NAT devices will pick external port based on [src ip/port, dst ip/port] combo, not just [src ip/port], so "WAN IP/port" you get from STUN will get you nothing useful. Not by itself. STUNs should be used for discovering the pattern in NAT port overloading logic and then using it to predict which port your peer will use tow…

Post by crookshanked » Fri, Dec 10, 2021, 5:18 PM UTC

apankrat wrote: post #50

The NAT traversal logic here is really basic and won't hold up well in practice. A good chunk of NAT devices will pick external port based on [src ip/port, dst ip/port] combo, not just [src ip/port], so "WAN IP/port" you get from STUN will get you nothing useful. Not by itself. STUNs should be used for discovering the pattern in NAT port overloading logic and then using it to predict which port your peer will use tow…