How to connect two Qt PC apps over Internet (not locally) using UDP protocol?
I'm in the process of developing some sort of teleoperation robotics application. One PC is ubuntu and the other PC is Windows 10. Both have Qt5.10. I've done some applications using sockets in Windows and Linux but locally using
444. Now I would like to develop an application over Internet to test my application. What are the general guidelines for this kind of applications? It seems to me the security is the real issue and merely dumping the IP is not enough. Is there any tips regarding this issue? Also, if Qt has any features to simply this kind of projects? Thank you in advance.
QSslSocket comes to mind for that.
Note that robot teleoperation and UDP doesn't sound quite right. Looks more like something for TCP.
@SGaist thank you for QSslSocket. Regarding the UDP, this is the right approach for teleoperation robotics. Delay is a major issue in teleoperation so upd is preferred in this kind of projects. This is a well-established fact in literature.
Connecting over LAN or internet works 100% the same.
The only matter is source and target will be behind router/firewall and the correct
NAT/forwarding needs to be in place for it to work.
Pablo J. Rogina
Delay is a major issue in teleoperation so upd is preferred in this kind of projects. This is a well-established fact in literature.
@CroCo maybe UDP is well established in the literature, but perhaps it was so in a world where the clients/servers sat in the same local network, and Internet or IoT was not widely available as it is now, full of bad guys trying to do bad things.
Given that said, and if you're really going to connect some robotics device on the Internet and expect to control it from somewhere in the world, please be advised that you won't be the only one trying to control it. Once somebody discover that there's a port open listen for plain UDP packets, well, it's a invitation for things to go wrong.
In addition to what you guys have said, I thought UDP is for "broadcasting to multiple clients" whereas a TCP connection would be for "one-to-one communication". Why would the OP want to "broadcast" in this situation?
And just to add to @Pablo-J.-Rogina,
Regarding the UDP, this is the right approach for teleoperation robotics. Delay is a major issue in teleoperation so upd is preferred in this kind of projects. This is a well-established fact in literature.
You are aware that sending packets through the internet is not comparable with sending them in the local network? First, the time to tansmit a packet to another station takes unpredicatable time, and every packet can take another route.
Second, sometimes packets get lost in the internet. With TCP you have automatic retransmission, something that you have to take care yourself when using UDP.
Pablo J. Rogina
@JonB I think UDP is/was used because of its simplicity, and thus, less computation resources needed to implement it (thinking of old embedded devices for instances), but simplicity comes at a stake of less reliability. A TCP connection guarantees the delivery of a package (because of retransmission, etc.) while UDP doesn't assure any given packet will reach the other end.
@Pablo-J.-Rogina thank you for this informative answer. The comparison between UDP and TCP in teleopration projects has been done in literature. I don't remember the papers I've read since this was a long time ago. UDP is preferred over TCP due to not simplicity which is a bonus but the fact that delay destablizes Haptic-Teleopereation projects. In the aforementioned projects, delay time injects unwanted energy in the system. The mathematical proof for the preceding fact has been published in the 1980s. You can search more about that in IEEE if you are interested.
You are absolutely right about the security issue which is why I'm asking since my background is far away from networking security discipline. I need some guidelines for this matter in order to perform projects in more realistic scenarios. I've done the local networking communication. Now I need to move forward with caution.