Remote Framebuffer-protocol

Het Remote Framebuffer Protocol ( RFB ) is een netwerkprotocol voor toegang tot de grafische gebruikersinterfaces (GUI) van andere computers . Het wordt gebruikt door VNC om scherminhoud en gebruikersinvoer te verzenden .

Basis principe

Een RFB- server biedt een zogenaamd "scherm". Meestal wordt hier een " desktop " of een enkel programma van een grafische werkomgeving op een externe computer of de bijbehorende applicaties op weergegeven. De RFB- client toont dit bureaublad meestal op de werkstationcomputer van de gebruiker, ontvangt gebruikersinvoer ( toetsenbordinvoer , muisbewegingen en klikken , etc.) en stuurt deze door naar de RFB-server, die daar de werkomgeving aanstuurt .

Omdat het werkt op het niveau van het bitmapgeoriënteerde grafische geheugen ( Engelse framebuffer ), kan het op elk venstersysteem worden gebruikt, zoals Windows , Mac OS of X11 . De scherminhoud wordt als bitmaps verzonden, waarbij meestal alleen de respectievelijke wijzigingen - in geschikte codering, zie hieronder - worden verzonden naar de client. Er zijn kleurdiepten van 8, 16 en 32 bits per pixel ondersteuning. De RFB client vraagt ​​de gewenste kleurdiepte en codering aan bij de server en de server moet zich laten leiden door de wensen van de client, als deze de gewenste codering ondersteunt. Dit ontwerp maakt het mogelijk om de eisen voor de cliënt eenvoudig te houden en zo het gebruik van thin clients te ondersteunen.

RFB-verbindingen zijn staatloos , zodat verbindingsonderbrekingen of wijziging van de RFB-client probleemloos mogelijk zijn zonder dat de bijbehorende sessie verloren gaat. Het uiteindelijke doel van RFB en VNC is het ondersteunen van werken op afstand op computers in een uniforme werkomgeving.

Poort- en desktopnummers

In de originele Unix-versie van VNC is elke VNC-server zijn eigen X-server en vertegenwoordigt precies één X-desktop ( Xvnc ). Het eerste gratis X-servernummer wordt standaard door VNC gebruikt. Als er al een lokale X-server op de machine draait, die dus het X-bureaublad :0bezet, haalt VNC het bureaublad op :1. Het TCP-poortnummer dat wordt ingenomen door VNC is meestal 5901 onder Unix Sommige VNC-servers bieden poort 5800 of een Java-applet waarmee het bureaublad kan worden bekeken en bestuurd met een webbrowser . 5900 + desktopnummer5800 + desktopnummer

Er draait meestal geen lokale X-server onder Windows en Mac OS X , dus VNC bezet het bureaublad en dus het TCP-poortnummer 5900. Deze poort wordt ook gebruikt door het Unix-programma x11vnc , dat de bestaande lokale X-server als VNC-desktop aanbiedt. :0:0

Protocol details

Handdruk en versie-ID's

Zodra de TCP-verbinding tot stand is gebracht, stuurt de server het door hem ondersteunde RFB-versienummer naar de client, waarop de client antwoordt met zijn protocolversienummer. De protocolversie heeft de structuur hoofdversie .secundaire versie . Aangenomen wordt dat de protocolversies met dezelfde hoofdversie compatibel zijn met elkaar. Het grootste versienummer dat door beide partners wordt ondersteund, wordt geacht te zijn overeengekomen voor de volgende verbinding. Het staat elke communicatiepartner echter vrij om de verbinding te verbreken nadat de protocolversie is uitgewisseld als de onderhandelde protocolversie niet voor communicatie kan of mag worden gebruikt.

De versie-ID is altijd een 12-byte lange ASCII- tekenreeks, die wordt beëindigd met een LineFeed- teken. De meest voorkomende versies zijn 3.3, 3.7 en 3.8:

Sommige clients melden ten onrechte een protocolversie 3.5. Dit zou aan de serverkant als versie 3.3 moeten worden behandeld.

Client authenticatie

Als de client en server hebben onderhandeld over een compatibele RFB-versie, stuurt de server het vereiste type authenticatie van de client. In de originele RFB-specificatie zijn twee typen gedefinieerd: "VNC-authenticatie" of "geen authenticatie". Er zijn echter andere soorten authenticatie gedefinieerd door externe fabrikanten. De client beslist welke van de authenticatietypen die door de server worden aangeboden, hij op de server wil authenticeren.

initialisatie

Na succesvolle authenticatie verzendt de client een 1-byte "ClientInit" -bericht. Dit bevat alleen een vlag die aangeeft of de client een "gedeelde" verbinding accepteert, i. Dit betekent dat mogelijke verbindingen van de server naar andere clients zijn toegestaan ​​of (als de vlag is ingesteld op 0) moeten worden beëindigd.

De server stuurt vervolgens een "ServerInit" -bericht. Dit bevat de naam van de desktop (die vaak is afgeleid van de computernaam van de server), de grootte van de desktop (in pixels) en de native kleurdiepte en rangschikking van de pixels aan de serverzijde. De beeldgegevens worden standaard in dit formaat naar de klant gestuurd, tenzij de klant de gegevens in een ander formaat opvraagt ​​dat voor de klant gemakkelijker te verwerken is via een "SetPixelFormat" -bericht.

Data overdracht

De klant bepaalt of en wanneer gegevens moeten worden overgedragen. Het stuurt de lokale toetsenbord- en muisinvoer naar de server. Bovendien stuurt het regelmatig "FramebufferUpdateRequest" -berichten naar de server, die vervolgens de wijzigingen in de scherminhoud (sinds de laatste FramebufferUpdateRequest) naar de client stuurt .

In de originele RFB-versie werden de bewegingen van de muisaanwijzer ook via normale framebuffer-updates naar de client gestuurd. De hoeveelheid over te dragen gegevens is vrij hoog en vooral de bijbehorende latenties bemoeilijken de bediening. Met RFB versie 3.8 is een extensie geïntroduceerd waarmee de muisaanwijzer lokaal door de klant kan worden getekend en alleen het uiterlijk van de muispijl en zijn wijzigingen (bijvoorbeeld wanneer de muispijl over een invoerveld beweegt en vervolgens naar de I Cursor wordt overgedragen aan de klant.

Sinds versie 3.8. een wijziging in de grootte van de desktop wordt naar de klant gestuurd. In eerdere versies moest de server de verbinding met de client verbreken, aangezien de grootte van de desktop alleen in de initialisatiefase van een verbinding naar de client kon worden overgedragen.

web links

• RFC 6143 - Het Remote Framebuffer-protocol