Display protocols have been around for decades. It may be argued that even for centuries: Ever since the prehistoric days of the predecessors of the computing industry, a couple of centuries back then; Back in the late 19th century, technology has brought the wonders of having data, stored in one’s mind, given to a “Terminal Server” such as the typewriter which did some sort of Processing, and emitted output to a Display such as a paper.
Nubo CTO Ron Munitz examines the evolution of display protocols, from typewriters to distributed mobile OS display servers, in this first in a series Nubo Blog post.
Ever since then, technology has evolved greatly, introducing complex graphical platforms such as Microsoft Windows and GNU/Linux, obtaining input from various sources such as Keyboards, mice, applications talking to one another and so, doing complex computations and emitting state of the art graphics to some Display hardware.
Naturally, given the distributed nature of computing in the 20th century, the needs arose to have the input given Remotely at an arbitrary location, transmitted “over the wire” into the Terminal Server to do its magic, and emitted Remotely to a display. All this happens over some network, and completely remotely, and putting this entire framework together is commonly known as using Terminal Services via Remote Display Protocols.
Remote display protocols work in the following way: They use some internistic knowledge of the way the Operating System processes input events (e.g. the way the kernel receives an interrupt of an incoming keystroke), and the way it renders information to the display (e.g. how a matrix of pixels is written to the graphic card memory), and apply this knowledge to reproduce the same actions on two different entities: The client and the Terminal Server.
The Client is a software which is responsible to interact with the user. It gathers input events on the hardware and Operating System it is running on, puts them “on the wire” and sends them to the remote Terminal Server. It is also responsible of receiving display information from the Terminal Server, and emit it locally to the server. In other words the client is an I/O pipe. Receives input from the user, displays output to the user and runs no business logic whatsoever.
The Terminal Server is the system which actually executes the business logic of applications, has exclusive access to data, and is the only entity that really executes the applications of concern. It receives no direct user input or output on its local hardware, but rather translates the input events it gets from the client into its operating system’s internal structure format, and injects them to the application of concern as if these events were received locally by the Terminal Server hardware, at its local interfaces. In a similar fashion, the graphics the application would otherwise share with a local device hardware are projected “onto the wire” rather than on the display, and sent over to the client.
Since both input and output go over the wire (or over the network, to be more formal), remote display protocol are tender to network conditions, which can greatly impact the user experience, making latency and bandwidth considerations the Achilles’ heel of all of them: The input processing is in most cases small in terms of bandwidth it requires. The other part of the puzzle however, having to emit display from the server and onto the client’s display may be extremely challenging and bandwidth expensive.
Many display protocols have been developed in order to optimize these aspects for the different operating systems around. The most famous ones would be VNC, X11 and RDP, to name a few. These have been around for decades, all targeted at the having a desktop or even a laptop client, running over a general purpose operating system such as Windows, Unix, Linux, and their likes executing software on a remote operating system such as those aforementioned.
But what about mobile apps? These have significantly changed the rules of the game. No longer desktop UI, and no longer stable slotted aloha ethernet networks over wired LAN. Everything now goes mobile. For better and worse. The game has changed. And when the game changes – technology catches up. The next article will explain how, why and when, describing the challenges behind the adoption of mobile terminal servers.