SIMP 1.01 Protokollspezifikation (Mindestanforderung)

Größe: px

Ab Seite anzeigen:

Download "SIMP 1.01 Protokollspezifikation (Mindestanforderung)"

Joachim Esser
vor 8 Jahren
Abrufe

1 SIMP 1.01 Protokollspezifikation (Mindestanforderung) Autor: Harald Pittesser, Dokumentversion: 0.5 beta Eigenschaften SIMP (Simple Instant Message Protocol) ist ein Instant Message Protokol welches folgende Eigenschaften aufweist: Es basiert auf XML und IP/TCP. Es lässt sich beliebig erweitern. Es ermöglicht (je nach Aufbau des Servers) sowohl direkte als auch indirekte (zeitversetzte) Kommunikation. Server und Client sind vergleichsweise einfach zu realisieren. Nachrichtenarten Grundsätzlich gibt es zwei unterschiedliche Arten von Nachrichten: Statusnachrichten (hellomessage, loginmessage, logoutmessage, registrationmessage, registrationackmessage,registrationdeniedmessage, loginackmessage, logindeniedmessage) Datennachrichten (datamessage) Statusnachrichten werden durch den Benutzer nicht direkt wahrgenommen. Der Benutzer nimmt nur die resultierende Statusverränderung in der Kontaktliste wahr. Datennachrichten werden direkt angezeigt. Adressierung Die logische Adressierung der Benutzer des Protokolls wird durch ganzzahlige Nummern, der so genannten SUN (Simple User Number), realisiert. Der mögliche Wertebereich für Benutzer erstreckt sich von 1002 bis Jeder Benutzer muss eine eindeutige SUN besitzen, deshalb muss bei der Registration darauf geachtet werden, dass die angegebene SUN noch nicht in Verwendung ist. Der Server wird immer mit der SUN 1000 adressiert. Beim erstmaligen Registrieren wird der Benutzer temporär mit der SUN 1001 adressiert. Header Jede Nachricht enthält einen Header mit Informationen über Empfänger, Absender und Typ der Nachricht. Der Header wird durch <head> bzw. </head> abgegrenzt. Jeder Header hat mindestens vier Einträge: <to> SUN des Empfängers </to> <from> SUN des Absenders </from> <alias> Spitzname des Absenders </alias> <type> Typ der Nachricht </type>

Es ermöglicht (je nach Aufbau des Servers) sowohl direkte als auch indirekte (zeitversetzte) Kommunikation. Server und Client sind vergleichsweise einfach zu realisieren.

2 Optional können sich im Header (je nach Typ der Nachricht) noch folgende Einträge befinden: <pw> Passwort des Benutzers </pw> <version> Version des Protokolls </version> <time> Zeitpunkt des Eintreffens der datamessage beim Server </time> Zu beachten ist, dass der Spitznahme im Tag <alias> und das Passwort im Tag <pw> nicht länger als 16 Zeichen sein darf. Der Inhalt von Tag <version> entspricht der Version des verwendeten Protokolls (ganze Zahl, Wertebereich 0 bis 99). Der Inhalt vom Tag <time> entspricht einer ganzen Zahl die aus dem gewöhnlichen Zeitformat generiert wird. Der Inhalt von Tag <type> ist besonders wichtig, da er den Typ der Nachricht spezifiziert. Grundsätzlich wird im Tag <type> eine einstellige, ganze Zahl abgespeichert. Diese Zahl muss mit dem Typ der Nachricht übereinstimmen: <type>1</type> registrationmessage <type>2</type> loginmessage <type>3</type> logoutmessage <type>4</type> hellomessage <type>5</type> datamessage <type>10</type> registration-ack-message <type>-10</type> registration-denied-message <type>20</type> login-ack-message <type>-20</type> login-denied-message Statusnachrichten: Registrationmessage: <to>1000</to> <from>1001</from> <type>1</type> <pw>********</pw> <version>1</version> Wird einmalig vom Client zum Server gesendet um den Benutzer zu registrieren. Registration-ack-message: <type>10</type>

