RNcom Schicht 2

2006-03-12T17:37:15Z

Vogon: /* Sessionbasierte Nachrichten */

== RNcom Schicht 2 - Übersicht ==

[[Bild: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.

{| {{Blaueschmaltabelle}}
| Length
| Länge des Datenpaketes, evtl abzüglich der bereits definierten Headerbytes
|}

{|{{Blaueschmaltabelle}}
| 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
|-
|}
 

{| {{Blaueschmaltabelle}}
| Length
| Länge des Datenpaketes, evtl abzüglich der bereits definierten Headerbytes
|}

{|{{Blaueschmaltabelle}}
| Byte 1
| Type
| 129 = Session Request
|-
| 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 Absender
|-
| Byte 7
| SessionID2
|-
| Byte 8
| rowspan=3 colspan=2 | Datenpaket, Format abhängig von der Applikation
|-
| ...
|-
| Byte n
|-
|}
 

{| {{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==

* [[RNcom Schicht 0]]
** [[RNcom Schicht 0 UART Spezifikation]]
** [[RNcom Schicht 0 TCP-IP Stream Spezifikation]]
** [[RNcom Schicht 0 IP-Multicast Spezifikation]]

* [[RNcom Schicht 1]]
** [[RNcom Schicht 1 Einfaches Dynamisches Routing]]

* RNcom Schicht 2

und auch:
*[[Network Controller/PC]]
*[[Network Controller/PC Schichten]]
*[[Network Controller/PC Spezifikationen]]

==Autor==

* [[Benutzer:Ragnar|Ragnar]]

[[Kategorie:Projekte]]
[[Kategorie:Software]]

RNcom Schicht 0

2006-03-12T17:30:43Z

Vogon: /* Beispiele für einige Medien */

== RNcom Schicht 0 - Übersicht ==

[[Bild:layer0.gif]]

=== Allgemeines ===

Schicht 0 verbindet mehrere Hardware-devices (Prozessoren) miteinander.
Über die Verbindungen müssen Datenpakete mit vor unterschiedlichen Längen
übertragen werden. Es kann eine maximale Länge der Daten festgelegt werden.
Über die Daten können sonst keine Annahmen gemacht werden. Insbesondere
können die Daten die Werte 0..255 annehmen.

Aufgrund verschiedener Medien und Implementierungen können die Verbindungen
verschiedene Eigenschaften haben. Jede dieser Eigenschaften kann entweder von
dem Medium direkt unterstützt oder ''kann'' (muß aber nicht) durch das
Kommunikationsprotokoll gewährleistet werden.
 
* Sicherung: Der Absender erfährt, ob der Empfänger die Daten empfangen hat oder nicht und kann die Daten wenn nötig mehrfach senden bzw. den Abbruch der Übertragung nach melden. Die zur sicheren Übertragung nötigen Befehle wie Acks, Nacks, usw sowie eventuell nötige Sequenznummern müssen innerhalb der Schicht bleiben und dürfen nicht nach außen sichtbar sein.
 
* Integrität: Es ist sichergestellt, das genau die Daten ankommen, die abgesendet wurden. Integrität wird häufig zusammen mit gesicherten Verbindungen verwendet um falsche Daten neu zu senden.
 
* Bidirektional / Unidirektional: Unidirektionale Verbindungen brauchen spezielle Synchronisation zur Übertragung. Obwohl es möglich ist, diese Synchronisation an den Nutzer weiterzugeben, sollten Unidirektionale Verbindungen immer durch interne Synchronisation zu virtuellen Bidirektionalen Verbindungen erweitert werden.
 
Die Schnittstelle der Verbindung kann sowohl Synchron als auch Asynchron
ausgeführt sein. Auch die Unterstützung mehrerer Threads ist möglich.

=== Beispiele für einige Medien ===
 
* UART:
** Übertragung von Datenpakete z.B. durch Frameing
** Sicherung z.B. durch Acks/Nacks, jedes Paket muss direkt acknowledged werden, vorher wird von dem Sender kein weiteres Paket gesendet.
** Integrität z.B. durch Checksummen am Ende des Pakets
 
* LAN mit TCP-IP streams:
** Übertragung von Datenpaketen z.B. durch <Länge><Daten>
** Sicherung und Integrität durch Transportmedium (TCP-IP) garantiert
** Aufbau der Verbindung z.B. durch Konfiguration (baue RNcom Verbindung zu 192.168.0.10 auf, bzw. lausche auf RNcom Verbindungen auf port 9000)
 
* LAN mit UDP Pakets:
** Übertragung von Datenpaketen z.B. durch UDP-Pakete
** Sicherung z.B. durch Ack bzw. Nack des Empfängers
** Integrität durch UDP-Checksumme gesichert
** Aufbau der Verbindung z.B. durch Autodiscovery innerhalb des lokalen Netzes oder Broadcast Gruppe.
 
* i2c
** Übertragung von Datenpaketen begrenzt durch Start/Stopbedingung.
** In Single-Master Systemen Rückübertragung mit Interrupt durch Lesen beim Slave.
** Sicherung: Durch i2c-Protokoll garantiert
** Integrität z.B. durch Checksumme am Ende der Übertragung
** Aufbau der Verbindungen z.B. durch Konfiguration (RNcom device auf i2c-Adresse 0x20)
 

=== Allgemeiner Nachrichtenaufbau: ===
 

Allgemeines Format der Nachrichten zur oberen Schicht 1 hin

{| {{Blaueschmaltabelle}}
| Length
| Länge des Datenpaketes
|}

{|{{Blaueschmaltabelle}}
| Byte 1
| rowspan=4 | Datenpaket
|-
| Byte 2
|-
| ...
|-
| Byte n
|-
|}

Über die Daten dürfen innerhalb der Schicht 0 keine weiteren Annahmen getroffen werden. Lediglich die Länge der Daten ist bekannt.

==Siehe auch==

* RNcom Schicht 0
** [[RNcom Schicht 0 UART Spezifikation]]
** [[RNcom Schicht 0 TCP-IP Stream Spezifikation]]
** [[RNcom Schicht 0 IP-Multicast Spezifikation]]

* [[RNcom Schicht 1]]
** [[RNcom Schicht 1 Einfaches Dynamisches Routing]]

* [[RNcom Schicht 2]]

und auch:
*[[Network Controller/PC]]
*[[Network Controller/PC Schichten]]
*[[Network Controller/PC Spezifikationen]]

==Autor==

* [[Benutzer:Ragnar|Ragnar]]

[[Kategorie:Projekte]]
[[Kategorie:Software]]

RN-Wissen.de - Benutzerbeiträge [de]

RNcom Schicht 2

RNcom Schicht 0