MaJaProL:Protokoll

Aus II-Wiki
Wechseln zu: Navigation, Suche

Das MaJaLED-Protokoll beschreibt die UDP-Kommunikation zwischen den Clients und dem Server.

Ablauf:

  1. Es erfolgt eine Verbindungsanfrage und die Vergabe der Client-ID
  2. Dann werden die Ressourcen (LED-Paare) reserviert
  3. Ein Algorithmus behandelt die Prioritätenverteilung
  4. Bis Verbindungsabbau können neue Belegungen gesendet werden
  5. Bei ausbleibenden Pings/Pingantworten (Pongs) wird die Verbindung getrennt (manuelle Trennung möglich)

Paketeaufbau

[1 Byte SERVER_ID]|[1 Byte CLIENT_ID]|[3 Byte Kommando]|[x Byte Parameter]

Aufbau der Verbindung

Um eine Verbindung zum Server aufzubauen sendet der Client zuerst ein WTC. Der Server antwortet daruafhin im Erfogsfall mit RTR oder mit CER im Fehlerfall.

Client baut Verbindung auf

SERVER_ID|0xFF|"W"|"T"|"C"|[4 Byte Integer Zufallszahl]|0xA
SERVER_ID ID des anzusprechenden Servers (Standard: 0x1)
WTC Want To Connect
Zufallszahl 32-Bit Integer, der eine Zufallszahl enthält. Diese sendet der Server später zurück, um den Clienten eine CLEINT_ID zuzuweisen
0xA hexadezimale Kodierung für LineFead-Zeichen (Unix-typische Zeilenbegrenzung)

Server aktzeptiert Verbindung

SERVER_ID|CLIENT_ID|"R"|"T"|"R"|[4 Byte Integer Zufallszahl]|[Bitvektor aus n Byte]|LED-Anzahl|0xA
SERVER_ID ID des antwortenden Servers
CLIENT_ID Vom Server vergebene ID, unter der der Client jetzt immer angesprochen wird
RTR Ready To Recieve (Server ist bereit zu empfangen)
Zufallszahl 32-Bit Integer, der die Zufallszahl des angesprochenen Clienten enthält.
Bitvektor n-Byte, deren Bit die die Farben einzelnen LEDs beschreiben. Wobei eine 1 einer blauen LED entspricht. 0 steht für eine weiße LED. Die Nummerierung der LEDs erfolgt in der Reihenfolge, wie Peter sie festgelegt hat (siehe Skizze). Die erste LED liegt im n-ten Byte ganz rechts.
LED-Anzahl Gibt an, wieviele LEDs nun genau existieren. Dies ist nötig, da die Anzahl der LEDs nicht durch 8 teilbar (volles Byte) sein muss. Als Standartwert wird hier 166 stehen.
0xA hexadezimale Kodierung für LineFead-Zeichen (Unix-typische Zeilenbegrenzung)

Server weist Verbindung ab

 SERVER_ID|0xFF|"C"|"E"|"R"|[4 Byte Integer Zufallszahl]|CER-Byte|0xA
SERVER_ID ID des antwortenden Servers
CER Connection ERror
Zufallszahl 32-Bit Integer, der die Zufallszahl des angesprochenen Clienten enthält.
CER-Byte 256 verschiedene Fehlergründe (muss noch geklärt werden) [0x1= To many Clients connected]
0xA hexadezimale Kodierung für LineFead-Zeichen (Unix-typische Zeilenbegrenzung)

Reservierung der Ressourcen

Nachdem der Client das RTR Packte vom Server empfangen hat, sendet er einen Vektor der angibt, welche LEDs der Client gern für sich in Anspruch nehmen möchte. (Dieser Abschnitt des Protokolls ist durchaus diskussionswürdig, wird aber dennoch in den Server integriert).

SERVER_ID|CLIENT_ID|"L"|"T"|"R"|[Bitvektor aus n Byte]|0xa
SERVER_ID ID des Servers
CLIENT_ID ID des sendenden Clients
LTR LEDs To Reserve (zu reservierende LEDs)
Bitvektor n-Byte, deren Bits angeben welche der LEDs der Client ansteuern möchte. Eine "1" markiert die zu reservierende LED. Die Byteanzahl muss mit der vom Server vorgegebenen übereinstimmen. (Default: 164 LEDs, kodiert in 21 Byte). Die Nummerierung der LEDs erfolgt in der Reihenfolge, wie Peter sie festgelegt hat (siehe Skizze). Die erste LED liegt im n-ten Byte ganz rechts.
0xA hexadezimale Kodierung für LineFead-Zeichen (Unix-typische Zeilenbegrenzung)

Client-Server Kommunikation

Der Server empfängt nach Erhalt des LTR-Packetes die LTS-Packete vom Clienten. Diese enthalten dann die eigentlichen Nutzdaten.

SERVER_ID|CLIENT_ID|"L"|"T"|"S"|[LED_VEKTOR]|0xA
SERVER_ID ID des Servers
CLIENT_ID ID des sendenden Clienten
LTS LEDs To Show
[LED_VEKTOR] n-Byte Vektor. In diesem Vektor entspricht eine "1" einer eingeschalteten LED. Eine "0" einer ausgeschalteten. Die Byteanzahl richtet sich nach der vom Server vorgegebenen. Die Nummerierung der LEDs erfolgt in der Reihenfolge, wie Peter sie festgelegt hat (siehe Skizze). Die erste LED liegt im n-ten Byte ganz rechts.
0xA hexadezimale Kodierung für LineFead-Zeichen (Unix-typische Zeilenbegrenzung)

Abbau der Verbindung

Kann von beiden Seiten gesendet werden. Wenn der Server solch ein Paket empfängt, wird der dazugehörige Client aus der Clientliste gelöscht. Wenn der Client solch ein Paket empfängt, wird die Kommunikation mit dem Server sofort eingestellt.

SERVER_ID|CLIENT_ID|"C"|"L"|"C"|CLC-Byte|0xA
SERVER_ID ID des Servers
CLIENT_ID ID des Clients
CLC CLose Connection
CLC-Byte 256 verschiedene Beendigungsgründe (muss noch geklärt werden)
0xA hexadezimale Kodierung für LineFead-Zeichen (Unix-typische Zeilenbegrenzung)


Status-Nachrichten

Zur Übermittlung von Nachrichten können sogenannte Message Pakete genutzt werden. Sie sind wie folgt aufgebaut

SERVER_ID|CLIENT_ID|"M"|"S"|"G"|MSG-Byte|0xA

SERVER_ID ID des Servers
CLIENT_ID ID des Clients
MSG MeSaGe
MSG-Byte 256 verschiedene Nachrichten. (Bisher wird nur die 0x1 zur Time-Out Behandlung genutzt)
0xA hexadezimale Kodierung für LineFead-Zeichen (Unix-typische Zeilenbegrenzung)

Time-Outs

Sobald der Server das erste RTR-Packet an den Clienten gesendet hat, sendet er alle 20 Sekunden ein MSG-Packet mit msg=0x1 an den Clienten. Dieses Packet muss der Client dann umgehend zurücksenden.

Es ist unbedingt notwendig, dass die Clienten auf die Aufforderung zum Pong warten. Sollte es innerhalb von 10 Sekunden zu keiner Reaktion auf einer der beiden Seiten gekommen sein, beendet sowohl der Server als auch der Client die Verbindung selbstständig. (Sofern er nicht abgeschmiert ist ;-)