Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.comp.os.windows-10 > #186429 > unrolled thread
| Started by | Fokke Nauta <fnauta@solfon.nl> |
|---|---|
| First post | 2025-08-01 16:11 +0200 |
| Last post | 2025-08-14 16:00 +0200 |
| Articles | 20 on this page of 113 — 20 participants |
Back to article view | Back to alt.comp.os.windows-10
Alternative for remote desktop connection Fokke Nauta <fnauta@solfon.nl> - 2025-08-01 16:11 +0200
Re: Alternative for remote desktop connection "Alan K." <alan@invalid.com> - 2025-08-01 10:28 -0400
Re: Alternative for remote desktop connection "J. P. Gilliver" <G6JPG@255soft.uk> - 2025-08-01 18:19 +0100
Re: Alternative for remote desktop connection VanguardLH <V@nguard.LH> - 2025-08-01 12:33 -0500
Re: Alternative for remote desktop connection "Alan K." <alan@invalid.com> - 2025-08-01 13:49 -0400
Re: Alternative for remote desktop connection "J. P. Gilliver" <G6JPG@255soft.uk> - 2025-08-01 21:11 +0100
Re: Alternative for remote desktop connection NY <me@privacy.net> - 2025-08-02 16:29 +0100
Re: Alternative for remote desktop connection "J. P. Gilliver" <G6JPG@255soft.uk> - 2025-08-02 18:26 +0100
Re: Alternative for remote desktop connection Fokke Nauta <fnauta@solfon.nl> - 2025-08-01 20:45 +0200
Re: Alternative for remote desktop connection "s|b" <me@privacy.invalid> - 2025-08-02 15:58 +0200
Re: Alternative for remote desktop connection Fokke Nauta <fnauta@solfon.nl> - 2025-08-02 16:35 +0200
Re: Alternative for remote desktop connection Graham J <nobody@nowhere.co.uk> - 2025-08-01 16:43 +0100
Re: Alternative for remote desktop connection Fokke Nauta <fnauta@solfon.nl> - 2025-08-01 20:47 +0200
Re: Alternative for remote desktop connection T <T@invalid.invalid> - 2025-08-01 09:02 -0700
Re: Alternative for remote desktop connection T <T@invalid.invalid> - 2025-08-01 09:13 -0700
Re: Alternative for remote desktop connection "s|b" <me@privacy.invalid> - 2025-08-01 18:41 +0200
Re: Alternative for remote desktop connection Fokke Nauta <fnauta@solfon.nl> - 2025-08-01 20:49 +0200
Re: Alternative for remote desktop connection VanguardLH <V@nguard.LH> - 2025-08-01 12:06 -0500
Re: Alternative for remote desktop connection Fokke Nauta <fnauta@solfon.nl> - 2025-08-01 20:54 +0200
Re: Alternative for remote desktop connection VanguardLH <V@nguard.LH> - 2025-08-01 15:26 -0500
Re: Alternative for remote desktop connection Michael Logies <logies@t-online.de> - 2025-08-06 15:58 +0200
Re: Alternative for remote desktop connection "s|b" <me@privacy.invalid> - 2025-08-06 18:41 +0200
Re: Alternative for remote desktop connection VanguardLH <V@nguard.LH> - 2025-08-06 12:35 -0500
Re: Alternative for remote desktop connection T <T@invalid.invalid> - 2025-08-01 17:32 -0700
Re: Alternative for remote desktop connection Philip Herlihy <nothing@invalid.com> - 2025-08-02 12:15 +0100
Re: Alternative for remote desktop connection "s|b" <me@privacy.invalid> - 2025-08-02 15:57 +0200
Re: Alternative for remote desktop connection "J. P. Gilliver" <G6JPG@255soft.uk> - 2025-08-02 15:46 +0100
Re: Alternative for remote desktop connection "s|b" <me@privacy.invalid> - 2025-08-02 17:30 +0200
Re: Alternative for remote desktop connection "J. P. Gilliver" <G6JPG@255soft.uk> - 2025-08-02 18:32 +0100
Re: Alternative for remote desktop connection "Carlos E.R." <robin_listas@es.invalid> - 2025-08-02 19:53 +0200
Re: Alternative for remote desktop connection Paul <nospam@needed.invalid> - 2025-08-02 17:53 -0400
Re: Alternative for remote desktop connection "s|b" <me@privacy.invalid> - 2025-08-03 19:43 +0200
Re: Alternative for remote desktop connection Char Jackson <none@none.invalid> - 2025-08-03 20:41 -0500
Re: Alternative for remote desktop connection "J. P. Gilliver" <G6JPG@255soft.uk> - 2025-08-04 11:55 +0100
Re: Alternative for remote desktop connection Char Jackson <none@none.invalid> - 2025-08-04 23:22 -0500
Re: Alternative for remote desktop connection "J. P. Gilliver" <G6JPG@255soft.uk> - 2025-08-05 20:24 +0100
Re: Alternative for remote desktop connection "Carlos E.R." <robin_listas@es.invalid> - 2025-08-04 12:57 +0200
Re: Alternative for remote desktop connection T <T@invalid.invalid> - 2025-08-03 23:10 -0700
Re: Alternative for remote desktop connection "s|b" <me@privacy.invalid> - 2025-08-04 15:37 +0200
Re: Alternative for remote desktop connection "s|b" <me@privacy.invalid> - 2025-08-02 15:54 +0200
Re: Alternative for remote desktop connection Fokke Nauta <fnauta@solfon.nl> - 2025-08-02 16:40 +0200
Re: Alternative for remote desktop connection VanguardLH <V@nguard.LH> - 2025-08-02 19:56 -0500
Re: Alternative for remote desktop connection Fokke Nauta <fnauta@solfon.nl> - 2025-08-03 20:36 +0200
Re: Alternative for remote desktop connection VanguardLH <V@nguard.LH> - 2025-08-03 18:11 -0500
Re: Alternative for remote desktop connection Fokke Nauta <fnauta@solfon.nl> - 2025-08-04 11:34 +0200
Re: Alternative for remote desktop connection VanguardLH <V@nguard.LH> - 2025-08-04 14:06 -0500
Re: Alternative for remote desktop connection Fokke Nauta <fnauta@solfon.nl> - 2025-08-06 08:59 +0200
Re: Alternative for remote desktop connection Philip Herlihy <nothing@invalid.com> - 2025-08-03 21:07 +0100
Re: Alternative for remote desktop connection Fokke Nauta <fnauta@solfon.nl> - 2025-08-04 11:24 +0200
Re: Alternative for remote desktop connection Philip Herlihy <nothing@invalid.com> - 2025-08-04 10:50 +0100
Re: Alternative for remote desktop connection Fokke Nauta <fnauta@solfon.nl> - 2025-08-06 09:01 +0200
Re: Alternative for remote desktop connection Philip Herlihy <nothing@invalid.com> - 2025-08-07 11:39 +0100
Re: Alternative for remote desktop connection Fokke Nauta <fnauta@solfon.nl> - 2025-08-07 15:19 +0200
Re: Alternative for remote desktop connection Zaidy036 <Zaidy036@air.isp.spam> - 2025-08-04 16:25 -0400
Re: Alternative for remote desktop connection Fokke Nauta <fnauta@solfon.nl> - 2025-08-06 09:03 +0200
Re: Alternative for remote desktop connection Brian Gregory <void-invalid-dead-dontuse@email.invalid> - 2025-08-06 20:55 +0100
Re: Alternative for remote desktop connection Brian Gregory <void-invalid-dead-dontuse@email.invalid> - 2025-08-06 21:00 +0100
Re: Alternative for remote desktop connection Fokke Nauta <fnauta@solfon.nl> - 2025-08-07 15:22 +0200
Re: Alternative for remote desktop connection Fokke Nauta <fnauta@solfon.nl> - 2025-08-07 15:20 +0200
Re: Alternative for remote desktop connection Philip Herlihy <nothing@invalid.com> - 2025-08-08 11:44 +0100
Re: Alternative for remote desktop connection Fokke Nauta <fnauta@solfon.nl> - 2025-08-09 12:59 +0200
Re: Alternative for remote desktop connection VanguardLH <V@nguard.LH> - 2025-08-09 13:17 -0500
Re: Alternative for remote desktop connection Fokke Nauta <fnauta@solfon.nl> - 2025-08-10 18:01 +0200
Re: Alternative for remote desktop connection "J. P. Gilliver" <G6JPG@255soft.uk> - 2025-08-10 18:12 +0100
Re: Alternative for remote desktop connection Fokke Nauta <fnauta@solfon.nl> - 2025-08-10 19:33 +0200
Re: Alternative for remote desktop connection "J. P. Gilliver" <G6JPG@255soft.uk> - 2025-08-10 19:08 +0100
Re: Alternative for remote desktop connection Fokke Nauta <fnauta@solfon.nl> - 2025-08-11 09:46 +0200
Re: Alternative for remote desktop connection "J. P. Gilliver" <G6JPG@255soft.uk> - 2025-08-11 14:07 +0100
Re: Alternative for remote desktop connection VanguardLH <V@nguard.LH> - 2025-08-11 08:19 -0500
OT: Microsoft product (and service) naming (was: Re: Alternative for remote desktop connection) "J. P. Gilliver" <G6JPG@255soft.uk> - 2025-08-11 14:36 +0100
Re: OT: Microsoft product (and service) naming "Carlos E.R." <robin_listas@es.invalid> - 2025-10-20 11:06 +0200
Re: OT: Microsoft product (and service) naming "J. P. Gilliver" <G6JPG@255soft.uk> - 2025-10-20 10:48 +0100
Re: OT: Microsoft product (and service) naming "Carlos E.R." <robin_listas@es.invalid> - 2025-10-20 13:36 +0200
Re: OT: Microsoft product (and service) naming Frank Slootweg <this@ddress.is.invalid> - 2025-10-20 12:36 +0000
Re: Alternative for remote desktop connection "Carlos E.R." <robin_listas@es.invalid> - 2025-08-10 19:57 +0200
Re: Alternative for remote desktop connection "s|b" <me@privacy.invalid> - 2025-08-10 20:42 +0200
Re: Alternative for remote desktop connection Fokke Nauta <fnauta@solfon.nl> - 2025-08-11 09:44 +0200
Re: Alternative for remote desktop connection "J. P. Gilliver" <G6JPG@255soft.uk> - 2025-08-11 14:09 +0100
Re: Alternative for remote desktop connection VanguardLH <V@nguard.LH> - 2025-08-11 08:53 -0500
Re: Alternative for remote desktop connection "J. P. Gilliver" <G6JPG@255soft.uk> - 2025-08-11 15:53 +0100
Re: Alternative for remote desktop connection VanguardLH <V@nguard.LH> - 2025-08-11 13:03 -0500
Re: Alternative for remote desktop connection "J. P. Gilliver" <G6JPG@255soft.uk> - 2025-08-11 19:31 +0100
Re: Alternative for remote desktop connection "s|b" <me@privacy.invalid> - 2025-08-11 21:11 +0200
Re: Alternative for remote desktop connection "J. P. Gilliver" <G6JPG@255soft.uk> - 2025-08-12 02:00 +0100
Re: Alternative for remote desktop connection "s|b" <me@privacy.invalid> - 2025-08-13 21:21 +0200
Re: Alternative for remote desktop connection The Horny Goat <lcraver@home.ca> - 2025-10-19 23:36 -0700
OT: ageing (was: Re: Alternative for remote desktop connection) "J. P. Gilliver" <G6JPG@255soft.uk> - 2025-10-20 08:45 +0100
Re: Alternative for remote desktop connection VanguardLH <V@nguard.LH> - 2025-08-11 20:20 -0500
Re: Alternative for remote desktop connection Java Jive <java@evij.com.invalid> - 2025-08-12 12:35 +0100
Re: Alternative for remote desktop connection VanguardLH <V@nguard.LH> - 2025-08-12 14:16 -0500
Re: Alternative for remote desktop connection Java Jive <java@evij.com.invalid> - 2025-08-12 21:11 +0100
Re: Alternative for remote desktop connection VanguardLH <V@nguard.LH> - 2025-08-12 17:24 -0500
Re: Alternative for remote desktop connection Java Jive <java@evij.com.invalid> - 2025-08-13 05:10 +0100
Re: Alternative for remote desktop connection Paul <nospam@needed.invalid> - 2025-08-12 15:29 -0400
Re: Alternative for remote desktop connection Michael Logies <logies@t-online.de> - 2025-08-11 22:40 +0200
Re: Alternative for remote desktop connection "s|b" <me@privacy.invalid> - 2025-08-11 21:06 +0200
Re: Alternative for remote desktop connection VanguardLH <V@nguard.LH> - 2025-08-11 20:35 -0500
Re: Alternative for remote desktop connection "J. P. Gilliver" <G6JPG@255soft.uk> - 2025-08-12 09:01 +0100
Re: Alternative for remote desktop connection VanguardLH <V@nguard.LH> - 2025-08-12 13:23 -0500
Re: Alternative for remote desktop connection "J. P. Gilliver" <G6JPG@255soft.uk> - 2025-08-13 03:45 +0100
Re: Alternative for remote desktop connection "s|b" <me@privacy.invalid> - 2025-08-13 21:28 +0200
Re: Alternative for remote desktop connection VanguardLH <V@nguard.LH> - 2025-08-13 17:09 -0500
Re: Alternative for remote desktop connection "s|b" <me@privacy.invalid> - 2025-08-14 13:27 +0200
Re: Alternative for remote desktop connection "s|b" <me@privacy.invalid> - 2025-08-11 21:03 +0200
Re: Alternative for remote desktop connection VanguardLH <V@nguard.LH> - 2025-08-11 20:39 -0500
Re: Alternative for remote desktop connection rsutton <rsutton43@comcast.net> - 2025-08-12 07:49 -0400
Re: Alternative for remote desktop connection wasbit <wasbit@REMOVEhotmail.com> - 2025-08-13 09:26 +0100
Re: Alternative for remote desktop connection Fokke Nauta <fnauta@solfon.nl> - 2025-08-13 11:39 +0200
Re: Alternative for remote desktop connection "J. P. Gilliver" <G6JPG@255soft.uk> - 2025-08-13 12:13 +0100
Re: Alternative for remote desktop connection Fokke Nauta <fnauta@solfon.nl> - 2025-08-13 18:33 +0200
Re: Alternative for remote desktop connection VanguardLH <V@nguard.LH> - 2025-08-13 12:52 -0500
Re: Alternative for remote desktop connection rsutton <rsutton43@comcast.net> - 2025-08-14 08:22 -0400
Re: Alternative for remote desktop connection Fokke Nauta <fnauta@solfon.nl> - 2025-08-14 16:00 +0200
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | VanguardLH <V@nguard.LH> |
|---|---|
| Date | 2025-08-11 13:03 -0500 |
| Message-ID | <115qxw8a067va.dlg@v.nguard.lh> |
| In reply to | #186664 |
"J. P. Gilliver" <G6JPG@255soft.uk> wrote: > VanguardLH wrote: > >> their comparison page doesn't mention the limitations. The other >> editions mention the number of logged in users, and number of >> managed devices, but no mention of a limit for the free plan. While >> their free version is OSS, their other versions are not. >> >> Teamviewer supplies their own servers. No setup by you. Rustdesk >> has you setup a self-hosted server just like you have to setup a VNC >> server. > > Is that on your own machine? I've used Teamviewer in the past. You don't setup a server. They provide that. It is only to coordinate handshaking between the endpoint clients. Once they are connected, the server is no longer involved. For Rustdeak, just change their fluffy terminology of self-hosted server to just server, just like you have to do with a VNC server. You have to provide your own server, just like with VNC. In that case, you have to consider punching a hole in your router's firewall, and the firwall on your server host, use a porting rule in the router to forward all external access to just one of your intranet hosts (the ones running a server), and add protection to the server. You also probably won't know what is the current IP address of your intranet VNC server host (well, for the WAN IP address of your NAT router) unless you get static IP addresses from your ISP. To have a memorable host name for your WAN IP, you can use a DDNS service. You have the DNS updater client run on any of your intranet hosts, it reports the current WAN IP address to your account at the DDNS, and uses that lookup when you do an external connect. If you only do remoting from within your intranetwork, you don't need DDNS, but you'll need to configure your router to assign static IP addresses to your intranet host based on their MAC address. I have never used Rustdesk. Teamviewer works by the endpoint hosts making outbound HTTPS connections to the server. Firewalls, by default, pass out HTTP traffic without interference, and accept inbound connects to those outbound-initiated connection (i.e., stateful packet inspection). No having to punch holes in firewalls, define port forwarding, or employ DDNS to get a memorable host name to your network (WAN IP address of your router). Both ends make outbound HTTP connects to their already existing server that handshakes the endpoints to each other, and then drops out of the circuit. If Rustdesk uses the same scenario (both endpoints act as clients connecting via HTTP a server to facilitate the handshaking for the endpoints to find each other) then Rustdesk may be as easy as using Teamviewer. However, YOU have to setup the Rustdesk server, just like you have to setup a VNC server. Maybe sb can elucidate on how easy it was to setup his own Rustdesk server. Maybe they automate the setup to make it easy, but there are major differences between setting up a server for intranet access only, or setting up a server for external access into your intranetwork. https://rustdesk.com/docs/en/self-host/ "If you are using RustDesk you should have your own RustDesk Server, ..." "Support is available via our Discord for OSS and email for Pro." The free OSS version has you using Discord to get help. YUCK EXTREME! E-mail support is available, but only if you pay for the Pro version. They make noise how they are OSS, but that feature disappears once you move beyond their free version. I did happen upon: https://www.reddit.com/r/rustdesk/comments/13b0jz6/extremely_confusing_instructions/ which mentions "one may use the free Rustdesk public server". That looks to emulate Teamviewer's config, so maybe the endpoints use HTTP clients to connect to the rendezvous server to initiate handshaking between the endpoints. I did not find just what is the hostname or IP address for their rendezvous (public) server. Maybe that is encoded as a default in the Rustdesk clients, and you have to change to point at your own self-hosted Rustdesk server, if you want to do it that way. https://rustdesk.com/docs/en/client/ Usage Once installed (or run as a temporary executable) RustDesk will connect to the Public servers. So, they have a public rendezvous server (maybe more than one to provide load balancing since they used the plural of "server"). I found a forum thread where rs-ny.rustdesk.com was mentioned, but that may just a frontend server to redirect to other servers. I thought: https://github.com/rustdesk/rustdesk/#free-public-servers might list those, but nope. One user noted an nslookup on rs-ny-rustdesk.com return an IP of 108.61.171.103. Today I got 209.250.254.15. 108.61.171.103 is in Germany versus mine whose geolocation is in the Netherlands. Like with Tor and VPN that can have multiple exit nodes, could be their public free server changes to what it redirects. According to user reports, Rustdesk has had to up their server count, or otherwise improve the capacity of their free server due to increased load probably due to increased popularity. However, during their upgrades users have reported outages in the service. To see uptime of their various servers, you can visit: https://rustdesk.github.io/uptime/ Click on one, like for the rendezvous server, to see the weekly uptime stats. For me doing that now, the weekly stat (which is actually a daily report over a 1-month span) reported 26.38% uptime. That is very poor if you rely on their public server instead of hosting your own. BTW, I learned more about Rustdesk by having to research it more. No, I don't use it, and never have used it. With Teamviewer, all I had to do was install their client on each endpoint host no matter if it was an intranet or accessed across the Internet. Actually, for Teamviewer, you don't have to install anything as you can use web browsers at each endpoint to do a remote connect. Up to you to choose between their desktop client or web app. However, I don't recall if you get to use their web client with their free service tier.
[toc] | [prev] | [next] | [standalone]
| From | "J. P. Gilliver" <G6JPG@255soft.uk> |
|---|---|
| Date | 2025-08-11 19:31 +0100 |
| Message-ID | <107dcuf$2ooq7$1@dont-email.me> |
| In reply to | #186669 |
On 2025/8/11 19:3:33, VanguardLH wrote: [a very detailed and in theory helpful answer to my questions about RustDesk, and the subject in general] I'm afraid you lost mr pretty early on - which is no criticism of your answer, more of my ageing ability to absorb. I fear, if I need remote desktop in the future, I'll probably be back on TeamViewer - or one of the other similar. Or, possibly, nothing. > BTW, I learned more about Rustdesk by having to research it more. No, I > don't use it, and never have used it. With Teamviewer, all I had to do > was install their client on each endpoint host no matter if it was an > intranet or accessed across the Internet. Actually, for Teamviewer, you > don't have to install anything as you can use web browsers at each > endpoint to do a remote connect. Up to you to choose between their > desktop client or web app. However, I don't recall if you get to use > their web client with their free service tier. I don't remember seeing it, but then I probably would have avoided it anyway, as if there's a browser-centred way of doing something and an alternative, I tend to choose the latter - I don't like browser-everything. Much as I don't like everything (in life!) being done via "smart"phone. -- J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf War doesn't determine who's right. War determines who's left.
[toc] | [prev] | [next] | [standalone]
| From | "s|b" <me@privacy.invalid> |
|---|---|
| Date | 2025-08-11 21:11 +0200 |
| Message-ID | <mfuticFaqu3U1@mid.individual.net> |
| In reply to | #186672 |
On Mon, 11 Aug 2025 19:31:43 +0100, J. P. Gilliver wrote: > I fear, if I need remote desktop in the future, I'll probably be back on > TeamViewer - or one of the other similar. Or, possibly, nothing. I've been using TeamViewer for ages, but at one point it accused me of commercial use or I left the connection open for too long. Recently, I used RustDesk and my impression is that it's faster than TeamViewer. Setting it up is a no brainer: you download the portable EXE and run it. The other party does the same and provides you with an ID and password, exactly as in TeamViewer. RustDesk is also a bit smaller than TeamViewer's QuickSupport. RustDesk also allows you to set up favourites, so I'm assuming ID and password stay the same. -- s|b
[toc] | [prev] | [next] | [standalone]
| From | "J. P. Gilliver" <G6JPG@255soft.uk> |
|---|---|
| Date | 2025-08-12 02:00 +0100 |
| Message-ID | <107e3o7$2vckj$1@dont-email.me> |
| In reply to | #186675 |
On 2025/8/11 20:11:8, s|b wrote: > On Mon, 11 Aug 2025 19:31:43 +0100, J. P. Gilliver wrote: > >> I fear, if I need remote desktop in the future, I'll probably be back on >> TeamViewer - or one of the other similar. Or, possibly, nothing. > > I've been using TeamViewer for ages, but at one point it accused me of > commercial use or I left the connection open for too long. Recently, I I had that once, or possibly twice. They reactivated me (or whatever the right word is), but it took a few days. > used RustDesk and my impression is that it's faster than TeamViewer. > > Setting it up is a no brainer: you download the portable EXE and run it. > The other party does the same and provides you with an ID and password, > exactly as in TeamViewer. RustDesk is also a bit smaller than > TeamViewer's QuickSupport. Ah. If you read the VLH post to which I was replying, you'll see why I was losing the will to live thinking about it. If it's really as simple as you say, I was worrying unnecessarily.> > RustDesk also allows you to set up favourites, so I'm assuming ID and > password stay the same. > Presumably those are stored on their server. -- J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf In the words of my grandpa, a woman is as old as she looks. A man is never old until he stops looking. - Alice Apfel, designer, 1921-2024 (102)
[toc] | [prev] | [next] | [standalone]
| From | "s|b" <me@privacy.invalid> |
|---|---|
| Date | 2025-08-13 21:21 +0200 |
| Message-ID | <mg46tsF7cdhU1@mid.individual.net> |
| In reply to | #186690 |
On Tue, 12 Aug 2025 02:00:55 +0100, J. P. Gilliver wrote: > > Setting it up is a no brainer: you download the portable EXE and run it. > > The other party does the same and provides you with an ID and password, > > exactly as in TeamViewer. RustDesk is also a bit smaller than > > TeamViewer's QuickSupport. > Ah. If you read the VLH post to which I was replying, you'll see why I > was losing the will to live thinking about it. If it's really as simple > as you say, I was worrying unnecessarily.> I got my 70+ aunt (who claimed the TeamViewer QuickSupport wasn't on her Desktop where I left it last time) to run it successfully. > > RustDesk also allows you to set up favourites, so I'm assuming ID and > > password stay the same. > Presumably those are stored on their server. I guess. Today I downloaded the EXE on my mother's PC and after running it says two things: because of UAC it states it may be better to install and 'For faster connection, please set up your own server' Which can be done for free: <https://rustdesk.com/docs/en/self-host/rustdesk-server-oss/> -- s|b
[toc] | [prev] | [next] | [standalone]
| From | The Horny Goat <lcraver@home.ca> |
|---|---|
| Date | 2025-10-19 23:36 -0700 |
| Message-ID | <61mbfk58m3rttt9oeoqi6bind1fvt0khbl@4ax.com> |
| In reply to | #186690 |
On Tue, 12 Aug 2025 02:00:55 +0100, "J. P. Gilliver" <G6JPG@255soft.uk> wrote: >In the words of my grandpa, a woman is as old as she looks. A man is >never old until he stops looking. >- Alice Apfel, designer, 1921-2024 (102) That sounds like something Robert Preston might have said in Victor Victoria. (There's a scene where he was being harassed by a bunch of young toughs in a bar and one of them demanded to know when one loses interest in women. His response was "I'll be sure to let you know when that happens!")
[toc] | [prev] | [next] | [standalone]
| From | "J. P. Gilliver" <G6JPG@255soft.uk> |
|---|---|
| Date | 2025-10-20 08:45 +0100 |
| Subject | OT: ageing (was: Re: Alternative for remote desktop connection) |
| Message-ID | <10d4pa3$2rl2b$1@dont-email.me> |
| In reply to | #188500 |
On 2025/10/20 7:36:58, The Horny Goat wrote:
> On Tue, 12 Aug 2025 02:00:55 +0100, "J. P. Gilliver"
> <G6JPG@255soft.uk> wrote:
>
>> In the words of my grandpa, a woman is as old as she looks. A man is
>> never old until he stops looking.
>> - Alice Apfel, designer, 1921-2024 (102)
>
> That sounds like something Robert Preston might have said in Victor
> Victoria. (There's a scene where he was being harassed by a bunch of
> young toughs in a bar and one of them demanded to know when one loses
> interest in women. His response was "I'll be sure to let you know when
> that happens!")
Or - equally un-PC, I think Groucho Marx: You're only as old as the
woman you feel.
My Grandma often said you're only as old as you feel, and she was a
cheerful soul, despite falling apart; she lived to 98 ("and a half"!).
[The .sig below was just chosen at random by my usual algorithm!]
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()ALIS-Ch++(p)Ar++T+H+Sh0!:`)DNAf
I finally got my head together, and my body fell apart.
[toc] | [prev] | [next] | [standalone]
| From | VanguardLH <V@nguard.LH> |
|---|---|
| Date | 2025-08-11 20:20 -0500 |
| Message-ID | <1bfmfv9mkw0uy.dlg@v.nguard.lh> |
| In reply to | #186675 |
s|b <me@privacy.invalid> wrote:
> I've been using TeamViewer for ages, but at one point it accused me of
> commercial use or I left the connection open for too long. Recently, I
> used RustDesk and my impression is that it's faster than TeamViewer.
That could be due to where you are, and where is the public rendezvous
Rustdesk server to which you connect. I found rs-ny.rustdesk.com
mentioned, and my traceroute to it shows a huge jump in delay most
likely caused by having to go over the undersea cable to connect the
hosts across the pond.
tracert rs-ny.rustdesk.com
...
9 21 ms {myISP}
10 21 ms ae8.cr9-chi1.ip4.gtt.net [63.141.223.245]
11 115 ms ae2.cr2-ams13.ip4.gtt.net [141.136.106.174]
12 114 ms ip4.gtt.net [154.14.36.78]
13 * Request timed out.
14 * Request timed out.
15 115 ms 209.250.254.15.vultrusercontent.com [209.250.254.15]
Even though the nodes on each side of the pond are with gtt.net, their
own network spans the ocean across their data centers. GTT is global.
The added latency impinges on every packet across the pond.
You could do a traceroute on the Teamview rendezvous server to see if
you going the other way across the pond.
By the way, vultrusercontent.com resolves to 127.0.0.1. Odd it resolves
to localhost. Likely they don't want you directly using that hostname
since it is a frontend to redirect to their farm of actual servers.
[toc] | [prev] | [next] | [standalone]
| From | Java Jive <java@evij.com.invalid> |
|---|---|
| Date | 2025-08-12 12:35 +0100 |
| Message-ID | <107f8uq$37ukr$1@dont-email.me> |
| In reply to | #186693 |
On 2025-08-12 02:20, VanguardLH wrote:
>
> That could be due to where you are, and where is the public rendezvous
> Rustdesk server to which you connect. I found rs-ny.rustdesk.com
> mentioned, and my traceroute to it shows a huge jump in delay most
> likely caused by having to go over the undersea cable to connect the
> hosts across the pond.
This interpretation in the last sentence is wrong, see below ...
> tracert rs-ny.rustdesk.com
> ...
> 9 21 ms {myISP}
> 10 21 ms ae8.cr9-chi1.ip4.gtt.net [63.141.223.245]
> 11 115 ms ae2.cr2-ams13.ip4.gtt.net [141.136.106.174]
> 12 114 ms ip4.gtt.net [154.14.36.78]
> 13 * Request timed out.
> 14 * Request timed out.
> 15 115 ms 209.250.254.15.vultrusercontent.com [209.250.254.15]
Whereas for me in Scotland, using a mobile broadband connection (because
landlines around here are next to useless, and there is no FTTx in
wildest Sutherland):
11:04:08 D:\Temp>tracert rs-ny.rustdesk.com
Tracing route to rs-ny.rustdesk.com [209.250.254.15]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms [anonymised]
2 23 ms 19 ms 19 ms [anonymised]
3 * * * Request timed out.
4 67 ms 90 ms 73 ms 172.26.19.1
5 * * * Request timed out.
6 * * * Request timed out.
7 86 ms 69 ms 87 ms 172.26.24.93
8 * * * Request timed out.
9 71 ms 94 ms 83 ms 172.26.3.150
10 91 ms 90 ms 102 ms 149.11.22.122
11 * * * Request timed out.
12 105 ms 71 ms 83 ms be2592.ccr42.lon13.atlas.cogentco.com
[154.54.60.245]
13 106 ms 98 ms 99 ms be12488.ccr42.ams03.atlas.cogentco.com
[130.117.51.42]
14 101 ms 104 ms 98 ms be2154.rcr22.ams06.atlas.cogentco.com
[130.117.50.206]
15 111 ms 114 ms 98 ms 149.6.0.227
16 * * * Request timed out.
17 * * * Request timed out.
18 114 ms 94 ms 97 ms 209.250.254.15.vultrusercontent.com
[209.250.254.15]
Trace complete.
Again, see below ...
> Even though the nodes on each side of the pond are with gtt.net, their
> own network spans the ocean across their data centers. GTT is global.
> The added latency impinges on every packet across the pond.
>
> You could do a traceroute on the Teamview rendezvous server to see if
> you going the other way across the pond.
>
> By the way, vultrusercontent.com resolves to 127.0.0.1. Odd it resolves
> to localhost. Likely they don't want you directly using that hostname
> since it is a frontend to redirect to their farm of actual servers.
'The pond' is crossed by optical fibres, which by definition carry
signals at the speed of light for that medium, so, at the Atlantic's
widest point of 4,600kms, signals will take 4,600/[between 300,000 (best
case of a vacuum) and 61/0.000350 = 174,286 (worst case of a deliberate
slowing down as a 'speed bump' described in the link below)] = between
0.015s theoretical best case and 0.026s as a practical worst case, so
between 15ms and 26ms. Even in the worst case, these delays are no
worse than the fastest records in the traces above, and significantly
less than most of them, so the delays are caused by other things, such
as how the intervening systems are configured and/or how busy they are
at the time.
https://physics.stackexchange.com/questions/80043/how-fast-does-light-travel-through-a-fibre-optic-cable
"Some real-world data: The IEX stock exchange routes their traffic
through 61km of wound up fiber as a speed bump for traders, which
introduces 350 µs delay. See exchange.iex.io/about/speed-bump and
youtu.be/d8BcCLLX4N4?t=159. The minimal delay from that should be 61km/c
= 204 µs.They do not specify where the additional 146 µs delay comes
from (e.g. reduced speed of light inside the fiber, longer travel
distance, maybe even delay from the electric components that send and
receive the signal). – Socowi Commented Oct 27, 2022 at 20:04"
--
Fake news kills!
I may be contacted via the contact address given on my website:
www.macfh.co.uk
[toc] | [prev] | [next] | [standalone]
| From | VanguardLH <V@nguard.LH> |
|---|---|
| Date | 2025-08-12 14:16 -0500 |
| Message-ID | <13bi5cvlmzkyk$.dlg@v.nguard.lh> |
| In reply to | #186707 |
Java Jive <java@evij.com.invalid> wrote: > On 2025-08-12 02:20, VanguardLH wrote: >> >> That could be due to where you are, and where is the public rendezvous >> Rustdesk server to which you connect. I found rs-ny.rustdesk.com >> mentioned, and my traceroute to it shows a huge jump in delay most >> likely caused by having to go over the undersea cable to connect the >> hosts across the pond. > > This interpretation in the last sentence is wrong, see below ... Satellites also incur jumps in latency. Mobile networks can be even worse for latency. Depends on what type of cellular network to which you connect, but also the number of hops and through which other networks your data traffic passes. See: https://mvno-index.com/the-latency-of-the-different-mobile-networks/ I didn't bother to research for an Android app that would measure cellular data traffic latency (not bandwidth speed) to see what I might get at different web sites, especially on different continents. I found one at: https://play.google.com/store/apps/details?id=com.latencetech.mobilelatency&hl=en_US but didn't bother to install it just to soon afterward uninstall it. > 'The pond' is crossed by optical fibres, which by definition carry > signals at the speed of light for that medium, ... https://en.wikipedia.org/wiki/Submarine_communications_cable Yes, the core are optical fibers. You can see a map of them at: https://www.submarinecablemap.com/ Unfortunately the map doesn't specify the type of submarine cable for a particular route. For example, hover over the Atlantic Crossing-1 cable (purple), click on it, and the info panel shows some info, but not the type of cable. > "Some real-world data: The IEX stock exchange routes their traffic > through 61km of wound up fiber as a speed bump for traders, which > introduces 350 µs delay. Based on that example, the Atlantic Crossing-1 fiber cable would incur 350 microseconds x (14301 km / 61 km) = 82 ms. However, repeaters are required for the transatlantic cables, and add further delay. https://www.submarinenetworks.com/en/component/tags/tag/trans-atlantic Unforunately "low latency" doesn't provide an actual value. Some of the cables listed have latencies mentioned: 68 ms for AEConnect, 60 to 120 ms for Ellalink, 56 ms for EXA Express (between New York and London). With AEConnect with its 5200 km span as another example, 68 ms x (14301 km / 5200 km) = 187 ms for the AC-1 cable. I did find other info at: https://www.iptp.net/wp-content/uploads/IPTPMap_2017_1000x700-small.pdf which shows some latencies, like 64 ms from New York to London (scroll down to the bottom showing the concentric circles for major cities, and latencies to other cities). Worse is New York to Singapore at 252 ms. Theoreticals rarely equal actuals. For those using Rustdesk's or Teamviewer's public rendezvous servers, they need to measure latency for THEIR route to the server.
[toc] | [prev] | [next] | [standalone]
| From | Java Jive <java@evij.com.invalid> |
|---|---|
| Date | 2025-08-12 21:11 +0100 |
| Message-ID | <107g76a$3h1n3$1@dont-email.me> |
| In reply to | #186721 |
On 2025-08-12 20:16, VanguardLH wrote: > Java Jive <java@evij.com.invalid> wrote: > >> On 2025-08-12 02:20, VanguardLH wrote: >>> >>> That could be due to where you are, and where is the public rendezvous >>> Rustdesk server to which you connect. I found rs-ny.rustdesk.com >>> mentioned, and my traceroute to it shows a huge jump in delay most >>> likely caused by having to go over the undersea cable to connect the >>> hosts across the pond. >> >> This interpretation in the last sentence is wrong, see below ... > > Satellites also incur jumps in latency. Yes, but we're discussing undersea fibre-optic cables. > Mobile networks can be even worse for latency. Yes, but we're discussing undersea fibre-optic cables. >> 'The pond' is crossed by optical fibres, which by definition carry >> signals at the speed of light for that medium, ... > > https://en.wikipedia.org/wiki/Submarine_communications_cable > > Yes, the core are optical fibers. You can see a map of them at: > > https://www.submarinecablemap.com/ > > Unfortunately the map doesn't specify the type of submarine cable for a > particular route. For example, hover over the Atlantic Crossing-1 cable > (purple), click on it, and the info panel shows some info, but not the > type of cable. > >> "Some real-world data: The IEX stock exchange routes their traffic >> through 61km of wound up fiber as a speed bump for traders, which >> introduces 350 µs delay. > > Based on that example, the Atlantic Crossing-1 fiber cable would incur > 350 microseconds x (14301 km / 61 km) = 82 ms. However, repeaters are > required for the transatlantic cables, and add further delay. > > https://www.submarinenetworks.com/en/component/tags/tag/trans-atlantic > > Unforunately "low latency" doesn't provide an actual value. Some of the > cables listed have latencies mentioned: 68 ms for AEConnect, 60 to 120 > ms for Ellalink, 56 ms for EXA Express (between New York and London). > With AEConnect with its 5200 km span as another example, 68 ms x (14301 > km / 5200 km) = 187 ms for the AC-1 cable. > > I did find other info at: > > https://www.iptp.net/wp-content/uploads/IPTPMap_2017_1000x700-small.pdf > > which shows some latencies, like 64 ms from New York to London (scroll > down to the bottom showing the concentric circles for major cities, and > latencies to other cities). Worse is New York to Singapore at 252 ms. > > Theoreticals rarely equal actuals. For those using Rustdesk's or > Teamviewer's public rendezvous servers, they need to measure latency for > THEIR route to the server. All of which exactly supports my statement ... On 2025-08-12 12:35, Java Jive wrote: > > the delays are caused by other things, such as how the intervening > systems are configured and/or how busy they are at the time. ... in other words, it's not the passage through fibre-optic that's the reason for tracert &/or rust timeouts, it's other things in the system. -- Fake news kills! I may be contacted via the contact address given on my website: www.macfh.co.uk
[toc] | [prev] | [next] | [standalone]
| From | VanguardLH <V@nguard.LH> |
|---|---|
| Date | 2025-08-12 17:24 -0500 |
| Message-ID | <m5tffiues8iz.dlg@v.nguard.lh> |
| In reply to | #186724 |
Java Jive <java@evij.com.invalid> wrote: > VanguardLH wrote: > >> Mobile networks can be even worse for latency. > > Yes, but we're discussing undersea fibre-optic cables. Um, who brought mobile networks into the discussion? Oh, yeah, that was you. "Whereas for me in Scotland, using a mobile broadband connection". >> Theoreticals rarely equal actuals. For those using Rustdesk's or >> Teamviewer's public rendezvous servers, they need to measure latency for >> THEIR route to the server. > > All of which exactly supports my statement ... Um, who said to measure latency? That was me first. You brought in thereotical calculations (which were way off), and an example. I brought more examples. Yep, all of that supported my claim that the ocean cabling incurs a big jump in latency. Thanks for agreeing.
[toc] | [prev] | [next] | [standalone]
| From | Java Jive <java@evij.com.invalid> |
|---|---|
| Date | 2025-08-13 05:10 +0100 |
| Message-ID | <107h37e$3mo9s$1@dont-email.me> |
| In reply to | #186726 |
On 2025-08-12 23:24, VanguardLH wrote:
>
> Java Jive <java@evij.com.invalid> wrote:
>>
>> VanguardLH wrote:
>>>
>>> Mobile networks can be even worse for latency.
>>
>> Yes, but we're discussing undersea fibre-optic cables.
>
> Um, who brought mobile networks into the discussion? Oh, yeah, that was
> you. "Whereas for me in Scotland, using a mobile broadband connection".
It was merely there to document how the tracert was performed, it had no
other significance.
>>> Theoreticals rarely equal actuals. For those using Rustdesk's or
>>> Teamviewer's public rendezvous servers, they need to measure latency for
>>> THEIR route to the server.
>>
>> All of which exactly supports my statement ...
>
> Um, who said to measure latency? That was me first.
Yes, but then you drew the wrong conclusion - or perhaps only stated
it ambiguously giving an erroneous impression of what you believed, but
given your subsequent reply, I don't think so ... whatever.
> You brought in
> thereotical calculations (which were way off), and an example.
On the contrary, the calculations were reasonably accurate, certainly
accurate enough to show that the problems with latency had little or
nothing to do with crossing the Atlantic. See below ...
> I
> brought more examples.
Which were wrong, as the link you gave, which you clearly didn't bother
to read properly, stated in its description - BTW note that the
Atlantic is 4,600 kms wide AT ITS WIDEST POINT as per my ball-park
calculation, that should have alerted you that you were making some sort
of mistake [my emphasis]:
"The AC-1 (Atlantic Crossing 1) is a 14,000 km trans-Atlantic submarine
cable *SYSTEM* linking the USA and three European countries, the U.K.,
the Netherlands and Germany.
[...]
The AC-1 cable system comprises four fiber self-healing Synchronous
Digital Hierarchy (SDH) *RING* network connecting the United States with
the United Kingdom and Germany, with an initial design system capacity
of 40Gbps (8*2.5G DWDM, 2 fiber pairs).
The AC-1 cable lands at the following cable landing stations:
Brookhaven Cable Landing Station, the United States,
Whitesands Bay Cable Landing Station, the United Kingdom
Deutsche Telekom's Sylt Cable Landing Station, Germany
KPN's Beverwijk Cable Landing Station, Netherlands"
So it's a ring network, and 14,000kms is its total length, but the
distance between any two nodes on the ring is going to be much, much
less, similar to the 5-6000 km lengths given for the more recent cables
described further down on that same page.
> Yep, all of that supported my claim that the
> ocean cabling incurs a big jump in latency.
The fibre-optical cabling itself does not contribute significantly to
the latency, as I demonstrated, it's the other paraphernalia in the
system that's responsible for most of it.
> Thanks for agreeing.
You really do need to grow up and learn to admit when you're wrong.
--
Fake news kills!
I may be contacted via the contact address given on my website:
www.macfh.co.uk
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2025-08-12 15:29 -0400 |
| Message-ID | <107g4m5$3gdu6$1@dont-email.me> |
| In reply to | #186707 |
On Tue, 8/12/2025 7:35 AM, Java Jive wrote: > https://physics.stackexchange.com/questions/80043/how-fast-does-light-travel-through-a-fibre-optic-cable > > "Some real-world data: The IEX stock exchange routes their traffic through 61km of wound up fiber as a speed bump for traders, which introduces 350 µs delay. See exchange.iex.io/about/speed-bump and youtu.be/d8BcCLLX4N4?t=159. The minimal delay from that should be 61km/c = 204 µs.They do not specify where the additional 146 µs delay comes from (e.g. reduced speed of light inside the fiber, longer travel distance, maybe even delay from the electric components that send and receive the signal). – Socowi Commented Oct 27, 2022 at 20:04" > If you know the index of refraction, you know the speed of the light. The canonical value for the speed of light, is as measured in a vacuum. When the light travels through a material with an index of refraction, the light goes slower. AI Overview (ha!) [I should have asked for Olympic swimming pools] The speed of light in a vacuum is exactly 299,792,458 meters per second. ******* The speed of light is exactly 299,792,458 meters per second in a vacuum. In a transparent solid or liquid, it is divided by the index of refraction. The index of refraction for glass is roughly 1.5. So the speed of light in a glass fiber optic will be close to 199,861,638 meters per second. I like how the index is "roughly 1.5", but the speed is good to nine digits :-) There is also an organic liquid, with n = 1.5, and if you put a little dab of that on the end of the fiber, when you screw two connectors together there is no reflection where they meet. And it has to be something that won't evaporate. At the rate that fiber optic data transmission has changed, it would be pretty hard today, to say what the thru-delay is on a fiber amp module. At some point, they started using DSP for signal recovery. And presumably this is along the lines of PAM-5 on Ethernet. This allows multiple bits to be recovered in one clock period. Then, if your fastest logic runs at 100GHz, you can have a higher rate cable, if say eight bits are encoded in the signal in each clock signal period. But just in general principles, the regen period cannot be all that long, or the device would need a "huge buffer". And when the housing of that thing is opened up, the solution is not physically all that big. It's not like a Colossus hides inside the housing. The distance between regenerators, has also improved markedly, so there aren't as many "lumps" in the cable as it goes across the ocean floor. A term that just popped into my head, is "soliton". And while the article mentions erbium doped amplifiers, I don't know if those are fast enough for a transatlantic cable today. The EDA was used at about 40Gbit/sec. https://en.wikipedia.org/wiki/Soliton_%28optics%29 The cable is multi-spectral (uses more than one wavelength of light), the pulses are encoded with some sort of DSP (no article explained how that was done or what the pattern was). I guess it's a trade secret. All we need say, is "the datarate today... is damn high". It doesn't really matter any more, what that number is. It's just got a lotta zeros on it. Paul
[toc] | [prev] | [next] | [standalone]
| From | Michael Logies <logies@t-online.de> |
|---|---|
| Date | 2025-08-11 22:40 +0200 |
| Message-ID | <33lk9k9srglfp2qd188fcbqndpmnk7gc3v@4ax.com> |
| In reply to | #186672 |
>I'm afraid you lost mr pretty early on - which is no criticism of your >answer, more of my ageing ability to absorb. With Google Chrome Remote Desktop, which is free and fast, you are up and running within 5-10 min. I don`t understand, why more complex should be better for an average user. Teamview has been annoying with its nag screens in the free version in the past.. For a professional like me, RDP over a private VPN offers some advantages, but is more complex to set up. Regards M.
[toc] | [prev] | [next] | [standalone]
| From | "s|b" <me@privacy.invalid> |
|---|---|
| Date | 2025-08-11 21:06 +0200 |
| Message-ID | <mfut8oFaoijU2@mid.individual.net> |
| In reply to | #186669 |
On Mon, 11 Aug 2025 13:03:33 -0500, VanguardLH wrote: > I've used Teamviewer in the past. You don't setup a server. They > provide that. It is only to coordinate handshaking between the endpoint > clients. Once they are connected, the server is no longer involved. > > For Rustdeak, just change their fluffy terminology of self-hosted server > to just server, just like you have to do with a VNC server. You have to > provide your own server, just like with VNC. Nope. Simply open the (portable) EXE, other party does the same and provides ID and password, so you can connect with it. If you don't trust the RustDesk servers, then you can choose to set up your own server. -- s|b
[toc] | [prev] | [next] | [standalone]
| From | VanguardLH <V@nguard.LH> |
|---|---|
| Date | 2025-08-11 20:35 -0500 |
| Message-ID | <1ww76usawcdmz.dlg@v.nguard.lh> |
| In reply to | #186674 |
s|b <me@privacy.invalid> wrote: > On Mon, 11 Aug 2025 13:03:33 -0500, VanguardLH wrote: > >> I've used Teamviewer in the past. You don't setup a server. They >> provide that. It is only to coordinate handshaking between the endpoint >> clients. Once they are connected, the server is no longer involved. >> >> For Rustdeak, just change their fluffy terminology of self-hosted server >> to just server, just like you have to do with a VNC server. You have to >> provide your own server, just like with VNC. > > Nope. Simply open the (portable) EXE, other party does the same and > provides ID and password, so you can connect with it. If you don't trust > the RustDesk servers, then you can choose to set up your own server. With your setup, you are using their rendezvous server to connect the endpoint hosts. Self-hosted servers means you create your own rendezvous server. Upon first reading, I thought Rustdesk required you to setup your own self-host server simply because they didn't make it obvious they had publicly accessible rendezvous servers (well, I only found one, and it appears they have a problem with the ever increasing workload on their "demo" server). As I noted using their own stats page, Rustdesk's public rendezvous server does not have high reliability (aka high uptime) per their own specs. https://rustdesk.github.io/uptime/history/rust-desk-public-rendezvous-server 26% uptime seems high to you? 114 ms latency (sometimes up to 300 ms) seems low to you? I suspect if you paid for their closed-source versions that you get to connect to better servers with better load balancing and redundancy (aka a larger server farm).
[toc] | [prev] | [next] | [standalone]
| From | "J. P. Gilliver" <G6JPG@255soft.uk> |
|---|---|
| Date | 2025-08-12 09:01 +0100 |
| Message-ID | <107esd1$2vckk$3@dont-email.me> |
| In reply to | #186694 |
On 2025/8/12 2:35:18, VanguardLH wrote: [] > As I noted using their own stats page, Rustdesk's public rendezvous > server does not have high reliability (aka high uptime) per their own > specs. > > https://rustdesk.github.io/uptime/history/rust-desk-public-rendezvous-server > > 26% uptime seems high to you? 114 ms latency (sometimes up to 300 ms) > seems low to you? > > I suspect if you paid for their closed-source versions that you get to > connect to better servers with better load balancing and redundancy (aka > a larger server farm). 1 in 4 chance of it working sounds pretty useless - unless (a) its uptime distribution is spread, i. e. it's up for say 1 second in 4, or maybe as long as 5 seconds in 20 AND (b) it's only needed to help the two ends establish connection. If it needs to be up throughout your connection, then 26% isn't usable, and the latency would also come into consideration. So - _does_ the server need to be there throughout your connection, or just to establish it? And if the latter, and it's only up 26% of the time, how long do you usually have to wait for it? (For that matter, does a TeamViewer connection use the server all the time or just initially? The fact that they know how long you stay connected [and allegedly decide you're commercial if you stay on too long] suggests it is a continuous thing, though that could be just it looks say once an hour, minute, whatever to see if you still are.) -- J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf Apologies to [those] who may have been harmed by the scientific inaccuracies in this post. - Roger Tilbury in UMRA, 2018-3-14
[toc] | [prev] | [next] | [standalone]
| From | VanguardLH <V@nguard.LH> |
|---|---|
| Date | 2025-08-12 13:23 -0500 |
| Message-ID | <1tll2qm0z0h0f.dlg@v.nguard.lh> |
| In reply to | #186703 |
"J. P. Gilliver" <G6JPG@255soft.uk> wrote: > On 2025/8/12 2:35:18, VanguardLH wrote: > > [] > >> As I noted using their own stats page, Rustdesk's public rendezvous >> server does not have high reliability (aka high uptime) per their own >> specs. >> >> https://rustdesk.github.io/uptime/history/rust-desk-public-rendezvous-server >> >> 26% uptime seems high to you? 114 ms latency (sometimes up to 300 ms) >> seems low to you? >> >> I suspect if you paid for their closed-source versions that you get to >> connect to better servers with better load balancing and redundancy (aka >> a larger server farm). > > 1 in 4 chance of it working sounds pretty useless - unless (a) its > uptime distribution is spread, i. e. it's up for say 1 second in 4, or > maybe as long as 5 seconds in 20 AND (b) it's only needed to help the > two ends establish connection. If it needs to be up throughout your > connection, then 26% isn't usable, and the latency would also come into > consideration. > > So - _does_ the server need to be there throughout your connection, or > just to establish it? And if the latter, and it's only up 26% of the > time, how long do you usually have to wait for it? > > (For that matter, does a TeamViewer connection use the server all the > time or just initially? The fact that they know how long you stay > connected [and allegedly decide you're commercial if you stay on too > long] suggests it is a continuous thing, though that could be just it > looks say once an hour, minute, whatever to see if you still are.) No, the rendezvous server is just to handle the initial handshaking between the endpoint hosts. With VNC, you can use a DDNS service to give a hostname to the WAN IP of your router, so you don't have to figure out what is its current dynamic IP address. Don't need DDNS if you get a static IP from your ISP. For DDNS, your host needs a DDNS updater client to update your DDNS account with your current dynamic IP address. You define a port forwarding rule (punch a hole) in your router's firewall to direct that traffic to whichever intranet host is running the VNC server. Hopefully you required a strong password at your VNC server to prevent invasion. That's for external traffic; i.e., one endpoint is your intranet host, and the other endpoint is across the Internet. For intranet-only setups, you don't need DDNS, but you might want to configure the upstream DHCP server in your router to assign fixed IP addresses to your intranet hosts (well, at least the one running the VNC server) by using their MAC address. That way, you don't have to check the current dynamic IP address at the VNC server host to then connect using a VNC client on another intranet host. However, with TeamViewer or Rustdesk using their own public rendezvous servers, you will always make an outbound connection to reach an external server to handle the handshaking between your intranet hosts. One intranet host goes outside to the rendezvous server, the other intranet host goes outside to the rendezvous server, and the server facilitates one intranet host to find the other one. If the outbound connects by your intranet hosts use HTTP to connect to the outside server, you don't need to define a firewall rule. The firewall should already have an HTTP rule to let your web browser to connect to outside hosts. If not using HTTP client to connect to the outside server, you probably will need to define a firewall rule. Some companies don't want to have traffic bounce outside their corporate network to reach a public rendezvous server just to connect between their own hosts inside their own network hence the need for a self-hosted rendezvous server running inside the corporate network. If all you are connecting are your intranet hosts, both Teamviewer and Rustdesk will require your intranet hosts to connect outside to the Internet to get at their public rendezvous servers. That connection is only short-lived for the server to facilitate one host finding another. After the server gets the endpoints connected, the server [should] steps out of the circuit. Those services do not want to pay for the bandwidth resources to pipe all your inter-host traffic through their network.
[toc] | [prev] | [next] | [standalone]
| From | "J. P. Gilliver" <G6JPG@255soft.uk> |
|---|---|
| Date | 2025-08-13 03:45 +0100 |
| Message-ID | <107gu8o$3ldm0$1@dont-email.me> |
| In reply to | #186719 |
On 2025/8/12 19:23:32, VanguardLH wrote: [] > No, the rendezvous server is just to handle the initial handshaking > between the endpoint hosts. Thanks - that's all I need to know.> Thanks for the detailed explanation that followed - but I'm afraid you lost me at the first line: "With strawberry, you can use a tangerine service to give a banana to the cherry of ...". OK, you didn't use fruits, but that's where I glazed over! [thirty something lines] > If all you are connecting are your intranet hosts, both Teamviewer and > Rustdesk will require your intranet hosts to connect outside to the > Internet to get at their public rendezvous servers. That connection is > only short-lived for the server to facilitate one host finding another. > After the server gets the endpoints connected, the server [should] steps > out of the circuit. Those services do not want to pay for the bandwidth > resources to pipe all your inter-host traffic through their network. That makes sense. (Though do TeamViewer at least have a look, maybe every few minutes or even just once an hour, so they can see you and accuse you of being commercial?)So: Rust only needs to be there for your initial connection. So, of what nature is its alleged only 26% uptime - does it go off for hours (or days, or weeks) at a time, or does it pop up every few seconds - or maybe at minute intervals, if its software doesn't time out for that long? If it comes up _reasonably_ often, and for long enough to help you make a connection, it's a usable alternative to TeamViewer; if it goes off for hours, it isn't. The other figure someone mentioned - latency - presumably isn't that much of a problem if the server is only used when establishing a connection. -- J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf I've never really "got" sport or physical exercise. The only muscle I've ever enjoyed exercising is the one between my ears. - Beryl Hales, Radio Times 24-30 March 2012
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | alt.comp.os.windows-10
csiph-web