MaJaProL:Protokoll
Das MaJaLED-Protokoll beschreibt die UDP-Kommunikation zwischen den Clients und dem Server.
Ablauf:
- Es erfolgt eine Verbindungsanfrage und die Vergabe der Client-ID
- Dann werden die Ressourcen (LED-Paare) reserviert
- Ein Algorithmus behandelt die Prioritätenverteilung
- Bis Verbindungsabbau können neue Belegungen gesendet werden
- 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 ;-)