| Zeile 12: | Zeile 12: | ||
meistens nicht ausreichend. Wünschenswert wären folgende Eigenschaften für Nachrichten: | meistens nicht ausreichend. Wünschenswert wären folgende Eigenschaften für Nachrichten: | ||
| − | * Datenintegrität: | + | * Datenintegrität: Es kommt genau die Nachricht an, die losgeschickt wurde, z.B. durch CRC gesichert |
| − | * Übertragungssicherung: Es ist sichergestellt, | + | * Übertragungssicherung: Es ist sichergestellt, dass die Nachricht ankommt, z.B. durch |
** Ack/Nack/Timeout: Empfangsbestätigungen für Nachrichten | ** Ack/Nack/Timeout: Empfangsbestätigungen für Nachrichten | ||
** Automatische Retries wenn der Versand fehlschlägt | ** 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. | Die Aufgabe der Schicht 2 ist nun die Sicherstellung einiger oder aller dieser Eigenschaften. | ||
| Zeile 27: | Zeile 27: | ||
Bei Verbindungslosen Nachrichten erwartet der Sender weder eine (direkte) Antwort noch einen Timeout wenn | Bei Verbindungslosen Nachrichten erwartet der Sender weder eine (direkte) Antwort noch einen Timeout wenn | ||
| − | die Übertragung fehlschlägt. Es wird weder die | + | die Übertragung fehlschlägt. Es wird weder die Übertragungs- noch die Datenintegrität gesichert. Im Gegenzug |
sind verbindungslose Nachrichten schnell und unkomplizierte Einwegnachrichten. | sind verbindungslose Nachrichten schnell und unkomplizierte Einwegnachrichten. | ||
| Zeile 33: | Zeile 33: | ||
=== Sessionbasierte Nachrichten === | === 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. | ||
| + | |||
| + | Wie genau funktioniert das ganze? | ||
| + | |||
| + | Im Prinzip gibt es zwei Arten von Nachrichten, Session-Request Nachrichten und Session-Referral Nachrichten. | ||
| + | Beide tragen zusätzlich zu ihren Daten jeweils eine SessionID. Diese SessionID wird vom Initiator der Session | ||
| + | (Client) festgelegt und muss innerhalb seines Knotens eindeutig sein. Zum Aufbau einer Session schickt | ||
| + | der Client nun einen Session-Request mit der gewählten SessionID an den Endpunkt der Session (Server). | ||
| + | Der Server kann nun jederzeit mit einer Session-Referral Nachricht antworten. Bei dieser hängt der Server | ||
| + | die vom Client gewählte SessionID zusätzlich an die Nachricht an. Damit sind einfache Request-Response | ||
| + | Mechanismen möglich. | ||
| + | |||
| + | Wenn der Server die SessionID und die Adresse des Clients speichert, kann er auch spontane Session-Referral | ||
| + | Nachrichten generieren. In diesem Fall muß nur zwischen Client und Server eine Vereinbarung bestehen, wann | ||
| + | die Session geschlossen werden kann. | ||
| + | |||
| + | |||
| + | === Streams === | ||
| + | |||
| + | Eventuell wäre es wünschenswert, lückenlose, gesicherte Nachrichtenstreams zu definieren. Vorerst | ||
| + | sollten allerdings Verbindungslose und Sessionbasierte Nachrichten reichen. | ||
=== Beispiele === | === Beispiele === | ||
| + | TODO | ||
Version vom 11. März 2006, 22:53 Uhr
|
An diesem Artikel arbeitet gerade Mitglied Ragnar.
Am besten momentan noch keine gravierenden Ergänzungen / Änderungen vornehmen. Dieser Hinweis verschwindet wenn der Autor soweit ist. Sollte dieser Hinweis länger als drei Tage auf einer Seite sein, bitte beim Autor Ragnar per PM / Mail oder Forum nachfragen ob er vergessen wurde. |
Inhaltsverzeichnis
RNcom Schicht 2 - Übersicht
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.
Wie genau funktioniert das ganze?
Im Prinzip gibt es zwei Arten von Nachrichten, Session-Request Nachrichten und Session-Referral Nachrichten. Beide tragen zusätzlich zu ihren Daten jeweils eine SessionID. Diese SessionID wird vom Initiator der Session (Client) festgelegt und muss innerhalb seines Knotens eindeutig sein. Zum Aufbau einer Session schickt der Client nun einen Session-Request mit der gewählten SessionID an den Endpunkt der Session (Server). Der Server kann nun jederzeit mit einer Session-Referral Nachricht antworten. Bei dieser hängt der Server die vom Client gewählte SessionID zusätzlich an die Nachricht an. Damit sind einfache Request-Response Mechanismen möglich.
Wenn der Server die SessionID und die Adresse des Clients speichert, kann er auch spontane Session-Referral Nachrichten generieren. In diesem Fall muß nur zwischen Client und Server eine Vereinbarung bestehen, wann die Session geschlossen werden kann.
Streams
Eventuell wäre es wünschenswert, lückenlose, gesicherte Nachrichtenstreams zu definieren. Vorerst sollten allerdings Verbindungslose und Sessionbasierte Nachrichten reichen.
Beispiele
TODO
Allgemeiner Nachrichtenaufbau:
Kommt alles noch ...
Die Nachrichten vom Typ 128..255 werden an die Schicht 2 weitergeleitet und müssen geroutet werden.
Deshalb wird für diese Nachrichten das Format um die Ziel- und Absenderadresse erweitert.
| Length | Länge des Datenpaketes, evtl abzüglich der bereits definierten Headerbytes |
| Byte 1 | Type | 128..255 = Schicht 2 Nachricht |
| Byte 2 | Dest Net | Netznummer des Empfängers |
| Byte 3 | Dest Node | Knotennummer des Empfängers |
| Byte 4 | Src Net | Netznummer des Absenders |
| Byte 5 | Src Node | Knotennummer des Absenders |
| Byte 6 | Datenpaket, Format abhängig von Schicht 2 | |
| ... | ||
| Byte n | ||
Siehe auch
- RNcom Schicht 2
und auch:
Autor
