Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
embedded_systems:robi2:remote [2011-12-14 17:31] – Erster Entwurf des abgespeckten Protokolls niedererembedded_systems:robi2:remote [2012-01-30 11:40] (aktuell) – Kleinere Ergänzungen als Vorbereitung für aktuellen Stand niederer
Zeile 5: Zeile 5:
  
 ===== Das Kommunikationsprotokoll ===== ===== Das Kommunikationsprotokoll =====
-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 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.+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.
  
 ====Protokoll==== ====Protokoll====
-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 optional den Rückgabewert der aufgerufenen Methode. Liefert die Methode keinen Rückgabewert erhält der Aufrufer eine leere Zeile. +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.  
 + 
 +FIXME Eventuelle, transparente Erweiterung? FIXME
 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. 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.
  
Zeile 14: Zeile 16:
  
 ===Beispiele=== ===Beispiele===
-**Gültiges Kommando**+**Gültige Kommando**
 <code> <code>
-Request:  gibSensorWert 0<CR><LF> +Request:  drive 10<CR><LF> 
-Response: 127<CR><LF>+Response: <CR><LF>
 </code> </code>
- 
-**Ungültiges Kommando** 
 <code> <code>
-Request:  InvalidCommand<CR><LF> +Request:  getDistSensorValues<CR><LF> 
-Response: *1 Command Unknown<CR><LF>+Response: 10 0 12 45 100 200 312 450 35 35 32 31 32 31 30 30<CR><LF>
 </code> </code>
  
-**Ungültige Parameter**+**Ungültige Kommando**
 <code> <code>
-Request:  gibSensorWert 0 2.1<CR><LF> +Request:  InvalidCommand<CR><LF> 
-Response: *2 Invalid Parameter<CR><LF>+Response: *1 Command Unknown<CR><LF>
 </code> </code>