RNcom Schicht 2 - Versionsgeschichte

Vogon: /* Sessionbasierte Nachrichten */

2006-03-12T17:37:15Z

‎Sessionbasierte Nachrichten

Ragnar_alt am 12. März 2006 um 13:44 Uhr

2006-03-12T13:44:05Z

Ragnar_alt am 12. März 2006 um 13:42 Uhr

2006-03-12T13:42:23Z

Ragnar_alt am 12. März 2006 um 10:29 Uhr

2006-03-12T10:29:25Z

Ragnar_alt am 11. März 2006 um 21:53 Uhr

2006-03-11T21:53:01Z

Ragnar_alt am 11. März 2006 um 19:15 Uhr

2006-03-11T19:15:24Z

Ragnar_alt am 11. März 2006 um 18:37 Uhr

2006-03-11T18:37:51Z

Ragnar_alt am 11. März 2006 um 12:23 Uhr

2006-03-11T12:23:42Z

Neue Seite

{{Baustelle|Ragnar}}

== RNcom Schicht 2 - Übersicht ==

[[Bild:Layer2.gif]]

=== Allgemeines ===

In Schicht 2 werden nun die verbindungslosen Nachrichten der Schicht 1 weiter veredelt. Die Schicht 2
weis nichts mehr von Segmenten und Devices, die Schicht 2 kennt nur noch eine Menge an Adressen mit denen
sie kommunizieren kann.

Kommt alles noch ...

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

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

{|{{Blaueschmaltabelle}}
| 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
| rowspan=3 colspan=2 | Datenpaket, Format abhängig von Schicht 2
|-
| ...
|-
| Byte n
|-
|}

==Siehe auch==

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

* [[RNcom Schicht 1]]
** [[RNcom Schicht 1 Einfaches Dynamisches Routing]]
** [[RNcom Schicht 0 IP-Multicast Spezifikation]]

* RNcom Schicht 2

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

==Autor==

* [[Benutzer:Ragnar|Ragnar]]

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

@@ Zeile 42: / Zeile 42: @@
 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.
@@ Zeile 49: / Zeile 49: @@
 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 ===

← Nächstältere Version		Version vom 12. März 2006, 13:44 Uhr
Zeile 1:		Zeile 1:
−	~~{{Baustelle\|Ragnar}}~~
−
	== RNcom Schicht 2 - Übersicht ==		== RNcom Schicht 2 - Übersicht ==

@@ Zeile 39: / Zeile 39: @@
 Verbindungslosen Nachrichten sind Sessionbasierte Nachrichten schnell und mit minimalem Protokolloverhead.
-Wie genau funktioniert das ganze?
+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
-Im Prinzip gibt es zwei Arten von Nachrichten, Session-Request Nachrichten und Session-Referral Nachrichten.
+SessionID, die vom Initiator der Session gewählt wird und für seinen Knoten eindeutig ist. Mit diesen Nachrichten
-Beide tragen zusätzlich zu ihren Daten jeweils eine SessionID. Diese SessionID wird vom Initiator der Session
+sind nun mehrere Kommunikationsmodi möglich:
-(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
+* 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.
-Nachrichten generieren. In diesem Fall muß nur zwischen Client und Server eine Vereinbarung bestehen, wann
-die Session geschlossen werden kann.
+* 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.
@@ Zeile 58: / Zeile 56: @@
 Eventuell wäre es wünschenswert, lückenlose, gesicherte Nachrichtenstreams zu definieren. Vorerst
 sollten allerdings Verbindungslose und Sessionbasierte Nachrichten reichen.

@@ Zeile 12: / Zeile 12: @@
 meistens nicht ausreichend. Wünschenswert wären folgende Eigenschaften für Nachrichten:
-* Datenintegrität: Die Nachrichten sind unabhängig vom Kommunikationsmedium immer durch CRC gesichert
+* Datenintegrität: Es kommt genau die Nachricht an, die losgeschickt wurde, z.B. durch CRC gesichert
-* Übertragungssicherung: Es ist sichergestellt, das die Nachricht ankommt, z.B. durch
+* Ü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
-* Streambasiertheit: Bei Versendung mehrere Nachrichten kommen diese vollständig und in genau der Reihenfolge an, in der sie abgesendet wurden.
+* 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.
@@ Zeile 27: / Zeile 27: @@
 Bei Verbindungslosen Nachrichten erwartet der Sender weder eine (direkte) Antwort noch einen Timeout wenn
-die Übertragung fehlschlägt. Es wird weder die Übertragung- noch die Datenintegrität gesichert. Im Gegenzug
+die Übertragung fehlschlägt. Es wird weder die Übertragungs- noch die Datenintegrität gesichert. Im Gegenzug
 sind verbindungslose Nachrichten schnell und unkomplizierte Einwegnachrichten.
@@ Zeile 33: / Zeile 33: @@
 === Sessionbasierte Nachrichten ===
 === Beispiele ===

← Nächstältere Version		Version vom 11. März 2006, 19:15 Uhr
Zeile 35:		Zeile 35:


−	=== Beispiele ~~für die Verwendung~~ ===	+	=== Beispiele ===

@@ Zeile 49: / Zeile 49: @@
 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,
@@ Zeile 60: / Zeile 61: @@
 === Allgemeiner Nachrichtenaufbau: ===
-Kommt alles noch ...
+Es müssen drei Nachrichten (Verbindungslos, Session-Request, Session-Referral) definiert werden.
-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
 {| {{Blaueschmaltabelle}}
@@ Zeile 74: / Zeile 105: @@
   | Byte 1
   | Type
-  | 128..255 = Schicht 2 Nachricht
+  | 129 = Session Request
   |-
   | Byte 2
   | Dest Net
-  | Netznummer des Empfängers
+  | rowspan=2 | Adresse des Empfängers
   |-
   | Byte 3
   | Dest Node
   |-
   | Byte 4
   | Src Net
-  | Netznummer des Absenders
+  | rowspan=2 | Adresse des Absenders
   |-
   | Byte 5
   | Src Node
   |-
   | Byte 6
-  | rowspan=3 colspan=2 | Datenpaket, Format abhängig von Schicht 2
+ | SessionID1
   |-
   |  ...
@@ Zeile 100: / Zeile 136: @@
   |-
   |}
 ==Siehe auch==
@@ Zeile 106: / Zeile 184: @@
 ** [[RNcom Schicht 0 UART Spezifikation]]
 ** [[RNcom Schicht 0 TCP-IP Stream Spezifikation]]
 * [[RNcom Schicht 1]]
 ** [[RNcom Schicht 1 Einfaches Dynamisches Routing]]
 * RNcom Schicht 2

@@ Zeile 8: / Zeile 8: @@
 === Allgemeines ===
-In Schicht 2 werden nun die verbindungslosen Nachrichten der Schicht 1 weiter veredelt. Die Schicht 2
+Die von Schicht 1 zur Verfügung gestellten Kommunikationsinfrastruktur bietet einen virtuellen zusammenhängenden
-weis nichts mehr von Segmenten und Devices, die Schicht 2 kennt nur noch eine Menge an Adressen mit denen
+Kommunikationsraum in dem einfache Nachrichten übertragen werden können. Dies ist jedoch für eine Anwendung
-sie kommunizieren kann.
+meistens nicht ausreichend. Wünschenswert wären folgende Eigenschaften für Nachrichten: