| Beide Seiten der vorigen RevisionVorhergehende ÜberarbeitungNächste Überarbeitung | Vorhergehende Überarbeitung |
| embedded_systems:robi2:remote [2011-11-22 16:43] – Reduktion auf tatsächlich benötigte Teile, Abwandlung des Floatingpoint Formats auf einfach im Target umsetzbare Formatierung niederer | embedded_systems:robi2:remote [2012-01-30 11:40] (aktuell) – Kleinere Ergänzungen als Vorbereitung für aktuellen Stand niederer |
|---|
| <box red 80% | **Actung**>Diese Dokumentation befindet sich noch im Entwicklungsstadium</box> | <box red 80% | **Actung**>Diese Dokumentation befindet sich noch im Entwicklungsstadium</box> |
| |
| ======Robi2 Remote Interface====== | ======Robi2 Remote Interface====== |
| Es besteht die Möglichkeit, den Robi softwaretechnisch fernzusteuern. Hierfür wird auf dem Robi eine Server-Applikation installiert, welche eine vereinfachte Form eines RMI Servers zur Verfügung stellt. | Es besteht die Möglichkeit, den Robi softwaretechnisch fernzusteuern. Hierfür wird auf dem Robi eine Server-Applikation installiert, welche es erlaubt, Befehle im Klartext an den Robi zu senden. Der Robi liefert die entsprechenden Antworten ebenfalls in Klartext. Dies ermöglicht eine Bedienung über Software aber auch eine Bedienung durch eine Terminal-Anwendung wie beispielsweise [[http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html | putty]]. |
| |
| ===== Das Objektmodell ===== | ===== Das Kommunikationsprotokoll ===== |
| ====Client Implementation==== | Das Protokoll funktioniert nach dem Request-Response Prinzip wobei jeweils der Client die Requests stellt. Das Protokoll ist im Textformat entworfen. Dies ermöglicht die Überquerung von Plattformen, ohne dabei die [[wp>Endianness]] oder andere Plattformspezifische Fragen beachten zu müssen. Da es sich um geringe Datenmengen handelt, ist der Overhead vertretbar. Als Voraussetzung für dieses Protokoll wird ein garantierter Übertragungskanal für Byte-Ströme angenommen wie ihn beispielsweise [[wp>Transmission Control Protocol|TCP]] zur Verfügung stellt. |
| TODO | |
| |
| ====Server Implementation==== | ====Protokoll==== |
| TODO | Das Framing beschränkt sich auf eine Zeilenweise Trennung der einzelnen Requests und den jeweiligen Responses. Um das Protokoll möglichst zu vereinfachen wird auf eine Versionierung des Protokolls in Form eines spezifischen Startzeichens verzichtet. Als Antwort erhält der Aufrufer jeweils den Rückgabewert der aufgerufenen Methode. Liefert die Methode keinen Rückgabewert erhält der Aufrufer eine leere Zeile. |
| |
| =====Funktionsumfang===== | FIXME Eventuelle, transparente Erweiterung? FIXME |
| ====Robi Remote Version 0==== | Ist ein Aufruf nicht in Ordnung, so wird dem Aufrufer ein Fehlercode zurückgeliefert. In diesem Fall ist das erste Zeichen im Frame ein '*' gefolgt von einem numerischen Fehlercode. Optional kann ein erklärender Text auf den Fehlercode folgen. |
| Diese Remote-Procedure-Call Ausbaustufe wird durch //ProtVersion=0// im Traffic identifiziert. | |
| |
| ==Methodenliste== | Eine Beschreibung der möglichen Aufrufe befindet sich im Abschnitt [[ .#Befehlssatz ]] |
| TODO | |
| |
| ===== Das Kommunikationsprotokoll ===== | ===Beispiele=== |
| Das Protokoll funktioniert nach dem Request-Response Prinzip wobei jeweils der Client die Requests stellt. Das Protokoll ist als Textformat entworfen. Dies ermöglicht die Überquerung von Plattformen, ohne dabei die Endianness oder ähnliches beachten zu müssen. Da es sich um geringe Datenmengen handelt, ist der Overhead vertretbar. Nötigenfalls wäre eine Übersetzung in ein binäres Format aber einfach zu vollziehen. Als Voraussetzung für dieses Protokoll wird ein bereits gesicherter Übertragungskanal für Byte-Ströme angenommen. | **Gültige Kommando** |
| | <code> |
| | Request: drive 10<CR><LF> |
| | Response: <CR><LF> |
| | </code> |
| | <code> |
| | Request: getDistSensorValues<CR><LF> |
| | Response: 10 0 12 45 100 200 312 450 35 35 32 31 32 31 30 30<CR><LF> |
| | </code> |
| |
| ====Framing==== | **Ungültige Kommando** |
| Request und Response werden jeweils durch ein Startzeichen identifiziert und durch einen Zeilenumbruch abgeschlossen. Das erste Datenfeld in der Nutzlast entspricht der Protokollidentifikation. So können zum Beispiel verschiedene Protokollversionen unterschieden werden. Die eigentliche Nutzlast wird durch ein [[.:remote#Das Serialisierungsformat|PHP inspiriertes Serialisierungsverfahren]] codiert. Auf eine Längencodierung der Nutzlast wird bewusst verzichtet, da durch das Serialisierungsformat bereits - wo Nötig - eine Längencodierung stattfindet und dadurch keine Kollisionen mit dem Frame-End-Zeichen auftreten können, sofern der Parser für das Framing und der Parser der Serialisierung zusammen arbeiten. | <code> |
| | Request: InvalidCommand<CR><LF> |
| | Response: *1 Command Unknown<CR><LF> |
| | </code> |
| |
| ===Frameformat=== | ===Formale Beschreibung=== |
| <code> | <code> |
| Traffic = Request | Response . | Traffic = Request | Response . |
| Request = ">" ProtID ProtVersion CommandID { Parameter } FrameEnd . | Request = Command { Delimiter Parameter } FrameEnd . |
| Response = "<" ProtID ProtVersion { ReturnValue } FrameEnd . | Response = [ ReturnValue ] FrameEnd . |
| |
| ProtID = "R" "2" . | Command = Token . |
| ProtVersion = Number . | Parameter = FixedPoint | Integer . |
| | ReturnValue = [ FixedPoint |
| | | Integer |
| | | ( "*" ErrorCode { Delimiter Token } ) ] . |
| |
| CommandID = SerializedNumber . | FixedPoint = Integer "." Digit { Digit } . |
| Parameter = SerializedData . | Integer = "0" | ( [ "-" ] Number ) . |
| ReturnValue = SerializedData . | ErrorCode = Number . |
| | Token = ( Grossbuchstabe | Kleinbuchstabe ) { AlphaNumerisch } . |
| |
| SerializedNumber = ? Number in serialisiert Form ? . | AlphaNumerisch = Grossbuchstabe | Kleinbuchstabe | Digit . |
| SerializedData = ? Daten in serialisierter Form ? . | Number = NonZeroDigit { Digit } . |
| | Grossbuchstabe = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" |
| Number = NonZeroDigit { Digit } . | | "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" |
| Digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" . | | "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z" . |
| FrameEnd = "\r" "\n" . | Kleinbuchstabe = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" |
| | | "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" |
| | | "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z" . |
| | Digit = "0" | NonZeroDigit . |
| | NonZeroDigit = "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" . |
| | Delimiter = " " . |
| | FrameEnd = "\r" "\n" . |
| </code> | </code> |
| |
| ==== Das Serialisierungsformat ==== | ===== Das Objektmodell ===== |
| Das Serialisierungsformat ist durch das PHP Serialisierungsformat inspiriert und erweitert das grösstenteils kompatibel. Im Gegensatz zur Standard Java-Serialisierung ist dieses Datenformat als ASCII-Text ausgelegt und ausserdem wesentlich kompakter als ein Java Object Stream nach Standard-Protokoll. | ====Client Implementation==== |
| | TODO |
| |
| Leider ist das PHP Serialisierungsformat nirgendwo formal beschrieben. Es lässt sich jedoch aus dem {{http://svn.php.net/viewvc/php/php-src/tags/php_5_3_8/ext/standard/var.c?view=markup|Code des Moduls var.c}} aus der PHP Codebase sehr einfach rekonstruieren. Das an dieser Stelle verwendete Format beschränkt sich auf die primitiven Datentypen **ohne** Arrays. | ====Server Implementation==== |
| | TODO |
| |
| ===Formatbeschreibung=== | =====Befehlssatz===== |
| <code> | |
| SerializedData = SerializedObject { SerializedObject } . | |
| SerializedObject = ( Null | Bool | Long | Double ) ";" . | |
| | |
| Null = "N" ":" . | |
| Bool = "b" ":" ("0" (* = false *) | "1" (* = true *)) . | |
| Long = "i" ":" [ '-' ] Number . | |
| Double = "d" ":" ( DoubleNumber | ( "N" "a" "N" ) | (( "+" | "-" ) "I" "N" "F" ) ). | |
| | |
| DoubleNumber = Long [ "." Number "E" ( "+" | "-" ) Number ] . | |
| Number = NonZeroDigit { Digit } . | |
| Digit = "0" | NonZeroDigit . | |
| NonZeroDigit = "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" . | |
| AnyChar = ? Beliebige ASCII Zeichenfolge ?. | |
| </code> | |
| |
| ===Beispiel=== | |
| Das nachfolgende Beispiel illustriert die verkettete Serialisierung der Daten | |
| ^ Typ ^ Wert ^ Serialisiert ^ | |
| ^ - | null | N; | | |
| ^ boolean | false | b:0; | | |
| ^ long | 13 | i:13; | | |
| ^ double | 23.1 | d:FIXME; | | |
| ^ Alle verbunden ||N;b:0;i:13;d:FIXME; | | |
| |
