- 3D-Druck Einstieg und Tipps         
Ergebnis 1 bis 10 von 975

Thema: Rnbfra Multi-Thread und Netzwerkfähig mit GUI im www, jetzt

Baum-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #11
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    22.06.2005
    Ort
    München
    Beiträge
    113
    @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.

    ciao,
    Ragnar
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken ucomarchitecture.gif  

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

LiFePO4 Speicher Test