TheRFBProtocolTristanRichardsonRealVNCLtd(formerlyofOlivettiResearchLtd/AT&TLabsCambridge)∗Version3.8Lastupdated28August2008Contents1Introduction32DisplayProtocol33InputProtocol44Representationofpixeldata45Protocolextensions56ProtocolMessages56.1HandshakingMessages.........................76.1.1ProtocolVersion.........................86.1.2Security.............................96.1.3SecurityResult.........................116.2SecurityTypes..............................126.2.1None..............................136.2.2VNCAuthentication......................146.3InitialisationMessages.........................156.3.1ClientInit............................166.3.2ServerInit............................176.4Clienttoservermessages........................19∗JamesWeatherall,AndyHarterandKenWoodalsohelpedinthedesignoftheRFBprotocol1CONTENTS26.4.1SetPixelFormat.........................206.4.2SetEncodings..........................216.4.3FramebufferUpdateRequest..................226.4.4KeyEvent............................236.4.5PointerEvent..........................256.4.6ClientCutText..........................266.5Servertoclientmessages........................276.5.1FramebufferUpdate.......................286.5.2SetColourMapEntries......................296.5.3Bell...............................306.5.4ServerCutText.........................316.6Encodings................................326.6.1Rawencoding..........................336.6.2CopyRectencoding.......................346.6.3RREencoding.........................356.6.4Hextileencoding........................366.6.5ZRLEencoding.........................386.7Pseudo-encodings............................416.7.1Cursorpseudo-encoding....................426.7.2DesktopSizepseudo-encoding.................431INTRODUCTION31IntroductionRFB(“remoteframebuffer”)isasimpleprotocolforremoteaccesstographicaluserinterfaces.Becauseitworksattheframebufferlevelitisapplicabletoallwindow-ingsystemsandapplications,includingX11,WindowsandMacintosh.RFBistheprotocolusedinVNC(VirtualNetworkComputing).Theremoteendpointwheretheusersits(i.e.thedisplaypluskeyboardand/orpointer)iscalledtheRFBclientorviewer.Theendpointwherechangestotheframebufferoriginate(i.e.thewindowingsystemandapplications)isknownastheRFBserver.RFBServerRFBClientRFBProtocolRFBistrulya“thinclient”protocol.TheemphasisinthedesignoftheRFBprotocolistomakeveryfewrequirementsoftheclient.Inthisway,clientscanrunonthewidestrangeofhardware,andthetaskofimplementingaclientismadeassimpleaspossible.Theprotocolalsomakestheclientstateless.Ifaclientdisconnectsfromagivenserverandsubsequentlyreconnectstothatsameserver,thestateoftheuserinterfaceispre-served.Furthermore,adifferentclientendpointcanbeusedtoconnecttothesameRFBserver.Atthenewendpoint,theuserwillseeexactlythesamegraphicaluserinterfaceasattheoriginalendpoint.Ineffect,theinterfacetotheuser’sapplica-tionsbecomescompletelymobile.Whereversuitablenetworkconnectivityexists,theusercanaccesstheirownpersonalapplications,andthestateoftheseapplicationsispreservedbetweenaccessesfromdifferentlocations.Thisprovidestheuserwithafamiliar,uniformviewofthecomputinginfrastructurewherevertheygo.2DisplayProtocolThedisplaysideoftheprotocolisbasedaroundasinglegraphicsprimitive:“putarectangleofpixeldataatagivenx,yposition”.Atfirstglancethismightseem3INPUTPROTOCOL4aninefficientwayofdrawingmanyuserinterfacecomponents.However,allowingvariousdifferentencodingsforthepixeldatagivesusalargedegreeofflexibilityinhowtotradeoffvariousparameterssuchasnetworkbandwidth,clientdrawingspeedandserverprocessingspeed.Asequenceoftheserectanglesmakesaframebufferupdate(orsimplyupdate).Anupdaterepresentsachangefromonevalidframebufferstatetoanother,soinsomewaysissimilartoaframeofvideo.Therectanglesinanupdateareusuallydisjointbutthisisnotnecessarilythecase.Theupdateprotocolisdemand-drivenbytheclient.Thatis,anupdateisonlysentfromtheservertotheclientinresponsetoanexplicitrequestfromtheclient.Thisgivestheprotocolanadaptivequality.Theslowertheclientandthenetworkare,thelowertherateofupdatesbecomes.Withtypicalapplications,changestothesameareaoftheframebuffertendtohappensoonafteroneanother.Withaslowclientand/ornetwork,transientstatesoftheframebuffercanbeignored,resultinginlessnetworktrafficandlessdrawingfortheclient.3InputProtocolTheinputsideoftheprotocolisbasedonastandardworkstationmodelofakeyboardandmulti-buttonpointingdevice.Inputeventsaresimplysenttotheserverbytheclientwhenevertheuserpressesakeyorpointerbutton,orwheneverthepointingdeviceismoved.Theseinputeventscanalsobesynthesisedfromothernon-standardI/Odevices.Forexample,apen-basedhandwritingrecognitionenginemightgeneratekeyboardevents.4RepresentationofpixeldataInitialinteractionbetweentheRFBclientandserverinvolvesanegotiationofthefor-matandencodingwithwhichpixeldatawillbesent.Thisnegotiationhasbeende-signedtomakethejoboftheclientaseasyaspossible.Thebottomlineisthattheservermustalwaysbeabletosupplypixeldataintheformtheclientwants.Howeveriftheclientisabletocopeequallywithseveraldifferentformatsorencodings,