Der Inhalt von Tag <version> entspricht der Version des verwendeten Protokolls (ganze Zahl, Wertebereich 0 bis 99).

3 Wird vom Server zum Client gesendet um Registrierung zu bestätigen. Im Tag <to> wird die zugewiesene SUN des Clients abgelegt. Registration-denied-message: <to>1001</to> <type>-10</type> Wird vom Server zum Client gesendet, wenn Registrierung nicht erfolgt ist. Loginmessage: <to>1000</to> <from>1234</from> <type>2</type> <pw>********</pw> <version>1</version> Wird vom Client zum Server gesendet wenn der Client gestartet wird bzw. der Status des Clients von offline auf online gewechselt wird. Login-ack-message: <type>20</type> Wird vom Server zum Client gesendet um Login zu bestätigen. Login-denied-message: <type>-20</type>

Loginmessage: <to>1000</to> <from>1234</from> <type>2</type> <pw>********</pw> <version>1</version> Wird vom Client zum Server gesendet wenn der Client

4 Wird vom Server zum Client gesendet, wenn Login nicht erfolgt ist. Logoutmessage: <type>3</type> Wird vom Client zum Server gesendet wenn der Client beendet wird bzw. der Status des Clients von online auf offline gewechselt wird. In weiterer Folge wird die logoutmessage mit modifiziertem Tag <to> vom Server an jeden erreichbaren Client adressiert und gesendet, der mit dem Verfasser der ursprünglichen logoutmessage Kontakt hatte. Damit ist jedem dieser Clients bekannt, dass die Kontaktperson nicht mehr direkt erreichbar ist. Die für den Benutzer sichtbare Kontaktliste wird daraufhin entsprechend verändert. logoutmessage ---> <to> Server ) logoutmessage ---> Hellomessage: <type>4</type> Die hellomessage hat den Sinn Clients zu informieren, dass eine Kontaktperson erreichbar geworden ist. Oft wird die hellomessage vom Server aus einer eingegangenen loginmessage erzeugt, indem der Tag <pw> weggelassen wird. Der Server adressiert und sendet die erzeugte hellomessage mit modifiziertem Tag <to> an jeden erreichbaren Client, der mit dem Verfasser der ursprünglichen loginmessage Kontakt hatte. Hellomessages werden aber auch dafür verwendet, um einem erreichbar gewordenen Client zu informieren welche seiner Kontaktpersonen gerade erreichbar sind. Dabei sendet der Server für jede erreichbare Kontaktperson eine hellomessage mit entsprechenden <from> und <alias> Tag an den gerade erreichbar gewordenen Client. loginmessage ---> <to> Server )

In weiterer Folge wird die logoutmessage mit modifiziertem Tag <to> vom Server an jeden erreichbaren Client adressiert und gesendet, der mit dem Verfasser der ursprünglichen logoutmessage Kontakt

5 hellomessage ---> <--- hellomessage (<from> Client 2) <to> Client 1) Datennachrichten Datamessage <type>5</type> <time> </time> <data> ICQ suckz HDMS rulez! </data> Die datamessage ist die eigentliche Nachricht die der Benutzer direkt wahrnimmt. Im Gegensatz zu den Statusnachrichten besitzt die datamessage nicht nur einen Header sondern auch einen Nutzdatenbereich der mit <data> bzw. </data> abgegrenzt ist. Datamessages werden vom Server modifiziert weitergeleitet. Der Server fügt im Tag <time> die aktuelle Uhrzeit ein. datamessage ---> <to> Client 2) datamessage --->

Im Gegensatz zu den Statusnachrichten besitzt die datamessage nicht nur einen Header sondern auch einen Nutzdatenbereich der mit <data> bzw.

Ähnliche Dokumente

inviu routes Installation und Erstellung einer ENAiKOON id

inviu routes Installation und Erstellung einer ENAiKOON id Inhaltsverzeichnis inviu routes... 1 Installation und Erstellung einer ENAiKOON id... 1 1 Installation... 1 2 Start der App... 1 3 inviu routes