Zitat Zitat von PicNick
Wenn es interessiert, ich hab ein paar Aspekte von Netzwerken hier beleuchtet. ohne irgendwelche Präjudizien für bestimmte Lösungen, soweit das möglich war

https://www.roboternetz.de/wissen/in.../Network_MC/PC
Vielen Dank PicNick, dieser Artikel ist wirklich gut und er kommt im
wesentlichen zu den Ergebnissen, zu denen ich gestern auch gekommen
bin (hatte leider kein Netz).

Im wesentlichen denke ich, dass wir bei unseren Planungen
schichtorientiert denken müssen. Das ganze wird doch ein recht
umfangreiches System und Schichten werden uns helfen, das ganze
besser zu planen, besser zu verstehen und besser zu implementieren.
Klar definierte Schichten sind das A und O an der Geschichte.

PicNick hat schon einen Anlauf gemacht, diese Schichten zu definieren,
ich möchte es nochmal versuchen bzw. meine Meinung dazu sagen.
Ähnlichkeiten mit ISO/OSI sind nicht ausgeschlossen, ich will aber
keineswegs darauf rumreiten. Es geht mir außerdem erstmal nur darum,
welche Aufgaben diese Schichten haben sollen, nicht, wie sie konkret
implementiert werden können.


Schicht 1: Übertragung
  • - Definiert Protokolle für die Übertragung eines Frames über verschiedene Hardwaremedien.
    - Inhalt des Frames (Sender, Empfänger) nicht wichtig
    - verbindungslos (keine Antwort des Empfängers)
    - nicht zwingend abgesichert (Nachrichten können verloren bzw. kaputt gehen)

    - Schnittstelle zu Schicht 2: sendFrame(data, length)


Schicht 2: Routing
  • - Definiert Frames mit Adressen für Sender und Empfänger
    - Jeder Teilnehmer ist ein Knoten und hat eine global eindeutige Adresse
    - Alle Knoten sind gleichwertig.
    - Die real vorhandene Topologie der Knoten wird versteckt.
    - Eventuell erleichtert eine zweistufige Topologie (lokal/entfernt) die Implementierung.

    - Routet die Frames zwischen verschiedenen devices
    - Kennt alle verfügbaren Geräte der Schicht 1
    - Entscheidet bei ausgehenden Nachrichten, welches device die Nachricht schickt
    - Entscheidet bei eingehenden Nachrichten, ob der Frame an ein
    anderes device geschickt an Schicht 3 weitergeben wird.

    - eventuell eine automatische Vergabe von Adressen (bei PicNick: enumeration)

    - Schnittstelle zu schicht 1: receiveFrame(data, length)
    - Schnittstelle zu Schicht 3: sendFrame(sender, data, length)



Schicht 3: Verbindung
  • - Kann zusätzliche Verbindungseigenschaften realisieren (durch Steuerdaten)

    Mögliche Eigenschaften:
    - Datenintegrität (CRC)
    - Empfangsbestätigung (Acknowledge)
    - Verbindungsorientierter Nachrichtenaustausch (Acknowledge mit Wiederholung)
    - ping

    - Schnittstelle zu Schicht 2: receiveFrame(sender, data, length)
    - Schnittstelle zu Schicht 4: sendFrame(connectionType, receiver, data, length)


Schicht 4: Dienste
  • - Weist den Daten eine Struktur und eine Bedeutung zu, z.B. Kommandos und Parameter
    - Definiert Kommandos für gemeinsame Dienste
    - Diese Dienste bilden die Essenz einer gemeinsamen Steuersoftware, GUI, etc

    Mögliche Dienste sind z.B.
    - Verzeichnisdienst/Discoverydienst
    - Heartbeat/Ping
    - Debuggingschnittstelle

    - Schnittstelle zu Schicht 3: receiveFrame(sender, data, length


Anmerkung: Diese Architektur ist im wesentlichen darauf ausgelegt, einzelne
asynchrone Nachrichten zu übertragen. Ich möchte noch kurz begründen,
warum ich verbindungsorientierte 'Streams' nur stiefmütterlich
behandelt habe:
- Streams brauchen viel Rechenzeit und vergrößern das Datenvolumen
- Die korrekte Behandlung von Streams in uCs ohne Threads ist schwierig (Parallelität).
- Die meisten Dienste lassen sich problemlos auf verbindungslosen Nachrichten abbilden

- Teilnehmer können jederzeit wegfallen.
uCs werden ohne Neustart des Gesamtsystems neu programmiert, Programme neu
gestartet, etc. Streams können dies nicht verhindern sondern nur feststellen.
Der einzige Ausweg aus der Situation ist die Dienste darauf auszulegen,
störungsresistent zu arbeiten, z.B. den Betrieb nach Wiederverfügbarkeit
beider Kommunikationspartner automatisch wieder aufzunehmen.

Sind die Dienste aber sowieso störungsresistent ausgelegt, kann man auch
unsichere Verbindungen in Kauf nehmen.

Anmerkung 2:
Für mich zeichnet sich ab, dass wir das Projekt in zwei große Teile
zerlegen können. Zum einen die Implementierung eines Nachrichtensystems
(Schichten 1-3), zum anderen die Definition allgemeiner Dienst für
Roboterkomponenten (Schicht 4)


@NumberFive:
Wir arbeiten hier nicht für andere sondern für uns selbst. Zumindest
mir geistert diese Idee schon längere Zeit im Kopf herum und dies
hier ist nur der richtige Anlass. Ausserdem kommen wir gut voran
auch wenn man noch keinen Code sieht.

Das ganze ist jetzt erstmal ein Vorschlag. Ich bitte um Rückmeldung.

ciao,
Georg