Users communicate with NETLAB+ using a web browser. This is a logical choice since all computing platforms (PC, tablet, phone) have a web browser which is already installed. Just point your browser to the NETLAB+ server URL and you are good to go. That’s how it should work in theory anyway…
Until recently, browsers did not provide a native mechanism for two-way full duplex communication. For this capability you needed to install a browser plugin such as Java. The full-duplex capability provided by Java allows the NETLAB+ server to “push” unsolicited messages to NETLAB+ client applications. There are three NETLAB+ client applications that require full-duplex communication and utilize Java: the Remote PC Viewer, the CLI Terminal, and Chat.
When we launched NETLAB+ in 2000, Java was available with most web browsers and it was usually bundled with the browser. So this was the a very good choice at the time and we invested heavily in Java client-side applications. Flash was also bundled with most browsers, but did not have the native protocol support that Java had, so we chose Java over Flash.
Fast forward to 2014 and we find that browser plugins such as Java and Flash are rapidly being expelled from the browser. There are two reasons for this: 1) mounting pressure over security concerns, and 2) plugins allow developers to bypass the “app stores”, which has both security and profit implications. The decision to ban browser plugins from Apple IOS and Google Android will likely mean the end for Java web applications, Flash, and browser plugins in general.
What to do?
Fortunately, HTML5 introduces new browser functionality called “websockets” that provides similar full duplex communication between a web browser and a server. This capability was recently standardized and is now implemented in most recent web browsers. Converting the Remote PC Viewer and CLI Terminal to use HTML and websockets are very high priorities at NDG. I will discuss the future of Chat in another post.
Websocket applications start out by making normal HTTP or HTTPS requests to the server, but then switch to the websocket protocol. Websocket connections use the same TCP ports used for web access (80 and 443). However, not all firewalls and HTTP proxy servers understand the websocket protocol and thus may interfere with unencrypted HTTP connections on port 80. The use of HTTPS (port 443) and SSL for websockets prevents interference from these devices. As such, adding HTTPS support to NETLAB+ is also a high priority. Many have requested HTTPS/SSL as a feature, and this will eventually become a requirement to use the new websocket applications. I’ll be talking more about HTTPS in my next post.
We will continue to support the Java apps for some time to allow customers time to open port 443 and transition to the new applications. Once all Java applications are converted, it will be likely possible to run the entire NETLAB+ system with only one open IP address and one port (443).
