Hallo Community, im Anhang findet sich ein Schema für ein Netzwerkprotokoll. Dabei sollen verschiedene Controller einige Funktionen "over the Air" zur Verfügung stellen. Mit dem Resource Locator wird eine Funktion auf einem Device direkt angesprochen. Kurze Erklärung der Grafik: Schritt 1: Broadcast Der MIG generiert Zeitstempel und ZufallsID für die Unterhaltung -> Broadcast wird gesendet (zum Beispiel "Lichtkanal 33 auf "50%", wobei "Lichtkanal 33" = Resource Locator und "50%" = DATA) -> Gegenstelle die die Resource anbieten kann verarbeitet diese und antwortet. Ab BRDCST ist der Luftraum für andere Devices gesperrt, sie senden nicht. Schritt 2: Antwort auf Broadcast Die entsprechende Gegenstelle formuliert eine Antwort mit dem Ergebnis, oder antwortet im Fehlerfall nicht (Timeout). MSGID und Zeitstempel werden aus BRDCST übernommen. Schritt 3: Bestätigen der Antwort Im Erfolgsfall wird FREE gesendet, im Fehlerfall wird noch einige Male versucht die Daten zu übertragen, ansonsten FREE. Nach FREE läuft in jedem Device ein zufälliger Counter (0-10ms) auf 0, erst dann kann wieder gesendet werden (wenn nicht schon ein anderes Device sendet) Das soll verhindern, dass sich mehrere wartende Devices nach Free auf den Luftraum stürzen. Ausserdem wird die MSG ID für X Sekunden gespeichert. Kommt eine Nachricht mit schon gespeicherter ID oder älter als X Sekunden wird ein Fehler verursacht. (BCE 3 und BCE 4) Das soll ein abfangen und erneutes einsenden von Nachrichten verhindern. Meine Frage nun: Würde das theoretisch und praktisch funktionieren? Vielen Dank!
Angehängte Dateien:
-
cmncate.png
510 KB
> Ausserdem wird die MSG ID für X Sekunden gespeichert. Kommt eine > Nachricht mit schon gespeicherter ID oder älter als X Sekunden wird ein > Fehler verursacht. (BCE 3 und BCE 4) So muss man zum Abfangen und neu Senden auch nur eine Zahl ändern und ne MD5 neu generieren. Also sicher ist das nicht. Wenn die Kommunikation sicher sein soll muss sie eben verschlüsselt werden. Am besten Asymetrisch, so dass der Schlüssel nur im Sender gespeichert werden muss. Alternativ tuts auch eine entsprechende Signatur, am besten auch die asymetrisch. > Nach FREE läuft in jedem Device ein zufälliger Counter (0-10ms) auf 0, > erst dann kann wieder gesendet werden (wenn nicht schon ein anderes > Device sendet) > Das soll verhindern, dass sich mehrere wartende Devices nach Free auf > den Luftraum stürzen. Das verhindert keine Fehler sondern verschleiert sie nur. Dein Protokoll muss es abkönnen wenn mehrere Teilnehmer auf einmal senden wollen. Bei I2C gewinnt soweit ich weiß zB. der, der die größere Zahl zusammenhängender 0en sendet. Das ist aber wohl auch dem Bus aufbau geschuldet. Kommt wohl drauf an wie dein Physical layer mit Kollisionen umgeht.
> So muss man zum Abfangen und neu Senden auch nur eine Zahl ändern und ne > MD5 neu generieren. Also sicher ist das nicht. Wenn die Kommunikation > sicher sein soll muss sie eben verschlüsselt werden. Am besten > Asymetrisch, so dass der Schlüssel nur im Sender gespeichert werden > muss. Alternativ tuts auch eine entsprechende Signatur, am besten auch > die asymetrisch. Hab ich vergessen zu sagen: Hätte die Frames vor dem Senden durch XTEA verschlüsseln lassen, und an der Gegenstelle wieder entschlüsselt. Alle Devices kennen das geheimsame Geheimnis, mit dem sie die Frames ver- und entschlüsseln. In der Luft ist somit nur der Hash, der zwar mitgeschnitten, aber nicht bearbeitet werden kann. > Das verhindert keine Fehler sondern verschleiert sie nur. Dein Protokoll > muss es abkönnen wenn mehrere Teilnehmer auf einmal senden wollen. Bei > I2C gewinnt soweit ich weiß zB. der, der die größere Zahl > zusammenhängender 0en sendet. Das ist aber wohl auch dem Bus aufbau > geschuldet. Kommt wohl drauf an wie dein Physical layer mit Kollisionen > umgeht. Was passiert mit einem RFM12 beim Empfangen wenn 2 oder sogar 3 andere RFM12s Senden? Ich verfolge den Ansatz, dass alle Devices wissen, wann im Luftraum eine Kommunikation stattfindet (dazu gehen alle passiven Devices bei BRDCST in den Pausemodus, bzw Senden nicht). Erst wenn der Luftraum wieder frei ist, läuft das random delay. Der schnellste kriegt die nächste Sendeerlaubnis. So kommen gar nie 2 Frames zugleich an, oder? Vielen Dank.
> So kommen gar nie 2 Frames zugleich an, oder? Doch. Vielleicht nicht sofort, aber irgendwann definitiv. Denn random kann ja zufälligerweise auf 2 Controller mal das selbe ausspucken. > Was passiert mit einem RFM12 beim Empfangen wenn 2 oder sogar 3 andere > RFM12s Senden? Ohne es besser zu wissen würde ich sagen es kommt Müll an?
> Doch. Vielleicht nicht sofort, aber irgendwann definitiv. Denn random > kann ja zufälligerweise auf 2 Controller mal das selbe ausspucken. Das stimmt natürlich. Aber wie handeln sich die wartenden Devices aus, wer als nächstes Sendet? Mit der Counter-Methode hätte ich eine relativ hohe Wahrscheinlichkeit, dass es zu keiner Kollision kommt. Natürlich auch nicht das Optimum an Stabilität. > Ohne es besser zu wissen würde ich sagen es kommt Müll an? Hätte ich auch gemeint. Ergo: RFM12 kann nicht mit mehr als 1 Sender umgehen, oder? Vielen Dank.
> Das stimmt natürlich. Aber wie handeln sich die wartenden Devices aus, > wer als nächstes Sendet? Mit der Counter-Methode hätte ich eine relativ > hohe Wahrscheinlichkeit, dass es zu keiner Kollision kommt. Natürlich > auch nicht das Optimum an Stabilität. Vermutlich wird es manchmal gehen und manchmal nicht. Wieso überlegst du dir nicht was in Richtung Token? Also jeder Controller hat eine Adresse, die immer mitgesendet wird und wenn ein Controller einen BRDCAST abgeschlossen hat darf der mit der nächsten Adresse senden. Dabei müssten dann halt alle Adressen jeder Station bekannt sein oder wahlweise die Addressen aufeinanderfolgen. Überleg dir halt ein System, bei dem eindeutig geregelt ist wer als nächstes senden darf.
Quasi eine Zentrale, die nacheinander alle Units fragt, ob sie was zu senden haben. Ich werd das ganze mal umschreiben und mich dann wieder melden. Vielen Dank.
> Quasi eine Zentrale, die nacheinander alle Units fragt, ob sie was zu > senden haben. > Ich werd das ganze mal umschreiben und mich dann wieder melden. Kann man machen, war so aber nicht gedacht von mir. Ein Token ist die Erlaubnis zu senden. Eine Station hat das Token, darf einen BRDCAST machen. Nach dem BRDCAST muss sie das Token an die nächste Station weitergeben. Es darf nur immer ein Token im Umlauf sein und das Token muss immer weitergegeben wird. Wenn das Token verloren geht darf eine fest bestimmte Instanz das Netzwerk neu starten. Man muss nur eine Methode finden, die nächste Station zu finden, der man das Token gibt. Das habe ich gemeint. Ist aber nur eine von vielen Möglichkeiten.
Nach reichlicher Überlegung und einigen Skizzen steht nun fest, dass es in Richtung PCF (http://de.wikipedia.org/wiki/Point_Coordination_Function) gehen wird. Viele Grüße aus Graz.
Angehängte Dateien:
-
cmncate_logo.png
98 KB -
logo.png
120 KB
Hier mal die aktuellen Projektlogos. Viele Grüße
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.