Menu
Home
People
Places
Arts
History
Plants & Animals
Science
Life & Culture
Technology
Reference.org
RFB (protocol)
open-in-new
<h2 id="description">Description</h2> <p>By default, a viewer/client uses TCP port 5900 to connect to a server (or 5800 for browser access), but can also be set to use any other port. Alternatively, a server can connect to a viewer in "listening mode" (by default on port 5500). One advantage of listening mode is that the server site does not have to configure its firewall/NAT to allow access on the specified ports; the burden is on the viewer, which is useful if the server site has no computer expertise, while the viewer user would be expected to be more knowledgeable. </p><p>Although RFB started as a relatively simple protocol, it has been enhanced with additional features (such as file transfers) and more sophisticated <a href="/facts/Data_compression/gMFuY4FT">compression</a> and security techniques as it has developed. To maintain seamless cross-compatibility between the many different VNC client and server implementations, the clients and servers negotiate a connection using the best RFB version, and the most appropriate compression and security options that they can both support. </p> <h2 id="history">History</h2> <p>RFB was originally developed at <a href="/facts/Olivetti_Research_Laboratory/oIrtgc0g">Olivetti Research Laboratory</a> (ORL) as a remote display technology to be used by a simple <a href="/facts/Thin_client/GtBdBho5">thin client</a> with <a href="/facts/Asynchronous_Transfer_Mode/SzA8ewFL">Asynchronous Transfer Mode</a> connectivity called a Videotile. In order to keep the device as simple as possible, RFB was developed and used in preference to any of the existing remote display technologies. </p><p>RFB found a second and more enduring use when VNC was developed. VNC was released as <a href="/facts/Open-source_software/HzTaB8E9">open source</a> software and the RFB specification published on the web. Since then RFB has been a free protocol which anybody can use. </p><p>When ORL was closed in 2002 some of the key people behind VNC and RFB formed <a href="/facts/RealVNC/nPhM8B8s">RealVNC</a>, Ltd., in order to continue development of VNC and to maintain the RFB protocol. The current RFB protocol is published on the <a href="https://help.realvnc.com/hc/en-us/articles/360002720337-RFB-protocol-specification">RealVNC website</a>. </p> <h2 id="versions">Versions</h2> <p>Published versions of the RFB protocol are as follows: </p> <table><tbody><tr><th>Version</th><th>Published</th><th>Date</th><th>Specification</th></tr><tr><td>RFB 3.3</td><td>ORL</td><td>January 1998</td><td><a href="https://web.archive.org/web/20140921005313/http://grox.net/doc/apps/vnc/rfbproto.pdf">The Remote Framebuffer Protocol 3.3</a></td></tr><tr><td>RFB 3.7</td><td>RealVNC Ltd</td><td>August 2003</td><td><a href="https://web.archive.org/web/20040325204925/http://www.realvnc.com/docs/rfbproto.pdf">The Remote Framebuffer Protocol 3.7</a></td></tr><tr><td>RFB 3.8 (current)</td><td>RealVNC Ltd</td><td>June 2007</td><td><a href="https://web.archive.org/web/20070703000012/http://www.realvnc.com/docs/rfbproto.pdf">The Remote Framebuffer Protocol 3.8</a></td></tr><tr><td>IETF RFC (3.8)</td><td>RealVNC Ltd</td><td>March 2011</td><td><a href="/facts/RFC_(identifier)/esftTvE7">RFC</a> <a href="https://www.rfc-editor.org/rfc/rfc6143">6143</a></td></tr></tbody></table> <p>Developers are free to add additional encoding and security types but they must book unique identification numbers for these with the maintainers of the protocol so that the numbers do not clash. Clashing type numbers would cause confusion when handshaking a connection and break cross-compatibility between implementations. The list of encoding and security types was maintained by RealVNC Ltd and is separate from the protocol specification so that new types can be added without requiring the specification to be reissued. Since December 2012, the list went to <a href="/facts/IANA/b6MlP6zQ">IANA</a>.<a class="footnote-ref" id="fnref:1" href="#fn:1"><sup>1</sup></a> </p><p>A community version of the RFB protocol specification which aims to document all existing extensions is hosted by the <a href="/facts/TigerVNC/t5KJ7FTD">TigerVNC</a> project.<a class="footnote-ref" id="fnref:2" href="#fn:2"><sup>2</sup></a> </p> <h2 id="encoding-types">Encoding types</h2> <p>Multiple encodings are part of the negotiation. Some of the encodings are pseudo-encodings used to advertise the ability to handle a certain extension. Encodings include:<a class="footnote-ref" id="fnref:3" href="#fn:3"><sup>3</sup></a> </p> <ul><li>Raw</li> <li>Zlib</li> <li>Tight</li> <li>XZ</li> <li><a href="/facts/H.264/soCzKcmJ">H.264</a></li> <li>Tight PNG</li></ul> <p>Of the publicly-defined picture-based encodings, the most efficient ones are the Tight encoding types. Two types of encodings are defined by TightVNC: Tight Encoding (a mixture of rectangle, palette and gradient filling with zlib and JPEG, plus a Zlib-plus-filter "basic compression")<a class="footnote-ref" id="fnref:4" href="#fn:4"><sup>4</sup></a> and Tight PNG Encoding (Tight encoding with basic compression replaced with <a href="/facts/Portable_Network_Graphics/mwgK6xw5">PNG</a> data). </p><p><a href="/facts/H.264/soCzKcmJ">H.264</a> has been researched for encoding RFB data, but the preliminary results (using Open H.264 format) were described as lackluster by a <a href="/facts/TurboVNC/8tmBSCFz">TurboVNC</a> developer. It does become more efficient with fewer I-frames (keyframes), but CPU utilization remains a problem.<a class="footnote-ref" id="fnref:5" href="#fn:5"><sup>5</sup></a> </p> <h2 id="limitations">Limitations</h2> <p>In terms of transferring clipboard data, "there is currently no way to transfer text outside the Latin-1 character set".<a class="footnote-ref" id="fnref:6" href="#fn:6"><sup>6</sup></a> A common pseudo-encoding extension solves the problem by using <a href="/facts/UTF-8/xlaVHSyf">UTF-8</a> in an extended format.<a class="footnote-ref" id="fnref:7" href="#fn:7"><sup>7</sup></a>: § 7.7.27 </p><p>The VNC protocol is pixel based. Although this leads to great flexibility (i.e. any type of desktop can be displayed), it is often less efficient than solutions that have a better understanding of the underlying graphic layout like <a href="/facts/X11/ac2vRIQL">X11</a> or desktop such as <a href="/facts/Remote_Desktop_Protocol/A5e9ILdI">RDP</a>. Those protocols send graphic primitives or high level commands in a simpler form (e.g. open window), whereas RFB just sends the raw pixel data, albeit compressed. </p><p>The VNC protocol expresses mouse button state in a single byte, as binary up/down. This limits the number of mouse buttons to eight (effectively 7 given convention of button 0 meaning "disabled"). Many modern mice enumerate 9 or more buttons, leading to forward/back buttons having no effect over RFB. A "GII" extension solves this problem.<a class="footnote-ref" id="fnref:8" href="#fn:8"><sup>8</sup></a>: § 7.7.11 </p><p>The original protocol specification does not define any way to transfer sound data at all, with the sole exception that the server may signal a <a href="/facts/Bell_character/yvPIWNMr">bell</a> (audible beep, notification sound) should be played by the client.<a class="footnote-ref" id="fnref:9" href="#fn:9"><sup>9</sup></a>: § 7.6.3 There is, however, a "QEMU Audio" extension defined in the RFB protocol's community version.<a class="footnote-ref" id="fnref:10" href="#fn:10"><sup>10</sup></a> </p> <h2 id="see-also">See also</h2> <ul><li><a href="/facts/Comparison_of_remote_desktop_software/fQ4kqmaf">Comparison of remote desktop software</a></li> <li><a href="/facts/NX_technology/60sQIeQg">NX technology</a> and <a href="/facts/Xpra/KCVms72z">Xpra</a> for efficient remote X Window System connections</li> <li><a href="/facts/SPICE_(protocol)/J1PfQBUP">SPICE</a></li> <li><a href="/facts/Remote_Desktop_Protocol/A5e9ILdI">Remote Desktop Protocol</a> (RDP)</li></ul> <h2 id="external-links">External links</h2> <ul><li><a href="https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst">The RFB Protocol - Community Version</a></li> <li><a href="https://tools.ietf.org/html/rfc6143">RFC 6143: The Remote Framebuffer Protocol (describes Version 3.8, 2011)</a></li> <li><a href="https://web.archive.org/web/20160410055332/http://www.realvnc.com/docs/rfbproto.pdf">The RFB Protocol - Version 3.8 (2010-11-26)</a></li> <li><a href="https://web.archive.org/web/20040325204925/http://www.realvnc.com/docs/rfbproto.pdf">The RFB Protocol - Version 3.7 (2003-08-12)</a></li> <li><a href="http://grox.net/doc/apps/vnc/rfbproto.pdf">The RFB Protocol - Version 3.3 (1998-01)</a></li></ul> <h2 id="references">References</h2> <ol> <li id="fn:1"><p>"Remote Framebuffer (RFB)". www.iana.org. <a href="https://www.iana.org/assignments/rfb/rfb.xml" target="_blank">https://www.iana.org/assignments/rfb/rfb.xml</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></p></li> <li id="fn:2"><p>"The RFB Protocol, Community Edition". GitHub. 12 May 2025. <a href="https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst" target="_blank">https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst</a> <a href="#fnref:2" class="footnote-back-ref">↩</a></p></li> <li id="fn:3"><p>"The RFB Protocol, Community Edition". GitHub. 12 May 2025. <a href="https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst" target="_blank">https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst</a> <a href="#fnref:3" class="footnote-back-ref">↩</a></p></li> <li id="fn:4"><p>"VNC Tight Encoder - Comparison Results". www.tightvnc.com. <a href="https://www.tightvnc.com/archive/compare.html" target="_blank">https://www.tightvnc.com/archive/compare.html</a> <a href="#fnref:4" class="footnote-back-ref">↩</a></p></li> <li id="fn:5"><p>Commander, DR. "A Study on the Usefulness of H.264 Encoding in a VNC Environment". turbovnc.org. <a href="https://turbovnc.org/About/H264" target="_blank">https://turbovnc.org/About/H264</a> <a href="#fnref:5" class="footnote-back-ref">↩</a></p></li> <li id="fn:6"><p>Richardson, Tristan (2010). "Sections 6.4.6, 6.5.4". The RFB Protocol - Version 3.8. <a href="#fnref:6" class="footnote-back-ref">↩</a></p></li> <li id="fn:7"><p>"The RFB Protocol, Community Edition". GitHub. 12 May 2025. <a href="https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst" target="_blank">https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst</a> <a href="#fnref:7" class="footnote-back-ref">↩</a></p></li> <li id="fn:8"><p>"The RFB Protocol, Community Edition". GitHub. 12 May 2025. <a href="https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst" target="_blank">https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst</a> <a href="#fnref:8" class="footnote-back-ref">↩</a></p></li> <li id="fn:9"><p>"The RFB Protocol, Community Edition". GitHub. 12 May 2025. <a href="https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst" target="_blank">https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst</a> <a href="#fnref:9" class="footnote-back-ref">↩</a></p></li> <li id="fn:10"><p>"The RFB Protocol, Community Edition". GitHub. 12 May 2025. <a href="https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst" target="_blank">https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst</a> <a href="#fnref:10" class="footnote-back-ref">↩</a></p></li> </ol>