Unattended access #178
Comments
|
I am implementing a client-server-client remote control system similar to Teamviewer based on Dayon's core code. I will use Netty as the network communication framework. If you are interested, you can follow me and I will launch this project as soon as possible. |
|
https://github.com/SpringStudent/remote-desktop-control, I have finished first version,hope you will try it |
|
It looks great from the uploads you have made! I would like to test, but need executables for Win11 and Linux Mint22 to do so, and I see no releases. I know it is java based, but it is beyond my skills to create. Perhaps see how it was done with Dayon. Thanks! |
|
@RetGal perhaps this is something you can leverage in Dayon! too, as the code made by @SpringStudent is also available here on GitHub? I trust you will keep Dayon! up to date and ever improved as time goes by. 😇 |
|
@SpringStudent The screens look promising! |
Thank you for your response! I’m really looking forward to seeing you improve the code or add new features. |
The current version has only been tested on macOS and Windows, so I’m not sure if it will run properly on Linux Mint 22. Regarding the installation package, it is still an unstable version, and running it as a packaged application may lead to various issues. I am continuously optimizing it. Additionally, this client-server-client architecture requires more than just installing the package; you also need to deploy the remote desktop server on a separate machine. |
|
Ok. I have several machines, but will have to wait for more mature releases, as it is far beyond my technical skills to be able test before then. I will keep watching and try to bring any value I can along the way. |
|
What I am about to write here may be noob stuff and already what you are looking at (or have implemented in Dayon!), so please accept my apologies for not knowing enough about the underlying code of @RetGal Dayon! or @SpringStudent remote-desktop-control. As @RetGal already knows, I understand some things, but lack other fundamental insights. RationaleThe reason I share this, is that I have seen instances where Dayon! is not able to connect the two computers, while other apps have been able to (see below) Just focus on the intial connectivity or also update the communication protocol? To achieve this, TeamViewer seems to be using a technique called "UDP Hole punching" and when I read about that, it sounds a lot like what is already used in Dayon! - but with a much stronger possibility of getting through all different NATs etc. I have also tested two open source solutions DWService.net and HopToDesk.com. Those are not built in Java as fas as I know, but they also offer Unattended Access and are able to get past more CGNATs than Dayon! currently are able to. My point with all this is that perhaps it is good to validate if it is only the "connectivity" module of Dayon! that needs to be looked at (to use more modern UDP Hole Punching), or if the perhaps the whole Netty implementations should replace "connectivity" + "communication" of Dayon! to get a broader full range of benefits (Netty includes UDP Hole Punching, but also more - see below) I found this java project on github - A NAT Traversal Mechanism for Peer-To-Peer Networks: UDP Hole Punching Implementation UDP Hole Punching vs. NettyThe Netty protocol is compatible with UDP hole punching. While Netty itself is not a hole punching technique, it is designed to work over UDP and can leverage UDP hole punching for NAT traversal. Similarities and differences between Netty and UDP hole punching, as I have understood it: Similarities
Differences
Hoping all this made sense and perhaps brought some value to the discussion. |
|
I see two main obstacles/challenges for implementing the ability of unattended access:
The first obstacle is bigger than it looks at first glance, because in many cases the user does not have the authorization to install a system service. And what happens if the user is not logged in, has locked their screen or the computer is in energy-saving mode? The second could eventually be mitigated by including the connection logic into the token/rvserver. With that approach, the assistant would still need the port forwarding activated on its side. Roughly outlined, this 'lightweight' approach could look like this:
This would of course add some load to the server, but probably not too much since most of the users will not have the need/requirement to let another party connect to their computer when they are not in front of it =) |
|
Thank you, as always, for your thoughtful response. ❤️ "Lightweight approach"I like your suggested approach, as it sounds like a no-nonsense way to do it. One thought I got when reading it through again, is if what you call the UA token is something that changes between sessions, or if that is what the other apps use as a fixed "Device ID" for? With a fixed "Device ID" for the Assisted, the Assistant can "connect" with it via the refreshed info in the rvserver. (This may be over my head, so pls ignore if the question does not make sense.) "Unattended Access" vs. "improve capabilities to connect Assisted and Assistant"I appreciate that it was I that started this topic with the intention on encouraging the unattended access functionality. 😁 But as I have tested and read up, I believe it is equally (more?) important (and perhaps easier to implement in a first step?) to get Dayon! more capable in getting through different modern NATs during its connection setup for sessions between Assisted and Assistant. That is what the "UDP Hole Punching vs. Netty" comment above is about. My point being: If the connection could be improved with UDP hole punch or Netty, and it would be less complicated for you to implement that without also creating the unattended access model, I would suggest that as a starting point. Then at a later stage look at how to make the unattended access model work smoothly, because as you so correctly write: many would not use it. But for us who do, it is a brilliant function (as long as the computers stay on idle and do not shut down 😊) Footnote: One could argue that the unattended access would provide the ultimate simplicity for the Assisted, once it is installed: they simply need to turn on their computer and the Assistant will be able to help them without the Assisted pressing any buttons to start the program etc. |
|
Thanks for the praise - you're right, "Device ID" would probably be the better term! Concerning "improve capabilities to connect Assisted and Assistant": If the port forwarding requirement on the Assistant side is the problem, which is very likely in an enterprise environment, then some form of “hole punching” from a third party peer is indeed inevitable. |
|
Thanks! That means I still seem to keep up with the topic :) When I have stress tested capabilities to connect, I have switched the Assistant/Assisted positions between internet access via 4G and via fiber access behind corporate grade NAT (the standard for most ISPs in the Nordics). I have also tested between Assistant/Assisted in DK and PT (but only CGNAT-CGNAT) DWService, TeamViewer and HopToDesk have been able to connect the two machines without issues in these tough combinations (both in normal "active" mode and in unassisted mode). Dayon did not. So I indeed believe this is the way forward to help Dayon users increase their chances of connecting in today's multi-network topologies. |
Regarding what you mentioned about TeamViewer using UDP hole punching (relay server) to establish a connection, this is indeed true. The purpose of this is to establish a P2P connection and avoid the data packets being routed through a relay server, with the fundamental goal of reducing latency. If the direct connection fails, it will fall back on the relay server to forward the packets. As for Dayon, my understanding is that there is no relay server involved. It can be considered an alternative form of P2P connection, where the control and the controlled devices communicate directly. Therefore, UDP hole punching may not be necessary. If you are unable to establish a connection between the control and the controlled devices using Dayon, you can try using network penetration tools such as frp or lanproxy to map the control device's IP and port to a public-facing IP and port that can be accessed over the internet, and then try again. Regarding remote-desktop-control, it currently doesn't require UDP hole punching because all the data packets between the control and the controlled devices are forwarded via a relay server. As long as the control and the controlled devices have normal network connectivity to the server, connection failures will not occur. This is because even if TeamViewer's hole punching fails, it will fall back to this type of scenario. |
|
@SpringStudent thank you so much for bringing clarity to me on this! Do I understand you correctly?
New question from me The connection part, in my mind, should be a separate issue from how the two parties then share session data packets. In short: "if no 1, then no 2 or 3". Apologies again if this is an irrelevant question, but I am curious to learn. Regarding frp and lanproxy
A note to @RetGal from me, is that Netty seems most capable of adding several (future) functions to Dayon, incl. UDP Hole Punch and a relay server functionality for session data packets, but perhaps a "clean" UDP Punch Hole or lanproxy solution is easier to implement to modernize the connectivity of Dayon, without adding the relay server in full? The reason for this thinking would be that, it seems to me, the rvs (with an update) could still be used only to share the needed info to connect the parties with each other (lanproxy or UDP Hole Punch), but not actually required to relay the session data packets (Netty). @SpringStudent please feel free to add or correct me here. |
|
The premise for using Dayon is that the IP and port of the assisting party must be accessible to the assisted party, meaning the network between the two must be communicable. UDP Hole Punching is used to help establish a P2P connection between two clients behind NAT. The two parties in this connection are equal in status, meaning there is no need to distinguish between the controlling party and the controlled party. The usage scenario for Dayon tends to favor giving control to the assisted party, while the controlling party typically doesn't relinquish control. Therefore, if Dayon can establish a P2P connection via UDP Hole Punching, it might make one question why we still need to differentiate between the controlling and controlled parties, as both sides can establish a long-lasting P2P connection. In contrast, TeamViewer doesn’t distinguish between controlling and controlled parties; as long as both sides know the client identifier, they can control each other. Regarding lanproxy and frp, these are internal network penetration tools. The intention in mentioning them is that if you just want to use Dayon in your application scenario, you can map the IP and port of the assisting party to the public network through these penetration tools. This way, the assisted party can connect to the assisting party, and assistance can take place. As for points 1, 2, and 3, I believe that 1 and 2/3 do not have to be directly related. It’s not the case that without 1, 2/3 cannot exist. Point 1 is simply a means of efficiently and low-latency sending data packets to both parties. |
|
Very well explained, @SpringStudent, then it all makes sense to me! I like that lanproxy could help improve the current connectivity capabilities of Dayon, while hole punching would make the two parties equal in their ability to connect to each other (simplifying, e.g., unattended access) Thank you so much for taking the time to explain 🙏 |
|
I'm glad I could help you. |
Is your feature request related to a problem? Please describe.
To provide remote assistance without the Assisted needing to be present.
I realize this may be way out-of-scope for this application, but having an Unattended Access would be magic: please consider this a long-term suggestion for enhancement.
Describe the solution you'd like
Like TeamViewer, AnyDesk and (soon) Helpwire: to be able to connect the Assistant to the Assisted without the assisted person sitting in front of their screen starting the session.
Describe alternatives you've considered
(A) If it is to be implemented, perhaps the online server(s) used for session keys could be leveraged to also host required scripts to enable this functionality (it seems all three providers mentioned above require online servers).
Or...
(B) Leave it be, as this may be considered out-of-scope.
Additional context
I've seen som great developments these past months, so this inspired me to pitch in this long-term idea.
The text was updated successfully, but these errors were encountered: