Aus RN-Wissen.de
Wechseln zu: Navigation, Suche
Rasenmaehroboter fuer schwierige und grosse Gaerten im Test

K (→‎Sessionbasierte Nachrichten)
 
(2 dazwischenliegende Versionen von einem anderen Benutzer werden nicht angezeigt)
Zeile 1: Zeile 1:
−
{{Baustelle|Ragnar}}
 
−
 
 
== RNcom Schicht 2 - Übersicht ==
 
== RNcom Schicht 2 - Übersicht ==
  
Zeile 44: Zeile 42:
 
sind nun mehrere Kommunikationsmodi möglich:
 
sind nun mehrere Kommunikationsmodi möglich:
  
−
* Request-Response Nachrichten: <br/> Bei Request-Response Nachrichten schickt der Client eine Session-Request Nachricht and den Server. Dieser antwortet mit genau einer Session-Referral Nachricht die die SessionID der Request-Nachricht trägt. Die Session wird beim Server nicht gespeichert. <br/> Der Server hat nun die Option auf das Ausbleiben einer Antwortnachricht durch Retries oder Timeouts zu antworten.
+
* Request-Response Nachrichten: <br/> Bei Request-Response Nachrichten schickt der Client eine Session-Request Nachricht an den Server. Dieser antwortet mit genau einer Session-Referral Nachricht die die SessionID der Request-Nachricht trägt. Die Session wird beim Server nicht gespeichert. <br/> Der Server hat nun die Option auf das Ausbleiben einer Antwortnachricht durch Retries oder Timeouts zu antworten.
  
 
* Continuous Session Nachrichten: <br/> Auch bei dieser Art von Nachrichten öffnet der Client die Session durch eine Request Nachricht. Der Server bestätigt dies auch sofort, speichert die SessionID und die Adresse des Clients jedoch ab. Nun kann er jederzeit spontane Session-Referral Nachrichten schicken. Diese Session muss von Client implizit geschlossen werden.
 
* Continuous Session Nachrichten: <br/> Auch bei dieser Art von Nachrichten öffnet der Client die Session durch eine Request Nachricht. Der Server bestätigt dies auch sofort, speichert die SessionID und die Adresse des Clients jedoch ab. Nun kann er jederzeit spontane Session-Referral Nachrichten schicken. Diese Session muss von Client implizit geschlossen werden.
  
 
Anmerkung: Ob es sich um eine Request-Response oder um eine Continuous Session handelt wird nicht explizit übertragen.
 
Anmerkung: Ob es sich um eine Request-Response oder um eine Continuous Session handelt wird nicht explizit übertragen.
−
Hier muss implizit Einigkeit zwischen Client und Server bestehen.
+
Hier muss implizit Einigkeit zwischen Client und Server bestehen. Wenn der Server also nur eine einfache Antwort gibt,
−
 
+
der Client aber einen Stream erwartet, wird der Client lange auf Daten warten.
  
 
=== Streams ===
 
=== Streams ===
Zeile 60: Zeile 58:
 
=== Allgemeiner Nachrichtenaufbau: ===  
 
=== Allgemeiner Nachrichtenaufbau: ===  
  
−
Kommt alles noch ...
+
Es müssen drei Nachrichten (Verbindungslos, Session-Request, Session-Referral) definiert werden.
  
 +
{| {{Blaueschmaltabelle}}
 +
| Length
 +
| Länge des Datenpaketes, evtl abzüglich der bereits definierten Headerbytes
 +
|}
  
−
Die Nachrichten vom Typ 128..255 werden an die Schicht 2 weitergeleitet und müssen geroutet werden.
+
{|{{Blaueschmaltabelle}}
−
Deshalb wird für diese Nachrichten das Format um die Ziel- und Absenderadresse erweitert.
+
| Byte 1
 +
| Type
 +
| 128 = Sessionless message
 +
|-
 +
| Byte 2
 +
| Dest Net
 +
| rowspan=2 | Adresse des Empfängers
 +
|-
 +
| Byte 3
 +
| Dest Node
 +
|-
 +
| Byte 4
 +
| Src Net
 +
| rowspan=2 | Adresse des Absenders
 +
|-
 +
| Byte 5
 +
| Src Node
 +
|-
 +
| Byte 6
 +
| rowspan=3 colspan=2 | Datenpaket, Format abhängig von der Applikation
 +
|-
 +
|  ...
 +
|-
 +
| Byte n
 +
|-
 +
|}
 +
<br/>
  
 
{| {{Blaueschmaltabelle}}
 
{| {{Blaueschmaltabelle}}
Zeile 74: Zeile 102:
 
  | Byte 1
 
  | Byte 1
 
  | Type
 
  | Type
−
  | 128..255 = Schicht 2 Nachricht
+
  | 129 = Session Request
 
  |-
 
  |-
 
  | Byte 2
 
  | Byte 2
 
  | Dest Net
 
  | Dest Net
−
  | Netznummer des Empfängers
+
  | rowspan=2 | Adresse des Empfängers
 
  |-
 
  |-
 
  | Byte 3
 
  | Byte 3
 
  | Dest Node
 
  | Dest Node
−
| Knotennummer des Empfängers
 
 
  |-
 
  |-
 
  | Byte 4
 
  | Byte 4
 
  | Src Net
 
  | Src Net
−
  | Netznummer des Absenders
+
  | rowspan=2 | Adresse des Absenders
 
  |-
 
  |-
 
  | Byte 5
 
  | Byte 5
 
  | Src Node
 
  | Src Node
−
| Knotennummer des Absenders
 
 
  |-
 
  |-
 
  | Byte 6
 
  | Byte 6
−
  | rowspan=3 colspan=2 | Datenpaket, Format abhängig von Schicht 2
+
| SessionID1
 +
| rowspan=2 | Session ID, eindeutig beim Absender
 +
|-
 +
| Byte 7
 +
| SessionID2
 +
|-
 +
| Byte 8
 +
  | rowspan=3 colspan=2 | Datenpaket, Format abhängig von der Applikation
 
  |-
 
  |-
 
  |  ...
 
  |  ...
Zeile 100: Zeile 133:
 
  |-
 
  |-
 
  |}
 
  |}
 +
<br/>
 +
 +
{| {{Blaueschmaltabelle}}
 +
| Length
 +
| Länge des Datenpaketes, evtl abzüglich der bereits definierten Headerbytes
 +
|}
 +
 +
{|{{Blaueschmaltabelle}}
 +
| Byte 1
 +
| Type
 +
| 130 = Session Referral
 +
|-
 +
| Byte 2
 +
| Dest Net
 +
| rowspan=2 | Adresse des Empfängers
 +
|-
 +
| Byte 3
 +
| Dest Node
 +
|-
 +
| Byte 4
 +
| Src Net
 +
| rowspan=2 | Adresse des Absenders
 +
|-
 +
| Byte 5
 +
| Src Node
 +
|-
 +
| Byte 6
 +
| SessionID1
 +
| rowspan=2 | Session ID, eindeutig beim Empfänger
 +
|-
 +
| Byte 7
 +
| SessionID2
 +
|-
 +
| Byte 8
 +
| rowspan=3 colspan=2 | Datenpaket, Format abhängig von der Applikation
 +
|-
 +
|  ...
 +
|-
 +
| Byte n
 +
|-
 +
|}
 +
  
 
==Siehe auch==
 
==Siehe auch==
Zeile 106: Zeile 181:
 
** [[RNcom Schicht 0 UART Spezifikation]]
 
** [[RNcom Schicht 0 UART Spezifikation]]
 
** [[RNcom Schicht 0 TCP-IP Stream Spezifikation]]
 
** [[RNcom Schicht 0 TCP-IP Stream Spezifikation]]
 +
** [[RNcom Schicht 0 IP-Multicast Spezifikation]]
  
 
* [[RNcom Schicht 1]]
 
* [[RNcom Schicht 1]]
 
** [[RNcom Schicht 1 Einfaches Dynamisches Routing]]
 
** [[RNcom Schicht 1 Einfaches Dynamisches Routing]]
−
** [[RNcom Schicht 0 IP-Multicast Spezifikation]]
 
  
 
* RNcom Schicht 2
 
* RNcom Schicht 2

Aktuelle Version vom 12. März 2006, 18:37 Uhr

RNcom Schicht 2 - Übersicht

Layer2.gif


Allgemeines

Die von Schicht 1 zur Verfügung gestellten Kommunikationsinfrastruktur bietet einen virtuellen zusammenhängenden Kommunikationsraum in dem einfache Nachrichten übertragen werden können. Dies ist jedoch für eine Anwendung meistens nicht ausreichend. Wünschenswert wären folgende Eigenschaften für Nachrichten:

  • Datenintegrität: Es kommt genau die Nachricht an, die losgeschickt wurde, z.B. durch CRC gesichert
  • Übertragungssicherung: Es ist sichergestellt, dass die Nachricht ankommt, z.B. durch
    • Ack/Nack/Timeout: Empfangsbestätigungen für Nachrichten
    • Automatische Retries wenn der Versand fehlschlägt
  • Reihenfolge: Beim Versendung mehrere Nachrichten kommen diese vollständig und in genau der Reihenfolge an, in der sie abgesendet wurden (Stream).

Die Aufgabe der Schicht 2 ist nun die Sicherstellung einiger oder aller dieser Eigenschaften.

