https://remmina.org/
Also 100% FOSS, but more advanced.
Show HN: P2P remote desktop – an alternative to TeamViewer / AnyDesk
41–50 of 100 posts
Re: Show HN: P2P remote desktop – an alternative to TeamViewer / AnyDesk
#42Re. remote desktop stability, not sure if my experience as someone censored by the GFW makes any sense, but when my RDP to oversea Windows host become unstable, Jump Desktop gives me fast and stable connection, and for free. Their program is lightweight and fast too.
Re: Show HN: P2P remote desktop – an alternative to TeamViewer / AnyDesk
#43Do you have any plans in case your software becomes famous to scammers?
TeamViewer / Anydesk (and the rest) regularly take actions to disable accounts of fake call (scam) centers.
For examples of this check out the youtube channels of:
Jim Browning / Kitboga / Perogi and lots more
Re: Show HN: P2P remote desktop – an alternative to TeamViewer / AnyDesk
#44Re: Show HN: P2P remote desktop – an alternative to TeamViewer / AnyDesk
#45@mp85, I don't think your MIT license is compatible with AForge.NET's LGPL license. I'm not a lawyer, but I'm guessing your license should also become LGPL.
The LGPL is compatible with pretty much all licenses, even proprietary ones. Also the MIT license is GPL compatible and compatible with pretty much all licenses too. https://www.gnu.org/licenses/license-list.en.html#Expat
He's directly including (not linking) LGPL code.
Re: Show HN: P2P remote desktop – an alternative to TeamViewer / AnyDesk
#46What method are you using for screen capture?
Re: Show HN: P2P remote desktop – an alternative to TeamViewer / AnyDesk
#47https://remmina.org/ Also 100% FOSS, but more advanced.
Is this just a client or is it also a server? It's not clear from their site...
Re: Show HN: P2P remote desktop – an alternative to TeamViewer / AnyDesk
#48Earlier quoted context omitted.
I think the difference is that Teamviewer/AnyDesk is intended mostly for corporate usage. Their software is optimised for images that are mostly static, letting them get away with much less bandwidth without making text blurry or illegible. Standard H.264/H.265 encoded video needs sharpening and extra filters to be both low bandwidth and legible in many cases. Parsec and friends use more bandwidth and hardware resour…
>Microsoft's RDP solution in excellent on all fronts, though. Is it? Even on gigabit LAN there's a noticeable amount of latency. For web surfing it's mostly passable, but for text/code editing it's very annoying.
Just to add to the anecdotes.. I regularly run RDP over VPNs and web gateways all over WiFi and only occasionally feel a little bit of lag, otherwise it's so fast I forget it's not my local device. I largely use CLI's, IDE's, Office, web browsing, and often tell myself off for watching YouTube videos over the RDP connection instead of locally.
Re: Show HN: P2P remote desktop – an alternative to TeamViewer / AnyDesk
#49This 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…
What does the open source angle add to compete with the existing offerings? From what I can tell they are free for personal use and businesses pay, as you suggest. I’m not too familiar with these products.
These tools behave like trojans, allowing complete control over a machine. Why would anyone want to run something like that without being able to check for malicious code is beyond my comprehension.
Re: Show HN: P2P remote desktop – an alternative to TeamViewer / AnyDesk
#50The 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 towards you if you were to try and connect now.
That is, you need to know the overloading pattern and then also time stuff correctly.
For that reason you will need a rendezvous server and it's also the best to let the server drive the whole process (as opposed to what STUN-based setups do, which is to let clients do it).
PS. In my past life I made a P2P VPN called Hamachi, which used all this stuff very extensively.