@alle:
Bei der Implementierung meiner Schicht 1 ist mir noch ein Fehler im Protokoll aufgefallen.
Unser BCC kann den Wert der Kontrollzeichen annehmen. Damit gibt es bestimmte Nachrichten,
die nicht übertragen werden können. Ich schlage deshalb vor, dem BCC auf die Ausgangsdaten
anzuwenden und dann erst zu prefixed. Damit wird der BCC bei Bedarf auch geprefixed.
Zur den Adressen:
@PicNick: Deine Idee mit den Zielklassen finde ich zwar relativ interessant, ich glaube
da vermischen sich aber Schicht 2 und Schicht 4. Meiner Meinung nach sollte die
Schicht 2 nur zwischen beliebigen Adressen vermitteln, unabhängig davon welche Klasse bzw.
welchen Typ diese Knoten haben.
Die Klasse eines Knotens würde ich erst auf Schicht 4 einführen, daran hängt schon relativ
viel highlevel-Bedeutung. Ich hatte da auch eher an 'Dienste' gedacht. z.B. könnte ein
Knoten mit einer bestimmten Adresse den Dienst "Motorcontrol" anbieten, während ein anderer
die Dienste "Bumper", "Infrarotsensoren" und "US-Sensoren" anbietet. Ein Knoten kann also
mehrere Dienste anbieten und die Dienste haben erstmal nichts mit den Adressen zu tun.
@NumberFive: Die Idee mit den 2 Bytes für die Adresse finde ich gut, 8-bit Adressen sind
zu wenig, 24-bit Adressen sind zu lang (schwieriger zu routen, länger zu übertragen). Ich
hatte hier schonmal einen Vorschlag gemacht, den ich jetzt nochmal aufgreifen will:
2 Bytes Adressen, davon 1 Byte "Netz#", 1 Byte "Knoten#"
Für beide Bytes gilt: 0=Broadcast, entweder "0.x" innerhalb des Netzes "x"
oder "0.0" an alle Knoten insgesamt. 255=reserviert.
Wie ist das jetzt mit dem Routing ?
Ich habe mal ein Bild gemalt, wie ich mir das vorstelle. Alles, was innerhalb der RNcom
Wolke ist, hat eine RNcom Adresse und wird als RNcom geroutet. Innerhalb von RNcom gibt
es verschiedene Medien. Eines davon ist LAN. Dabei werden über vorher konfigurierte
IP-Verbindungen RN-Frames übertragen. Geroutet wird dabei eigentlich zweimal - einmal
auf RNcom Ebene (auf die IP-Verbindung), ein zweites Mal das IP-Paket innerhalb des
IP-Netzes. Eventuell wird am Empfänger dann nochmal auf RNcom Ebene geroutet.
Ganz konkret bedeutet das: ein RN-Com Knoten kann nicht direkt mit einer
bestimmten IP-Adresse kommunizieren. Ein Programm kann aber z.B. auf einem bestimmten
Port lauschen und dort eine RNcom Verbindung anbieten. Um nun eine GUI mit diesem Rechner
zu verbinden konfiguriert der User seine GUI automatisch die IP-Verbindung aufzubauen.
Der RNcom Router stellt dann fest, welche RNcom Netze hinter der neuen Verbindung stehen
und routet dann automatisch.
Und zum Schluß noch was ganz anderes:
Lasst uns dem Kind doch noch einen Namen geben. Ich würde die Schichten 1-3 (den ganzen
Kommunikationskram) gerne unter einem Namen zusammenfassen (z.B. RNcom oder uCcom). Und
dann für die Schicht 4 einen Namen der mehr auf die Intelligenz bzw. die Softwaremodule
anspielt.
BTW: Ich würde erst gerne die Schichten 1-3 festzurren bevor wir über Schicht 4 spekulieren.
Zitieren
Lesezeichen