Zu beachten ist, das jede Eigenschaft auch gewisse Nachteile bezüglich Übertragungslatenz sowie Protokollkomplexität und -overhead mit sich bringt. Aus diesem Grund werden im folgenden zwei mögliche Übertragungsmodi definiert, die schnell, flexible und auch auf einem uC einfach zu implementieren sind.


Verbindungslose Nachrichten

Bei Verbindungslosen Nachrichten erwartet der Sender weder eine (direkte) Antwort noch einen Timeout wenn die Übertragung fehlschlägt. Es wird weder die Übertragungs- noch die Datenintegrität gesichert. Im Gegenzug sind verbindungslose Nachrichten schnell und unkomplizierte Einwegnachrichten.


Sessionbasierte Nachrichten

Sessionbasierte Nachrichten können genutzt werden, um Antwortnachrichten einer ursprünglichen Nachricht zuzuordnen. Dabei wird keine vollständiger Stream aufgebaut, sondern nur eine sehr leichtgewichtige Session. Es werden weder Übertragungs- noch Datenintegrität garantiert. Insbesondere können Nachrichten mehrfach oder gar nicht beim Empfänger ankommen. Zudem ist die Session nur einseitig. Genau wie die Verbindungslosen Nachrichten sind Sessionbasierte Nachrichten schnell und mit minimalem Protokolloverhead.

Das Funktionsprinzip der Sessionbasierten Nachrichen ist einfach. Es existieren zwei Arten von Nachrichten, Session-Request Nachrichten und Session-Referral Nachrichten. Beide tragen zusätzlich zu ihren Daten eine SessionID, die vom Initiator der Session gewählt wird und für seinen Knoten eindeutig ist. Mit diesen Nachrichten sind nun mehrere Kommunikationsmodi möglich:

  • Request-Response Nachrichten:
    Bei Request-Response Nachrichten schickt der Client eine Session-Request Nachricht an den Server. Dieser antwortet mit genau einer Session-Referral Nachricht die die SessionID der Request-Nachricht trägt. Die Session wird beim Server nicht gespeichert.
    Der Server hat nun die Option auf das Ausbleiben einer Antwortnachricht durch Retries oder Timeouts zu antworten.
  • Continuous Session Nachrichten:
    Auch bei dieser Art von Nachrichten öffnet der Client die Session durch eine Request Nachricht. Der Server bestätigt dies auch sofort, speichert die SessionID und die Adresse des Clients jedoch ab. Nun kann er jederzeit spontane Session-Referral Nachrichten schicken. Diese Session muss von Client implizit geschlossen werden.

Anmerkung: Ob es sich um eine Request-Response oder um eine Continuous Session handelt wird nicht explizit übertragen. Hier muss implizit Einigkeit zwischen Client und Server bestehen. Wenn der Server also nur eine einfache Antwort gibt, der Client aber einen Stream erwartet, wird der Client lange auf Daten warten.

Streams

Eventuell wäre es wünschenswert, lückenlose, gesicherte Nachrichtenstreams zu definieren. Vorerst sollten allerdings Verbindungslose und Sessionbasierte Nachrichten reichen.


Allgemeiner Nachrichtenaufbau:

Es müssen drei Nachrichten (Verbindungslos, Session-Request, Session-Referral) definiert werden.

Length Länge des Datenpaketes, evtl abzüglich der bereits definierten Headerbytes
Byte 1 Type 128 = Sessionless message
Byte 2 Dest Net Adresse des Empfängers
Byte 3 Dest Node
Byte 4 Src Net Adresse des Absenders
Byte 5 Src Node
Byte 6 Datenpaket, Format abhängig von der Applikation
...
Byte n


Length Länge des Datenpaketes, evtl abzüglich der bereits definierten Headerbytes
Byte 1 Type 129 = Session Request
Byte 2 Dest Net Adresse des Empfängers
Byte 3 Dest Node
Byte 4 Src Net Adresse des Absenders
Byte 5 Src Node
Byte 6 SessionID1 Session ID, eindeutig beim Absender
Byte 7 SessionID2
Byte 8 Datenpaket, Format abhängig von der Applikation
...
Byte n


Length Länge des Datenpaketes, evtl abzüglich der bereits definierten Headerbytes
Byte 1 Type 130 = Session Referral
Byte 2 Dest Net Adresse des Empfängers
Byte 3 Dest Node
Byte 4 Src Net Adresse des Absenders
Byte 5 Src Node
Byte 6 SessionID1 Session ID, eindeutig beim Empfänger
Byte 7 SessionID2
Byte 8 Datenpaket, Format abhängig von der Applikation
...
Byte n


Siehe auch

  • RNcom Schicht 2

und auch:


Autor

Von „https://rn-wissen.de/wiki/index.php?title=RNcom_Schicht_2&oldid=6482“

LiFePO4 Speicher Test