Raspberry Pi als Home Server Teil 4

Beim Parsen bzw. Zusammenstellen des Response-Streams bin ich auf ein Problem gestoßen. Es war auf einmal gar nicht mehr so leicht, die beiden Response Bytes an die richtige Stelle im Stream zu schreiben. Bei gültigen Responses war dies noch eine leichte Übung. Was aber macht man, wenn das angeforderte Command nicht unterstützt wird und man so nicht unterscheiden kann, ob es sich um ein Connection-Required Command oder um ein Connection-Not-Required Command handelt? Durch diesen Unterschied würde sich bei der aktuellen Definition die Response-Bytes um einige Stellen verschieben.

Diese Schwachstelle im Protokoll werde ich ausmerzen, indem ich bei Connection-Required Commands die Response-Bytes vor den Connection Identifier setze.

Eine weitere Anpassung gibt es bei allen enumerierbaren Datentypen. Diese bekommen die Anzahl der Bytes im Stream als ushort vorgesetzt. Somit vereinfacht sich das Parsen der Request und Response Streams noch einmal.

Die gesamte Dokumentation ist hier zu finden:
https://jan-schubert.github.io/HomeAutomation/


Teil 1 der Serie: Raspberry Pi als Home Server
Teil 2 der Serie: Raspberry Pi als Home Server
Teil 3 der Serie: Raspberry Pi als Home Server

Raspberry Pi als Home Server Teil 3

Um mit dem Raspberry kommunizieren zu können, habe ich erstmal ein einfaches binäres Protokoll definiert.
Folgende Vorraussetzungen gelten:

• Die Kommunikation läuft über TCP/IP.
• Alle Ganzzahlen werden dabei im Little-Endian Format übertragen.
• Strings werden als Unicode übertragen.

Server (Raspberry) Anforderungen:

• Alle Connections nach 5 Minuten ohne Kommunikation beenden.
• Bei allen gestarteten Transaktionen wird nach 15 Sekunden ohne Kommunikation ein Rollback ausgeführt.

Das Protokoll ist aufgeteilt in Commands, die eine Anmeldung am Server benötigen und eben in die die keine brauchen.

Zu den Commands, die keine Anmeldung benötigen gehört bspw. das Connect Command. Folgend der Bytestream für dieses Command.

00 01 00 00 00 00 00 00 00 AF FE

• Das erste Byte 00 steht für die Protokollversion und wird vorerst immer 00 sein. Dies habe ich eingeführt damit ich später, wenn ich merke das ich Anpassungen bzw. Erweiterungen im Protokoll benötige, dieses einfach unter einer neuen Versionsnummer erweitern kann. Dann müsste lediglich der Client und der Server verschiedene Protokollversionen unterstützen.
• Die nächsten vier Bytes 01 00 00 00 stehen für den Request Type und geben an, was eigentlich gemacht werden soll.
• Die nächsten zwei Bytes (ushort) sind ein Counter, der bei jeder Anfrage hochgezählt wird und in der Antwort vom Server zurückgeben wird. Ob dieser Counter wirklich benötigt wird, ist mir noch nicht ganz klar. Es gibt Vor- und Nachteile, die ich noch gegeneinander abwägen muss. Ggf. wird der Counter in der endgültigen Version des Protokolls 00 nicht mehr vorhanden sein.
• Die nächsten zwei Bytes (ushort) sind die Länge der Datenbytes in diesem Beispiel 00 00 und somit gibt es auch keine Daten.
• Die letzten beiden Bytes ist die CRC Checksumme AF FE. Diese wird in meinen Beispielen immer mit AF FE angegeben, in der eigentlichen Implementierung dann aber natürlich berechnet.

Der dazugehörige Response hat lediglich den Unterschied, dass nach dem Counter 2 Bytes als Response Codes dienen im folgenden Beispiel 00 00:

00 01 00 00 00 00 00 00 00 00 00 AF FE

Es gibt Common Response Codes und Command spezifische. Folgend die Common Response Codes bei denen das erste Byte immer FF ist:

• wrong crc FF 01
• not connected FF 02
• transaction required FF 03
• unknown command FF 04
• corrupt data FF 05
• not supported protocol version FF 06

Die gesamte Dokumentation ist hier zu finden:
https://jan-schubert.github.io/HomeAutomation/


Teil 1 der Serie: Raspberry Pi als Home Server
Teil 2 der Serie: Raspberry Pi als Home Server