Ever since the 1950’s remote computing has been a hot favorite amongst engineers and tech enthusiasts alike. Back in the day, remote control of computers was visionary. The first generation users of computers had access to time-sharing systems, from tremendous mainframes, which merely allowed a few users to log into a central computer. This established a precedent for what would develop into decentralized systems and remote computing as we now know it. Each decade was successively improved in terms of breakthroughs in speed, economy of effort and access, which were the building blocks of what we encounter today’s advanced solutions in remote access.

The evolution of distant computing is the sum of many networking and systems theory efforts spanning several decades. Let’s take RDP (Remote Desktop Protocol) and VNC (Virtual Network Computing): both changed the primary function of pumping pictures across the network into an advanced technology of information exchange. Each of the protocols applied its own encoded format, data compression, and data processing methods to its specific needs, each of which was quite a trade-off in network bandwidth type of business. These days, the demands of developing a true RMM system for the global market are only the most basic of these laws, optimized by years of engineering development.

Introducing RFB: The Underpinning Protocol for VNC

With this we come to the RFB protocol—VNC’s basic building block. RFB, an abbreviation for Remote Framebuffers, may seem comprehensive, but a lot goes on behind the scene. To put it simply, RFB makes it possible for a VNC server to send a “framebuffer” to the VNC client, which is in terms of structure, a collection of pixel data. It’s like a slideshow of pixel data with advanced capabilities for managing keyboard and pointer input. Since framebuffers are the building blocks of RFB, pixels are what enables VNC to transmit complete graphical interfaces.

RFB is functional in two major parts:

1. Input Protocol
2. Display Protocol

Let’s examine each of them independently.

1. Input Protocol

The Input Protocol manages communications coming from the client. Once any command is typed or a command is clicked on by a user on the client, these operations reach the server through two specific types of messages: KeyEvent and PointerEvent. For each keystroke or pointer movement, the server basically receives a message that says: "This key was pressed." or "This button was clicked." In order to standardize this, the keys are specified in the standard of the X Window System using "keysym" values, thus coordinating these activities on various systems. This provides a means for a user operating remotely to command a machine as if he/she is sitting in front of it, which is important for remote monitoring.

2. Display Protocol

The Display Protocol could be termed as the primary workhorse of RFB, which can be summarized with a single command – “put a rectangle of pixel data at a given x,y position.” While it might seem awkward to represent the screen in rectangular shapes, the weak areas of RFB – the way it encodes and compresses information, makes it fast and effective for such graphic data transfer over a network.

Pixel Data Format

Certainly, one of the most important components of RFBs versatility is the pixel data format. Client devices, when they connect, come to an agreement with the server as to how pixels and encodings will be used in this session. That this negotiation exists is designed for the client so that the client operates without difficulty on a vast majority of devices.

• Pixel Format: Reflects how different colours are reproduced. The most common are the 24-bit or 16-bit true color, in which the pixel values are texture-mapped directly onto red, green and blue intensity. There is also a format called 8-bit “color map”, which has limited color’s and pixel values done through RGB tables. Such formats are very effective in cases where the system does not need to transmit the full color grain.

• Encoding: It’s a term which describes how the rectangles representing pixels are transported around on the network. Each rectangle has a screen position, size and encoding type indicating the manner in which the data is coded for sending it across the network. The most common types are:

  • Hextile Encoding: The screen is divided into 16 by 16 sections with each section compressed for fast transfer.
  • Copy Rectangle Encoding: Copies area data from elsewhere on the screen instead of several similar ones from the same area.

Specialized Encodings To Extend The Functionality Further

As if that is not enough, the RFB also allows the usage of special such as JPEG encodings for still images and MPEG for video which all extends its capacity to cater for a wide range of graphical contents. This versatility is among the reasons RFB remains a jewel in remote monitoring systems, powering anything from simple desktop sharing to full-blown RMM systems.

What’s Next?

While this overview highlights RFB’s core structure, there’s even more to the protocol, including flags, specific parameters, and additional encoding schemes. But we’ll save that deep dive for another post—there’s a lot more to uncover in the intricate world of remote computing!