Tuesday, January 17, 2012

Local RDP, NX 3.5 Installed

After waiting many months for the release of NX 4 we reached a point where we could not wait any longer to use compression technology with the new GNOME desktop servers. We were really hoping that NX 4 would fall into place so that we could deploy iPads running host based software. So last week I removed the NX 4 beta and installed the released/stable NX 3.5 After remembering a few tweaks we did a number of years ago, it's all up and running. I removed the NX 4 client from our thin clients and reinstalled the older version as well. A few script changes and improvements and things were working. I should be able to get a test build to remote site users this week.

Our division got word very late in the implementation process of the new MS Windows based Recreation software that thin client workstation IDs were needed for the software to properly know which cash drawer to use. For Recreation sites running XDMCP, this was no problem and already implemented. I had offloaded RDP/Rdesktop sessions many thin client releases ago and they were already running on the local device. But we have one site that was using NX in full screen mode with no window manager. So when a local RDP session was started, there was no window manager to grab it and allow the user to move the two windows around. RDP would just sit over NX and obscure the view. It was clear that a new type of thin client build was required, one that connected to our servers with NX and that was running a local window manager. After a few white board drawings, I picked the path that seemed the best solution and made the necessary changes. As is seen in the shot below, when the user picks this option it automatically detects the size of the screen and NX is started consuming about 90% of the screen. The window manager then wraps this window and they are able to move it around nicely. When they click on this MS Windows app, the server sends a signal to the thin client who then launches Rdeskop locally and the window manager grabs this window as well. I put a small modal applet in the upper left hand corner to allow the user to disconnect this session and shut down the window manager. A bit more testing and this should be ready for beta testing; hopefully later this week.


Anonymous said...

Hello Dave,
A bit off-topic but I will bite since you are using NX extensively. I've been using th 3.x series for years. Recently I have noticed that TigerVNC gives me better responsiveness and picture quality. Have you noticed something similar? I know that NX has some additional enterprisey features that are quite handy in you case, but wanted to check whether someone else has the same experience with TigerVNC as me.

Dave Richards said...

@anonymous: I haven't had time to test all variations of VNC, but in my testing it worked well over WiFi, but was way too slow over EVDO. NX seems to get us excellent speed even over cell cards. NX has enterprise features: better resume and better rotary features. VNC requires lots of fixed ports and settings. User A is port 5902, user B is port 5903 and so on. I continue to test all ideas as time allows. :)

Anonymous said...

I am not anonymous, I am al_shopov (-:

Thank you for the answer, I know that there are quite a few VNC incarnations, and some of them are definitely slower than NX (and NX has some additional features that are important for your use case).
From Wikipedia I see that EVDO is at least 38.4kbps (though this might be shared). I have no idea what is the latency and package lost of such a link, but thank you for the info, I will probably test TigerVNC via cellular data transfer here in Bulgaria.

Just an additional point - TigerVNC for both server and client is the fastest I have seen for Linux, but I have had some problems with it as a server under Windows where TightVNC or RDP might be more appropriate (besides NX that is).

windows server said...

I currently work for Dell and I liked your blog, it's very informative. Thanks for sharing such a useful information with us.