First of all, if your devices are behind a router, then whatever network ports and protocols are used must be “forwarded” on the router. Basically:
- A device going to the external world, as the source of the new connection, does not need anything special from the router. In this case it would be the desktop PC.
- A device which is behind a router, when the device is going reply to a remote connection, must have the router forward the correct port/protocol to the receiving end. In this case it would be the Jetson.
Without the above there is only a connection from router to router, but the end device (the Jetson) would never see the network traffic. Being able to ping the Jetson’s router from the PC is a minimum test (assuming the router or firewall does not firewall ping). The next test is to see if you can reach the Jetson with some port, e.g., for ssh
command line, it would be port 22 using TCP protocol. If this is the case, then you know the router is forwarding ssh
. There are other similar services, and those each have their own port/protocol for the router to be set up for.
ssh
offers you command line access, which is actually pretty powerful, but it has limitations regarding GUI and GPU use. You will see references to using ssh
to forward from the Jetson using GUI apps or GPU apps. An example is that your host PC, if it uses the right option to ssh
, can run a terminal program and it pops up on the PC instead of the Jetson, but it definitely runs on the Jetson. This is not what you want for anything CUDA because it doesn’t work like you would expect.
The X server basically sees “events”, and performs GPU duties based on interpreting events. When you forward, then the remote event gets sent to the PC’s GPU, not to the Jetson. This is fine if your PC has all required software (e.g., OpenGL or CUDA) of the right version, but should want edge computing, then this fails. The Jetson would no longer be using its GPU because events go to the wrong server.
A virtual desktop is just like ordinary desktop software when you log in directly to the Jetson. However, it has bindings which allow a third program at a remote location see the result of X events, and brings those to the desktop PC with those events remaining on the Jetson’s GPU. The monitor itself can be “virtual” on a virtual desktop, meaning you don’t even need a monitor on the Jetson (though you could have one on it). The CUDA and other hardware accelerated software (e.g., OpenGL) does not know, nor does it care, that the monitor on the Jetson is a buffer which pretends to be a monitor. Setup would be more complicated for this, whereas ssh
with or without forwarding is trivial. The ports and protocols would differ for the router setup, depending on which software you use.
I have no recommendation on a virtual desktop, but other people here will have experience with virtual desktops. Hopefully others will post some recommendations at what virtual desktop to use.