1 Einleitung

Das Neocast Message Exchange Protocol (NCMEP) oder Neocast-Nachrichten­austausch­protokoll dient dem Übertragen von Neocast-Nachrichten­paketen und verwendet zumeist WebSocket oder HTTP-Polling als zugrundeliegende Protokolle, wenngleich keine standardisierte Implementierung oder Einordnung in das OSI-Modell existiert. Diese Norm legt nur die Struktur des Protokolls fest.

2 Paketstruktur

Jedes NCMEP-Paket besteht aus einem Statuscode, einem Nachrichtenkörper und einem Header, durch welchen Metadaten im Schlüssel-Wert-Format kodiert werden können. Darüber hinaus existieren Kontrollelemente, die durch das Backend interpretiert werden KÖNNEN. Die Paketstruktur ist wie folgt definiert: struct { char* key; char* value; } HeaderEntry; struct { uint8 version; char* username; uint128 checksum; uint8 statusCode; char* body; HeaderEntry* header; } Packet;

3 Statuscodes

NCMEP definiert folgende dreistellige Statuscodes, die Server wie Client verwenden SOLLTEN, um Logik zu implementieren. enum { awaitingResponse(101), exchangeComplete(200), redirected(201), badRequest(240), notAuthorised(241), forbidden(243), notFound(244), internalError(250), rejected(252) } StatusCode;

4 Das Handshake-Protokoll

Vor dem Betreten eines Nachrichtentunnels tauschen Client und Server Informationen ob der Natur der Verbindungsaufnahme aus. Dabei wird dem folgenden Schema gefolgt:

1. Client-Hello

   Der Client stellt eine Verbindung zum Server her.

2. Server-Hello („Pförtner“)

   Der Server antwortet mit einem der folgenden Statuscodes:
   1. 101: Die Verbindung wird zugelassen.
   2. 252: Die Verbindung wird abgelehnt.

3. Kanalanfrage

   Der Client übermittelt ein Paket mit leerem Körper und dem gewünschten Kanal in einem Header kodiert.

4. Serverantwort („Operator“)

   Der Server überprüft den Benutzernamen und die Prüfsumme sowie die Verfügbarkeit des gewünschten Kanals. Einer der folgenden Statuscodes wird zurückgesendet:
   1. 200: Der Client wird dem Kanal zugewiesen; der Austausch ist abgeschlossen.
   2. 241: Authentifizierung nicht erfolgreich; Verbindung wird unterbrochen.
   3. 243: Authentifizierung ist erfolgreich, Zugriff zum Kanal jedoch verweigert.

5 Sicherheitsüberlegungen

• Prüfsummenvalidierung. Die signierte Prüfsumme (s.o.) stellt sicher, daß Benutzernamen authentifiziert werden und Nachrichten nicht leicht gefälscht werden können. Implementierungen SOLLTEN starke Schlüsselpaare potenter asymmetrischer Verschlüsselungsverfahren verwenden.
• Verschlüsselung. Die Transportschicht SOLLTE Transport Layer Security [TLS] implementieren, um das Abfangen von Nachrichten zu verhindern.

6 Maschinenlesbare Versionsnummern

Neben den Versionsnummern im Schema des Semantic Versioning [1] existieren auch maschinenlesbare Versionsnummern, die aus einer Ganzzahl bestehen und mit jeder Version um Eins inkrementiert werden („Versions­index“). Folgende Zuordnung existiert:

7 Referenzen