PVS-Protokoll¶
Entsprechend der Spezifikationen wurde ein Protokoll für die Kommunikation zwischen Server- und Clientapplikation entwickelt.
Allgemein¶
Das PVS-Prokotoll stellt ein sehr einfaches Messagingprotkoll dar. Es ist relativ generisch gehalten, gleichzeitig aber nicht ausserhalb des PVS "out of the box" verwendbar.
Es findet keine Verschlüsselung, Fehlerbehandlung oder Komprimierung statt. Die Nachrichten werden als ein entsprechender String aus Header, Ident und Message erstellt und aneinandergehängt als plain-text gesendet. Der Messagetype, Ident und die Message selbst können selbst definiert werden. Der Typ der Nachricht ist entweder ein COMMAND, LOGIN, MESSAGE oder UNKNOWN. Sie unterscheiden sich nicht in ihrer Funktion, sonder nur durch unterschiedliche Dispatcher im Client (ServerConnection), bzw Server(ClientConnection/ListenServer). Der Ident dient der Unterscheidung innerhalb des Nachrichtentyps. Ein Ident kann beispielsweise Ein Username, ein Befehl oder Erklärung zur nachfolgenden Nachricht sein. Die Nachricht wiederrum enthält die dem Ident entsprechenden Informationen. Hierbei obliegt es der entsprechenden Implementation wie das Protokoll definiert wird. Die einzigen in Server und Client festgelegte Befehle ist "ID". Der Server generiert für sich und jede eingehende Verbindung eine eindeutige ID und übersendet diese umgehend. Momentan folgt implementationsabhängig nach Eingang der ID beim Server das versenden des eigenen Usernamens als Befehl "USERNAME". Jeweils die ID bzw der Username sind somit die Message, "ID, bzw "USERNAME" der Ident und beide sind auf dem Messagetype LOGIN realisiert.
Die Nachrichtenobjekte sind komfortable gestaltet und senden/empfangen direkt an/von Sockets. Somit sind sie wiederverwendbar und flexibel. Durch ihre geringe Größe lohnt es sich diese Objekte als konkrete Instanzen zu verwenden, da sie in ihrem Kon-/Destruktur (und dem Copykonstruktor) ein entsprechend sauberes Speichermanagement betreiben. Lokale Instanzen betreiben somit beim verlassen des Scopes ihre eigene Garbagecollection.
Beispiel¶
Die Übersendung des Usernames wird im Client durch den Erhalt der Nachricht "ID" getriggert. Das bedeutet, dass die Methode, welche mit dem loginDispatcher des Clients verbunden wurde, ein neues Nachrichtenobjekt erstellt wird mit dem Typ "LOGIN", dem Ident "USERNAME" und der Nachricht "MEINUSERNAME" welches anschließend der Sendemethode übergeben wird. Dabei wird die Nachricht entsprechend mit einem Header versehen und gesendet. Beim Empfang der Nachricht auf dem Server wird diese Nachricht gemäß des Headers in ein Nachrichtenobjekt übergeben welchese wegen seines Typs an den loginDispatcher weitergeleitet wird, welcher die Nachricht an alle eingetragenen Callbacks weiterleitet. Jedes Objekt welches im Scope des TCP-Servers liegt kann bei diesem Callbacks auf bestimmte Idents bei den unterschiedlichen Dispatchern registrieren. Es existieren entsprechend ein commandDispatcher, ein loginDispatcher und ein chatDispatcher. Nachrichten unbekannten Typs werden nicht dispatched. Die registrierten Methoden bekommen bei ihrem Aufruf eine Kopie des entsprechenden Nachrichtenobjekts übergeben, welche dann entsprechende Aktionen ausführen können, je nach Implementation. Der ConnectionManager jedenfalls reagiert auf ein entsprechendes Nachrichtenobjekt mit der Aktualisierung des Usernames im entsprechenden Eintrag in der Verbindungsliste.
Eine entsprechende Wildcard für Idents existiert auch, damit ist es möglich sich für alle Idents eines entsprechenden Typs anzumelden und so sämtliche, über einen Dispatcher gesendeten, Nachrichten zu erhalten. Somit ist es der Implementation überlassen ob eine einzelne Methode für Nachrichten jeden Idents zuständig ist oder für jeden Ident eine eigene Methode bereitgestellt wird. Auch Variationen aus beidem sind möglich.
Messages¶
Aktuell gesendete Nachrichten (05.05.2010)
| Nachrichtentyp | Nachrichten Ident | Inhalt | Beschreibung |
| PVSCOMMAND | PROJECT | hostname port password quality | Hostname, Port, Passwort und Qualität des VNC Servers zu dem verbunden werden soll (durch Space getrennt) |
| PVSCOMMAND | UNPROJECT | ||
| PVSCOMMAND | LOCKSTATION | ||
| PVSCOMMAND | LOCKSTATION | Message | Client mit Nachricht sperren |
| PVSCOMMAND | UNLOCKSTATION | ||
| PVSLOGIN | USERNAME | username | |
| PVSLOGIN | PASSWORD | password | Server Passwort |
| PVSLOGIN | ID | id | |
| PVSLOGIN | FAILED | "Wrong Password" | Wird bei falschem Passwort gesendet |
| PVSCOMMAND | PORT | port | |
| PVSCOMMAND | PASSWORD | password | VNC Passwort |
| PVSCOMMAND | RWPASSWORD | password | Passwort für den Zugriff auf die Tastatur und Maus |
| PVSCOMMAND | VNC | YES | Erlaube Zugriff |
| PVSCOMMAND | VNC | NO | Verbiete Zugriff |
| PVSCOMMAND | PING | ||
| PVSCOMMAND | VNCREQUEST | ||
| PVSCOMMAND | VNCSRVRESULT | result code | Der Rückgabewert des pvs-vncsrv skripts |
| PVSMESSAGE | BROADCAST | Message | |
| PVSMESSAGE | clientToAdd | Client hinzufügen (Chat) | |
| PVSMESSAGE | clientToRemove | Client entfernen (Chat) | |
| PVSMESSAGE | assignedName | Festgelegter Name (Chat) |
Header¶
Der Header besteht aus 4 Bytes. Das erste Byte stellt ein bisher ignoriertes Identitätsbyte dar (bspw. ein P oder eine Char-Repräsentation einer Zahl). Es markiert damit allerdings auch immer den Beginn eines Headers und könnte so später zur Fehlerkorrektur beitragen. Das zweite Byte stellt den Nachrichtentyp dar (login, command, message). Das dritte Byte ist die Char-Repräsentation der Zeichenlänge des Idents, das vierte entsprechend der Zeichenlänge der Nachricht.
In Client und Server werden jeweils zuerst 4 Bytes erwartet aus welchen die Länge der folgenden Nachricht hervorgeht, welche entsprechend vollständig empfangen werden sollte.