Remote Framebuffer Protocol - Versionsgeschichte

Crazy1880: Vorlagen-fix (RFC)

2023-05-27T10:30:02Z

Vorlagen-fix (RFC)

← Nächstältere Version		Version vom 27. Mai 2023, 12:30 Uhr
Zeile 1:		Zeile 1:
	{\| class="wikitable float-right"		{\| class="wikitable float-right"
	\|-		\|-
	!colspan="2" style="background:#C0C0FF; font-size:larger;"\| RFB (Remote Framebuffer Protocol)		! colspan="2" style="background:#C0C0FF; font-size:larger;"\| RFB (Remote Framebuffer Protocol)
	\|-		\|-
	\| '''Familie:'''		\| '''Familie:'''
Zeile 64:		Zeile 64:

	== Weblinks ==		== Weblinks ==
	* RFC ~~6143~~ – ''The Remote Framebuffer Protocol''		* {{RFC-Internet \|Autor=T. Richardson, J. Levine \|RFC=6143 \|Titel=The Remote Framebuffer Protocol \|Datum=2011-03}}

	[[Kategorie:Netzwerkprotokoll auf Anwendungsschicht]]		[[Kategorie:Netzwerkprotokoll auf Anwendungsschicht]]

Orthographus: Komma

2020-01-13T12:26:56Z

Komma

← Nächstältere Version		Version vom 13. Januar 2020, 14:26 Uhr
Zeile 52:		Zeile 52:

	=== Initialisierung ===		=== Initialisierung ===
	Nach erfolgreicher Authentifizierung sendet der Client eine 1 Byte große „ClientInit“-Nachricht. Diese enthält lediglich ein Flag, ob der Client eine „shared“ Verbindung akzeptiert, d. h. dass eventuelle Verbindungen des Servers zu anderen Clients erlaubt sind oder (falls das Flag auf 0 ist) beendet werden sollen.		Nach erfolgreicher Authentifizierung sendet der Client eine 1 Byte große „ClientInit“-Nachricht. Diese enthält lediglich ein Flag, ob der Client eine „shared“ Verbindung akzeptiert, d. h., dass eventuelle Verbindungen des Servers zu anderen Clients erlaubt sind oder (falls das Flag auf 0 ist) beendet werden sollen.

	Anschließend sendet der Server eine „ServerInit“-Nachricht. Diese enthält den Namen des Desktops (der oft aus dem Rechnernamen des Servers abgeleitet wird), die Größe des Desktops (in Pixeln) und die native Farbtiefe und Anordnung der Pixel auf Serverseite. Die Bilddaten werden standardmäßig in diesem Format zum Client übertragen, außer der Client fordert über eine „SetPixelFormat“-Nachricht die Daten in einem anderen, für den Client einfacher zu verarbeitenden Format an.		Anschließend sendet der Server eine „ServerInit“-Nachricht. Diese enthält den Namen des Desktops (der oft aus dem Rechnernamen des Servers abgeleitet wird), die Größe des Desktops (in Pixeln) und die native Farbtiefe und Anordnung der Pixel auf Serverseite. Die Bilddaten werden standardmäßig in diesem Format zum Client übertragen, außer der Client fordert über eine „SetPixelFormat“-Nachricht die Daten in einem anderen, für den Client einfacher zu verarbeitenden Format an.

PerfektesChaos: tk k

2017-04-01T09:49:04Z

tk k

← Nächstältere Version		Version vom 1. April 2017, 11:49 Uhr
Zeile 9:		Zeile 9:
	\| Datenübertragung,<br />Bildschirminhalte, Benutzereingaben		\| Datenübertragung,<br />Bildschirminhalte, Benutzereingaben
	\|-		\|-
	\| '''Port:''' \|\| 5900/TCP (Siehe [[#Port-~~_und_Desktopnummern~~\|Text]])		\| '''Port:''' \|\| 5900/TCP (Siehe [[#Port- und Desktopnummern\|Text]])
	\|-		\|-
			\|colspan="2" style="text-align:center"\|
	\|align="center" colspan="2" \|
	{{Netzwerk-TCP-IP-Anwendungsprotokoll\|RFB\|}}		{{Netzwerk-TCP-IP-Anwendungsprotokoll\|RFB\|}}
	\|}		\|}
Zeile 20:		Zeile 20:
	Ein RFB-[[Server (Software)\|Server]] bietet einen so genannten „Screen“ an. Üblicherweise ist auf diesem ein „[[Desktop (grafische Benutzeroberfläche)\|Desktop]]“ oder ein einzelnes Programm einer grafischen Arbeitsumgebung dargestellt, der auf einem entfernten Computer läuft bzw. die dazugehörigen Anwendungen. Der RFB-[[Client]] stellt in der Regel diesen Desktop auf dem Arbeitsplatzrechner des Benutzers dar, nimmt Benutzereingaben ([[Tastatureingabe]]n, [[Mausbewegung]]en und -[[Mausklick\|klicks]] usw.) entgegen und leitet diese an den RFB-Server weiter, womit die dortige Arbeitsumgebung gesteuert wird.		Ein RFB-[[Server (Software)\|Server]] bietet einen so genannten „Screen“ an. Üblicherweise ist auf diesem ein „[[Desktop (grafische Benutzeroberfläche)\|Desktop]]“ oder ein einzelnes Programm einer grafischen Arbeitsumgebung dargestellt, der auf einem entfernten Computer läuft bzw. die dazugehörigen Anwendungen. Der RFB-[[Client]] stellt in der Regel diesen Desktop auf dem Arbeitsplatzrechner des Benutzers dar, nimmt Benutzereingaben ([[Tastatureingabe]]n, [[Mausbewegung]]en und -[[Mausklick\|klicks]] usw.) entgegen und leitet diese an den RFB-Server weiter, womit die dortige Arbeitsumgebung gesteuert wird.

	Da es auf der Ebene des [[Rastergrafik\|bitmaporientierten]] [[Grafikspeicher]]s (~~[[Englische Sprache~~\|~~engl.]]~~ Framebuffer) arbeitet, ist die Anwendung auf beliebigen Fenstersystemen wie [[Windows]], [[Mac OS]] oder [[X11]] möglich. Die Bildschirminhalte werden als Bitmaps übertragen, wobei in der Regel nur die jeweiligen Änderungen – in geeigneter Kodierung, siehe unten – zum Client übertragen werden. Es werden [[Farbtiefe (Computergrafik)\|Farbtiefen]] von 8, 16 und 32 Bit pro [[Pixel]] unterstützt, wobei der RFB-Client die gewünschte Farbtiefe und Kodierung vom Server anfordert und der Server sich nach den Wünschen des Clients zu richten hat, sofern er die gewünschte Kodierung unterstützt. Dieses Design erlaubt es, die Anforderungen an den Client einfach zu halten und so die Verwendung von [[Thin Client]]s zu unterstützen.		Da es auf der Ebene des [[Rastergrafik\|bitmaporientierten]] [[Grafikspeicher]]s ({{enS\|Framebuffer}}) arbeitet, ist die Anwendung auf beliebigen Fenstersystemen wie [[Windows]], [[Mac OS]] oder [[X11]] möglich. Die Bildschirminhalte werden als Bitmaps übertragen, wobei in der Regel nur die jeweiligen Änderungen – in geeigneter Kodierung, siehe unten – zum Client übertragen werden. Es werden [[Farbtiefe (Computergrafik)\|Farbtiefen]] von 8, 16 und 32 Bit pro [[Pixel]] unterstützt, wobei der RFB-Client die gewünschte Farbtiefe und Kodierung vom Server anfordert und der Server sich nach den Wünschen des Clients zu richten hat, sofern er die gewünschte Kodierung unterstützt. Dieses Design erlaubt es, die Anforderungen an den Client einfach zu halten und so die Verwendung von [[Thin Client]]s zu unterstützen.

	RFB-Verbindungen sind [[Zustandslosigkeit\|zustandslos]], sodass Verbindungsunterbrechungen bzw. der Wechsel des RFB-Clients problemlos möglich sind, ohne dass die zugehörige Sitzung dabei verloren geht. Ziel von RFB und VNC ist letztendlich die Unterstützung des entfernten Arbeitens an Rechnern unter einer einheitlichen Arbeitsumgebung.		RFB-Verbindungen sind [[Zustandslosigkeit\|zustandslos]], sodass Verbindungsunterbrechungen bzw. der Wechsel des RFB-Clients problemlos möglich sind, ohne dass die zugehörige Sitzung dabei verloren geht. Ziel von RFB und VNC ist letztendlich die Unterstützung des entfernten Arbeitens an Rechnern unter einer einheitlichen Arbeitsumgebung.
Zeile 31:		Zeile 31:
	== Protokoll-Details ==		== Protokoll-Details ==
	=== Handshake & Versionskennungen ===		=== Handshake & Versionskennungen ===
	Sobald die TCP-Verbindung aufgebaut ist, sendet der Server die von ihm unterstützte RFB-Versionsnummer zum Client, worauf dieser mit seiner Protokollversionsnummer antwortet. Die Protokollversion hat den Aufbau ~~<code>~~''hauptversion''~~'''~~.~~'''~~''nebenversion''~~</code>~~. Es wird davon ausgegangen, dass die Protokollversionen mit gleicher Hauptversion untereinander kompatibel sind. Die größte von beiden Partnern unterstützte Versionsnummer gilt für die nachfolgende Verbindung als vereinbart. Es steht aber jedem Kommunikationspartner frei, nach dem Austausch der Protokollversionen die Verbindung zu beenden, wenn mit der ausgehandelten Protokollversion nicht kommuniziert werden kann oder soll.		Sobald die TCP-Verbindung aufgebaut ist, sendet der Server die von ihm unterstützte RFB-Versionsnummer zum Client, worauf dieser mit seiner Protokollversionsnummer antwortet. Die Protokollversion hat den Aufbau ''hauptversion''<code>.</code>''nebenversion''. Es wird davon ausgegangen, dass die Protokollversionen mit gleicher Hauptversion untereinander kompatibel sind. Die größte von beiden Partnern unterstützte Versionsnummer gilt für die nachfolgende Verbindung als vereinbart. Es steht aber jedem Kommunikationspartner frei, nach dem Austausch der Protokollversionen die Verbindung zu beenden, wenn mit der ausgehandelten Protokollversion nicht kommuniziert werden kann oder soll.

	Die Versionskennung ist stets ein 12 Byte langer [[American Standard Code for Information Interchange\|ASCII]]-String, welcher mit einem [[Zeilenumbruch\|LineFeed]]-Zeichen abgeschlossen wird. Die gebräuchlichsten Versionen sind 3.3, 3.7 und 3.8:		Die Versionskennung ist stets ein 12 Byte langer [[American Standard Code for Information Interchange\|ASCII]]-String, welcher mit einem [[Zeilenumbruch\|LineFeed]]-Zeichen abgeschlossen wird. Die gebräuchlichsten Versionen sind 3.3, 3.7 und 3.8:

	:{\| class="wikitable"		{\| class="wikitable"
	\|+ RFB Versionskennungen		\|+ RFB Versionskennungen
	!Version!!Kennung!!Kennung (hex)!!Veröffentlicht		!Version!!Kennung!!Kennung (hex)!!Veröffentlicht
	\|-		\|-
	\|\|3.3 \|\| <code>RFB 003.003\n</code> \|\| <code style="white-space: nowrap">52 46 42 20 30 30 33 2E 30 30 33 0A</code> \|\| Januar 1998 von Olivetti Research Laboratories (ORL)		\|\|3.3 \|\| <code>RFB 003.003\n</code> \|\| <code style="white-space:nowrap">52 46 42 20 30 30 33 2E 30 30 33 0A</code> \|\| Januar 1998 von Olivetti Research Laboratories (ORL)
	\|-		\|-
	\|\|3.7 \|\| <code>RFB 003.007\n</code> \|\| <code>52 46 42 20 30 30 33 2E 30 30 37 0A</code> \|\| Juli 2003 von RealVNC Ltd.		\|\|3.7 \|\| <code>RFB 003.007\n</code> \|\| <code>52 46 42 20 30 30 33 2E 30 30 37 0A</code> \|\| Juli 2003 von RealVNC Ltd.
Zeile 49:		Zeile 49:

	=== Client-Authentifizierung ===		=== Client-Authentifizierung ===
	Sofern Client und Server eine kompatible RFB-Version ausgehandelt haben, sendet der Server, welche Art von Authentifizierung er vom Client verlangt. In der originalen RFB-Spezifikation sind zwei Arten definiert: ~~"VNC~~ ~~Authentifizierung"~~ oder ~~"keine~~ ~~Authentifizierung"~~. Es sind aber weitere Authentifizierungsarten von Drittherstellern definiert worden. Der Client entscheidet, über welche der vom Server angebotenen Authentifizierungsarten er sich am Server authentifizieren will.		Sofern Client und Server eine kompatible RFB-Version ausgehandelt haben, sendet der Server, welche Art von Authentifizierung er vom Client verlangt. In der originalen RFB-Spezifikation sind zwei Arten definiert: „VNC Authentifizierung“ oder „keine Authentifizierung“. Es sind aber weitere Authentifizierungsarten von Drittherstellern definiert worden. Der Client entscheidet, über welche der vom Server angebotenen Authentifizierungsarten er sich am Server authentifizieren will.

	=== Initialisierung ===		=== Initialisierung ===
	Nach erfolgreicher Authentifizierung sendet der Client eine 1 Byte große ~~"ClientInit"~~-Nachricht. Diese enthält lediglich ein Flag, ob der Client eine ~~"shared"~~ Verbindung akzeptiert, d.h. dass eventuelle Verbindungen des Servers zu anderen Clients erlaubt sind oder (falls das Flag auf 0 ist) beendet werden sollen.		Nach erfolgreicher Authentifizierung sendet der Client eine 1 Byte große „ClientInit“-Nachricht. Diese enthält lediglich ein Flag, ob der Client eine „shared“ Verbindung akzeptiert, d. h. dass eventuelle Verbindungen des Servers zu anderen Clients erlaubt sind oder (falls das Flag auf 0 ist) beendet werden sollen.

	Anschließend sendet der Server eine ~~"ServerInit"~~-Nachricht. Diese enthält den Namen des Desktops (der oft aus dem Rechnernamen des Servers abgeleitet wird), die Größe des Desktops (in Pixeln) und die native Farbtiefe und Anordnung der Pixel auf Serverseite. Die Bilddaten werden standardmäßig in diesem Format zum Client übertragen, außer der Client fordert über eine ~~"SetPixelFormat"~~-Nachricht die Daten in einem anderen, für den Client einfacher zu verarbeitenden Format an.		Anschließend sendet der Server eine „ServerInit“-Nachricht. Diese enthält den Namen des Desktops (der oft aus dem Rechnernamen des Servers abgeleitet wird), die Größe des Desktops (in Pixeln) und die native Farbtiefe und Anordnung der Pixel auf Serverseite. Die Bilddaten werden standardmäßig in diesem Format zum Client übertragen, außer der Client fordert über eine „SetPixelFormat“-Nachricht die Daten in einem anderen, für den Client einfacher zu verarbeitenden Format an.

	=== Datenübertragung ===		=== Datenübertragung ===
	Der Client steuert, ob und wann Daten übertragen werden sollen. Er sendet die lokalen Tastatur- und Mauseingaben an den Server. Außerdem sendet er regelmäßig ~~"FramebufferUpdateRequest"~~-Nachrichten an den Server, der daraufhin die ''Änderungen'' des Bildschirminhaltes (seit dem letzten FramebufferUpdateRequest) an den Client sendet.		Der Client steuert, ob und wann Daten übertragen werden sollen. Er sendet die lokalen Tastatur- und Mauseingaben an den Server. Außerdem sendet er regelmäßig „FramebufferUpdateRequest“-Nachrichten an den Server, der daraufhin die ''Änderungen'' des Bildschirminhaltes (seit dem letzten FramebufferUpdateRequest) an den Client sendet.

	In der ursprünglichen RFB-Version wurden auch die Bewegungen des Mauszeigers über normale FramebufferUpdates an den Client geschickt. Dabei ist die zu übertragene Datenmenge recht hoch und vor allem die damit verbundenen Latenzen erschweren die Bedienung. Mit RFB-Version 3.8 wurde eine Erweiterung eingeführt, die es erlaubt, dass der Mauszeiger vom Client lokal gezeichnet wird und vom Server lediglich das Aussehen des Mauspfeils und dessen Änderungen (z. B. wenn sich der Mauspfeil über ein Eingabefeld bewegt und dann zum I-Cursor wird) an den Client übertragen werden.		In der ursprünglichen RFB-Version wurden auch die Bewegungen des Mauszeigers über normale FramebufferUpdates an den Client geschickt. Dabei ist die zu übertragene Datenmenge recht hoch und vor allem die damit verbundenen Latenzen erschweren die Bedienung. Mit RFB-Version 3.8 wurde eine Erweiterung eingeführt, die es erlaubt, dass der Mauszeiger vom Client lokal gezeichnet wird und vom Server lediglich das Aussehen des Mauspfeils und dessen Änderungen (z. B. wenn sich der Mauspfeil über ein Eingabefeld bewegt und dann zum I-Cursor wird) an den Client übertragen werden.
Zeile 64:		Zeile 64:

	== Weblinks ==		== Weblinks ==
	* RFC 6143 – The Remote Framebuffer Protocol		* RFC 6143 – ''The Remote Framebuffer Protocol''

	[[Kategorie:Netzwerkprotokoll auf Anwendungsschicht]]		[[Kategorie:Netzwerkprotokoll auf Anwendungsschicht]]

Sivizius: /* Handshake & Versionskennungen */

2016-11-28T13:23:57Z

Handshake & Versionskennungen:

← Nächstältere Version		Version vom 28. November 2016, 15:23 Uhr
Zeile 39:		Zeile 39:
	!Version!!Kennung!!Kennung (hex)!!Veröffentlicht		!Version!!Kennung!!Kennung (hex)!!Veröffentlicht
	\|-		\|-
	\|\|3.3 \|\| <code>RFB 003.003\n</code> \|\| <code style="white-space: nowrap">52 46 42 20 30 30 33 2E 30 30 33 0A</code> \|\| Januar 1998 von Olivetti Research Laboratories (ORL)		\|\|3.3 \|\| <code>RFB 003.003\n</code> \|\| <code style="white-space: nowrap">52 46 42 20 30 30 33 2E 30 30 33 0A</code> \|\| Januar 1998 von Olivetti Research Laboratories (ORL)
	\|-		\|-
	\|\|3.7 \|\| <code>RFB 003.007\n</code> \|\| <code>52 46 42 20 30 30 33 2E 30 30 37 0A</code> \|\| Juli 2003 von RealVNC Ltd.		\|\|3.7 \|\| <code>RFB 003.007\n</code> \|\| <code>52 46 42 20 30 30 33 2E 30 30 37 0A</code> \|\| Juli 2003 von RealVNC Ltd.
	\|-		\|-
	\|\|3.8 \|\| <code>RFB 003.008\n</code> \|\| <code>52 46 42 20 30 30 33 2E 30 30 38 0A</code> \|\| Juli 2005 von RealVNC Ltd.		\|\|3.8 \|\| <code>RFB 003.008\n</code> \|\| <code>52 46 42 20 30 30 33 2E 30 30 38 0A</code> \|\| Juli 2005 von RealVNC Ltd.
	\|}		\|}

Stefan Weil: /* Weblinks */ alten Link entfernt (Inhalt war offenbar weitgehend identisch mit RFC 6143)

2016-11-16T08:04:45Z

Weblinks: alten Link entfernt (Inhalt war offenbar weitgehend identisch mit RFC 6143)

← Nächstältere Version		Version vom 16. November 2016, 10:04 Uhr
Zeile 64:		Zeile 64:

	== Weblinks ==		== Weblinks ==
	* [http://www.realvnc.com/docs/rfbproto.pdf Protokollspezifikation RFB 3.3 bis 3.8] (PDF; 139 kB; englisch)
	* RFC 6143 – The Remote Framebuffer Protocol		* RFC 6143 – The Remote Framebuffer Protocol

RokerHRO: /* Datenübertragung */

2016-03-15T18:35:40Z

Datenübertragung

← Nächstältere Version		Version vom 15. März 2016, 20:35 Uhr
Zeile 57:		Zeile 57:

	=== Datenübertragung ===		=== Datenübertragung ===
	Der Client steuert, ob und wann Daten übertragen werden sollen. Er sendet die lokalen Tastatur- und Mauseingaben an den Server. Außerdem sendet er regelmäßig "FramebufferUpdateRequest"-Nachrichten an den Server, der daraufhin die ''Änderungen'' des Bildschirminhaltes an den Client sendet.		Der Client steuert, ob und wann Daten übertragen werden sollen. Er sendet die lokalen Tastatur- und Mauseingaben an den Server. Außerdem sendet er regelmäßig "FramebufferUpdateRequest"-Nachrichten an den Server, der daraufhin die ''Änderungen'' des Bildschirminhaltes (seit dem letzten FramebufferUpdateRequest) an den Client sendet.

	In der ursprünglichen RFB-Version wurden auch die ~~Updates~~ des Mauszeigers über normale FramebufferUpdates an den Client geschickt. Dabei ist die zu übertragene Datenmenge recht hoch und die damit verbundenen Latenzen erschweren die Bedienung. Mit RFB-Version 3.8 wurde eine Erweiterung eingeführt, die es erlaubt, dass der Mauszeiger vom Client lokal gezeichnet wird und vom Server lediglich das Aussehen des Mauspfeils und dessen Änderungen (z. B. wenn sich der Mauspfeil über ein Eingabefeld bewegt und dann zum I-Cursor wird) an den Client übertragen werden.		In der ursprünglichen RFB-Version wurden auch die Bewegungen des Mauszeigers über normale FramebufferUpdates an den Client geschickt. Dabei ist die zu übertragene Datenmenge recht hoch und vor allem die damit verbundenen Latenzen erschweren die Bedienung. Mit RFB-Version 3.8 wurde eine Erweiterung eingeführt, die es erlaubt, dass der Mauszeiger vom Client lokal gezeichnet wird und vom Server lediglich das Aussehen des Mauspfeils und dessen Änderungen (z. B. wenn sich der Mauspfeil über ein Eingabefeld bewegt und dann zum I-Cursor wird) an den Client übertragen werden.

	Ebenso kann seit Version 3.8. eine Änderung an der Größe des Desktops an den Client übertragen werden. Bei früheren Versionen musste der Server die Verbindung zum Client beenden, da nur in der Initialisierungsphase einer Verbindung die Größe des Desktops an den Client übertragen werden konnte.		Ebenso kann seit Version 3.8. eine Änderung an der Größe des Desktops an den Client übertragen werden. Bei früheren Versionen musste der Server die Verbindung zum Client beenden, da nur in der Initialisierungsphase einer Verbindung die Größe des Desktops an den Client übertragen werden konnte.

RokerHRO: /* Grundprinzip */ etwas umformuliert, ein paar Kommas …

2016-03-15T18:25:29Z

Grundprinzip: etwas umformuliert, ein paar Kommas …

← Nächstältere Version		Version vom 15. März 2016, 20:25 Uhr
Zeile 18:		Zeile 18:

	== Grundprinzip ==		== Grundprinzip ==
	Ein RFB-[[Server (Software)\|Server]] bietet einen so genannten „[[Desktop (grafische Benutzeroberfläche)\|Desktop]]“ ~~an.~~ ~~Dies~~ ~~ist~~ ~~eine~~ ~~grafische~~ Arbeitsumgebung, ~~die~~ auf einem entfernten Computer läuft bzw. die dazugehörigen Anwendungen. Der RFB-[[Client]] stellt in der Regel diesen Desktop auf dem Arbeitsplatzrechner des Benutzers dar, nimmt Benutzereingaben ([[Tastatureingabe]]n, [[Mausbewegung]]en und -[[Mausklick\|klicks]] usw.) entgegen und leitet diese an den RFB-Server weiter, womit die dortige Arbeitsumgebung gesteuert wird.		Ein RFB-[[Server (Software)\|Server]] bietet einen so genannten „Screen“ an. Üblicherweise ist auf diesem ein „[[Desktop (grafische Benutzeroberfläche)\|Desktop]]“ oder ein einzelnes Programm einer grafischen Arbeitsumgebung dargestellt, der auf einem entfernten Computer läuft bzw. die dazugehörigen Anwendungen. Der RFB-[[Client]] stellt in der Regel diesen Desktop auf dem Arbeitsplatzrechner des Benutzers dar, nimmt Benutzereingaben ([[Tastatureingabe]]n, [[Mausbewegung]]en und -[[Mausklick\|klicks]] usw.) entgegen und leitet diese an den RFB-Server weiter, womit die dortige Arbeitsumgebung gesteuert wird.

	Da es auf der Ebene des [[Rastergrafik\|bitmaporientierten]] [[Grafikspeicher]]s ([[Englische Sprache\|engl.]] Framebuffer) arbeitet, ist die Anwendung auf beliebigen Fenstersystemen wie [[Windows]], [[Mac OS]] oder [[X11]] möglich. Die Bildschirminhalte werden als Bitmaps übertragen, wobei nur die jeweiligen Änderungen – in geeigneter Kodierung, siehe unten – zum Client übertragen werden. Es werden [[Farbtiefe (Computergrafik)\|Farbtiefen]] von 8, 16 und 32 Bit pro [[Pixel]] unterstützt, wobei der RFB-Client die gewünschte Farbtiefe und Kodierung vom Server anfordert und der Server sich nach den Wünschen des Clients zu richten hat, sofern er die gewünschte Kodierung unterstützt.		Da es auf der Ebene des [[Rastergrafik\|bitmaporientierten]] [[Grafikspeicher]]s ([[Englische Sprache\|engl.]] Framebuffer) arbeitet, ist die Anwendung auf beliebigen Fenstersystemen wie [[Windows]], [[Mac OS]] oder [[X11]] möglich. Die Bildschirminhalte werden als Bitmaps übertragen, wobei in der Regel nur die jeweiligen Änderungen – in geeigneter Kodierung, siehe unten – zum Client übertragen werden. Es werden [[Farbtiefe (Computergrafik)\|Farbtiefen]] von 8, 16 und 32 Bit pro [[Pixel]] unterstützt, wobei der RFB-Client die gewünschte Farbtiefe und Kodierung vom Server anfordert und der Server sich nach den Wünschen des Clients zu richten hat, sofern er die gewünschte Kodierung unterstützt. Dieses Design erlaubt es, die Anforderungen an den Client einfach zu halten und so die Verwendung von [[Thin Client]]s zu unterstützen.

	Das Design von RFB ist darauf ausgerichtet, die Anforderungen an den Client einfach zu halten und so die Verwendung von [[Thin Client]]s zu unterstützen.

	RFB-Verbindungen sind [[Zustandslosigkeit\|zustandslos]], sodass Verbindungsunterbrechungen bzw. der Wechsel des RFB-Clients problemlos möglich sind, ohne dass die zugehörige Sitzung dabei verloren geht. Ziel von RFB und VNC ist letztendlich die Unterstützung des entfernten Arbeitens an Rechnern unter einer einheitlichen Arbeitsumgebung.		RFB-Verbindungen sind [[Zustandslosigkeit\|zustandslos]], sodass Verbindungsunterbrechungen bzw. der Wechsel des RFB-Clients problemlos möglich sind, ohne dass die zugehörige Sitzung dabei verloren geht. Ziel von RFB und VNC ist letztendlich die Unterstützung des entfernten Arbeitens an Rechnern unter einer einheitlichen Arbeitsumgebung.

	=== Port- und Desktopnummern ===		=== Port- und Desktopnummern ===
	In der Original-Unix-Version von VNC ist jeder VNC-Server ein eigener [[X-Server]] und stellt genau einen [[X Window System\|X-Desktop]] dar ([[Xvnc]]). Es wird dabei standardmäßig die erste freie X-Servernummer von VNC belegt. Falls bereits ein lokaler X-Server auf der Maschine läuft, der somit den X-Desktop <code>:0</code> belegt, bekommt VNC den Desktop <code>:1</code>. Die von VNC belegte [[Port (Protokoll)\|TCP-Portnummer]] ist <code>5900 + ''desktopnummer''</code>, unter Unix somit meist 5901. Einige VNC-Server stellen an Port 5800 bzw. <code>5800 + ''desktopnummer''</code> ein [[Java-Applet]] zur Verfügung mit dem der Desktop mit einem [[Webbrowser]] betrachtet und gesteuert werden kann.		In der Original-Unix-Version von VNC ist jeder VNC-Server ein eigener [[X-Server]] und stellt genau einen [[X Window System\|X-Desktop]] dar ([[Xvnc]]). Es wird dabei standardmäßig die erste freie X-Servernummer von VNC belegt. Falls bereits ein lokaler X-Server auf der Maschine läuft, der somit den X-Desktop <code>:0</code> belegt, bekommt VNC den Desktop <code>:1</code>. Die von VNC belegte [[Port (Protokoll)\|TCP-Portnummer]] ist <code>5900 + ''desktopnummer''</code>, unter Unix somit meist 5901. Einige VNC-Server stellen an Port 5800 bzw. <code>5800 + ''desktopnummer''</code> ein [[Java-Applet]] zur Verfügung, mit dem der Desktop mit einem [[Webbrowser]] betrachtet und gesteuert werden kann.

	Unter [[Windows]] und [[Mac OS X]] läuft in der Regel kein lokaler X-Server ~~(kann aber etwa von der Mac OS X-Installations-DVD nachinstalliert werden)~~, so dass VNC den Desktop <code>:0</code> und somit die TCP-Portnummer 5900 belegt. Dieser Port wird ebenfalls ~~benutzt~~ vom Unix-Programm [[x11vnc]], welches den lokalen X-Server <code>:0</code> als VNC-Desktop anbietet.		Unter [[Windows]] und [[Mac OS X]] läuft in der Regel ''kein'' lokaler X-Server, so dass VNC den Desktop <code>:0</code> und somit die TCP-Portnummer 5900 belegt. Dieser Port wird ebenfalls vom Unix-Programm [[x11vnc]] benutzt, welches den bestehenden lokalen X-Server <code>:0</code> als VNC-Desktop anbietet.

	== Protokoll-Details ==		== Protokoll-Details ==

Trustable: wikilinks

2016-03-15T17:29:49Z

wikilinks

← Nächstältere Version		Version vom 15. März 2016, 19:29 Uhr
Zeile 18:		Zeile 18:

	== Grundprinzip ==		== Grundprinzip ==
	Ein RFB-[[Server (Software)\|Server]] bietet einen so genannten „[[Desktop (~~Computer~~)\|Desktop]]“ an. Dies ist eine grafische Arbeitsumgebung, die auf einem entfernten Computer läuft bzw. die dazugehörigen Anwendungen. Der RFB-[[Client]] stellt in der Regel diesen Desktop auf dem Arbeitsplatzrechner des Benutzers dar, nimmt Benutzereingaben ([[Tastatureingabe]]n, [[Mausbewegung]]en und -[[Mausklick\|klicks]] usw.) entgegen und leitet diese an den RFB-Server weiter, womit die dortige Arbeitsumgebung gesteuert wird.		Ein RFB-[[Server (Software)\|Server]] bietet einen so genannten „[[Desktop (grafische Benutzeroberfläche)\|Desktop]]“ an. Dies ist eine grafische Arbeitsumgebung, die auf einem entfernten Computer läuft bzw. die dazugehörigen Anwendungen. Der RFB-[[Client]] stellt in der Regel diesen Desktop auf dem Arbeitsplatzrechner des Benutzers dar, nimmt Benutzereingaben ([[Tastatureingabe]]n, [[Mausbewegung]]en und -[[Mausklick\|klicks]] usw.) entgegen und leitet diese an den RFB-Server weiter, womit die dortige Arbeitsumgebung gesteuert wird.

	Da es auf der Ebene des [[Rastergrafik\|bitmaporientierten]] [[Grafikspeicher]]s ([[Englische Sprache\|engl.]] Framebuffer) arbeitet, ist die Anwendung auf beliebigen Fenstersystemen wie [[Windows]], [[Mac OS]] oder [[X11]] möglich. Die Bildschirminhalte werden als Bitmaps übertragen, wobei nur die jeweiligen Änderungen – in geeigneter Kodierung, siehe unten – zum Client übertragen werden. Es werden [[Farbtiefe (Computergrafik)\|Farbtiefen]] von 8, 16 und 32 Bit pro [[Pixel]] unterstützt, wobei der RFB-Client die gewünschte Farbtiefe und Kodierung vom Server anfordert und der Server sich nach den Wünschen des Clients zu richten hat, sofern er die gewünschte Kodierung unterstützt.		Da es auf der Ebene des [[Rastergrafik\|bitmaporientierten]] [[Grafikspeicher]]s ([[Englische Sprache\|engl.]] Framebuffer) arbeitet, ist die Anwendung auf beliebigen Fenstersystemen wie [[Windows]], [[Mac OS]] oder [[X11]] möglich. Die Bildschirminhalte werden als Bitmaps übertragen, wobei nur die jeweiligen Änderungen – in geeigneter Kodierung, siehe unten – zum Client übertragen werden. Es werden [[Farbtiefe (Computergrafik)\|Farbtiefen]] von 8, 16 und 32 Bit pro [[Pixel]] unterstützt, wobei der RFB-Client die gewünschte Farbtiefe und Kodierung vom Server anfordert und der Server sich nach den Wünschen des Clients zu richten hat, sofern er die gewünschte Kodierung unterstützt.
Zeile 61:		Zeile 61:
	Der Client steuert, ob und wann Daten übertragen werden sollen. Er sendet die lokalen Tastatur- und Mauseingaben an den Server. Außerdem sendet er regelmäßig "FramebufferUpdateRequest"-Nachrichten an den Server, der daraufhin die ''Änderungen'' des Bildschirminhaltes an den Client sendet.		Der Client steuert, ob und wann Daten übertragen werden sollen. Er sendet die lokalen Tastatur- und Mauseingaben an den Server. Außerdem sendet er regelmäßig "FramebufferUpdateRequest"-Nachrichten an den Server, der daraufhin die ''Änderungen'' des Bildschirminhaltes an den Client sendet.

	In der ursprünglichen RFB-Version wurden auch die Updates des Mauszeigers über normale FramebufferUpdates an den Client geschickt. Dabei ist die zu übertragene Datenmenge recht hoch und die damit verbundenen Latenzen erschweren die Bedienung. Mit RFB-Version 3.8 wurde eine Erweiterung eingeführt, die es erlaubt, dass der Mauszeiger vom Client lokal gezeichnet wird und vom Server lediglich das Aussehen des Mauspfeils und dessen Änderungen (z.B. wenn sich der Mauspfeil über ein Eingabefeld bewegt und dann zum I-Cursor wird) an den Client übertragen werden.		In der ursprünglichen RFB-Version wurden auch die Updates des Mauszeigers über normale FramebufferUpdates an den Client geschickt. Dabei ist die zu übertragene Datenmenge recht hoch und die damit verbundenen Latenzen erschweren die Bedienung. Mit RFB-Version 3.8 wurde eine Erweiterung eingeführt, die es erlaubt, dass der Mauszeiger vom Client lokal gezeichnet wird und vom Server lediglich das Aussehen des Mauspfeils und dessen Änderungen (z. B. wenn sich der Mauspfeil über ein Eingabefeld bewegt und dann zum I-Cursor wird) an den Client übertragen werden.

	Ebenso kann seit Version 3.8. eine Änderung an der Größe des Desktops an den Client übertragen werden. Bei früheren Versionen musste der Server die Verbindung zum Client beenden, da nur in der Initialisierungsphase einer Verbindung die Größe des Desktops an den Client übertragen werden konnte.		Ebenso kann seit Version 3.8. eine Änderung an der Größe des Desktops an den Client übertragen werden. Bei früheren Versionen musste der Server die Verbindung zum Client beenden, da nur in der Initialisierungsphase einer Verbindung die Größe des Desktops an den Client übertragen werden konnte.

HRoestTypo: Tippfehler entfernt: akzepztiert => akzeptiert,

2016-02-20T01:42:08Z

Tippfehler entfernt: akzepztiert => akzeptiert,

← Nächstältere Version		Version vom 20. Februar 2016, 03:42 Uhr
Zeile 54:		Zeile 54:

	=== Initialisierung ===		=== Initialisierung ===
	Nach erfolgreicher Authentifizierung sendet der Client eine 1 Byte große "ClientInit"-Nachricht. Diese enthält lediglich ein Flag, ob der Client eine "shared" Verbindung ~~akzepztiert~~, d.h. dass eventuelle Verbindungen des Servers zu anderen Clients erlaubt sind oder (falls das Flag auf 0 ist) beendet werden sollen.		Nach erfolgreicher Authentifizierung sendet der Client eine 1 Byte große "ClientInit"-Nachricht. Diese enthält lediglich ein Flag, ob der Client eine "shared" Verbindung akzeptiert, d.h. dass eventuelle Verbindungen des Servers zu anderen Clients erlaubt sind oder (falls das Flag auf 0 ist) beendet werden sollen.

	Anschließend sendet der Server eine "ServerInit"-Nachricht. Diese enthält den Namen des Desktops (der oft aus dem Rechnernamen des Servers abgeleitet wird), die Größe des Desktops (in Pixeln) und die native Farbtiefe und Anordnung der Pixel auf Serverseite. Die Bilddaten werden standardmäßig in diesem Format zum Client übertragen, außer der Client fordert über eine "SetPixelFormat"-Nachricht die Daten in einem anderen, für den Client einfacher zu verarbeitenden Format an.		Anschließend sendet der Server eine "ServerInit"-Nachricht. Diese enthält den Namen des Desktops (der oft aus dem Rechnernamen des Servers abgeleitet wird), die Größe des Desktops (in Pixeln) und die native Farbtiefe und Anordnung der Pixel auf Serverseite. Die Bilddaten werden standardmäßig in diesem Format zum Client übertragen, außer der Client fordert über eine "SetPixelFormat"-Nachricht die Daten in einem anderen, für den Client einfacher zu verarbeitenden Format an.

RokerHRO: /* Datenübertragung */

2014-11-18T09:26:55Z

Datenübertragung

← Nächstältere Version		Version vom 18. November 2014, 11:26 Uhr
Zeile 61:		Zeile 61:
	Der Client steuert, ob und wann Daten übertragen werden sollen. Er sendet die lokalen Tastatur- und Mauseingaben an den Server. Außerdem sendet er regelmäßig "FramebufferUpdateRequest"-Nachrichten an den Server, der daraufhin die ''Änderungen'' des Bildschirminhaltes an den Client sendet.		Der Client steuert, ob und wann Daten übertragen werden sollen. Er sendet die lokalen Tastatur- und Mauseingaben an den Server. Außerdem sendet er regelmäßig "FramebufferUpdateRequest"-Nachrichten an den Server, der daraufhin die ''Änderungen'' des Bildschirminhaltes an den Client sendet.

	In der ursprünglichen RFB-Version wurden auch die Updates des Mauszeigers über normale FramebufferUpdates an den Client geschickt. Dabei ist die zu übertragene Datenmenge recht hoch und die damit verbundenen Latenzen erschweren die Bedienung. Mit RFB-Version 3.8 eine Erweiterung eingeführt, die es erlaubt, dass der Mauszeiger vom Client lokal gezeichnet wird und vom Server lediglich das Aussehen des Mauspfeils und dessen Änderungen (z.B. wenn sich der Mauspfeil über ein Eingabefeld bewegt und dann zum I-Cursor wird) an den Client übertragen werden.		In der ursprünglichen RFB-Version wurden auch die Updates des Mauszeigers über normale FramebufferUpdates an den Client geschickt. Dabei ist die zu übertragene Datenmenge recht hoch und die damit verbundenen Latenzen erschweren die Bedienung. Mit RFB-Version 3.8 wurde eine Erweiterung eingeführt, die es erlaubt, dass der Mauszeiger vom Client lokal gezeichnet wird und vom Server lediglich das Aussehen des Mauspfeils und dessen Änderungen (z.B. wenn sich der Mauspfeil über ein Eingabefeld bewegt und dann zum I-Cursor wird) an den Client übertragen werden.

	Ebenso kann seit Version 3.8. eine Änderung an der Größe des Desktops an den Client übertragen werden. Bei früheren Versionen musste der Server die Verbindung zum Client beenden, da nur in der Initialisierungsphase einer Verbindung die Größe des Desktops an den Client übertragen werden konnte.		Ebenso kann seit Version 3.8. eine Änderung an der Größe des Desktops an den Client übertragen werden. Bei früheren Versionen musste der Server die Verbindung zum Client beenden, da nur in der Initialisierungsphase einer Verbindung die Größe des Desktops an den Client übertragen werden konnte.