Netzwerkprotokoll für RFM12

[cd_brenner]

Hallo Community,

seit einigen Monaten - nach einer C-Vorlesung in der Uni - habe ich mich mit dem Thema "Microcontroller" zu beschäftigen begonnen und einiges darüber gelesen. Ich finde diese Dinger genial, vor allem die Vielfältigkeit reizt mich besonders.
Da ich zur Zeit am Bauen eines Terrariums bin möchte ich dieses natürlich mit einem AVR Microcontroller steuern. Grundsätzlich will ich allerdings mehrere Units in meiner Wohnung haben die unterschiedliche Aufgaben übernehmen und vor allem miteinander über RFM12 Module kommunizieren können.
Als Beispiel soll das Terrarium die Uhrzeit von der Digitaluhr ablesen können.

Ich habe deshalb auch begonnen ein Netzwerkprotokoll zu entwerfen - vorerst nur theoretisch auf Papier. Ich würde auf ein zentral gesteuertes System setzen in dem ein "Tower" alle Units nacheinander fragt ob sie Daten zu senden haben (Token Ring) und die Datenframes vom Sender zum Empfänger leitet.
Um Sendefehler zu erkennen verwende ich eine CRC Checksumme im Datenframe.

Hier das Schema:


Ad 1)
Der Tower wählt die nächste UnitID aus seinem Speicher und versucht dieser das Sendetoken zu schicken.

Ad 2)
Die Unit bestätigt den Tokenerhalt oder reagiert nicht nach einer bestimmten Zeit.

Ad 3)
Der Tower versucht einen Datenframe* zu senden oder sendet ein READY, wenn keine Daten zum Senden vorhanden sind.
Falls ein Timeout passiert wird das Token an die nächste Unit weitergegeben.

Ad 4)
Falls ein Datenframe ankommt wird dieser auf Gültigkeit** untersucht und im FIFO gespeichert, damit er später weiterverarbeitet werden kann.
Wenn ein Fehler auftritt wird der Frame (NAK) nocheinmal angefordert. (max. 3x)
Wenn Daten zum Senden vorhanden sind werden diese an den Tower zurückgesendet, ansonsten: READY.

Ad 5)
Der Frame wird wieder auf Gültigkeit** überprüft und ggf. gespeichert, wenn die Daten ungültig sind werden sie erneut angefordert.
Wenn ein NAK ankommt (= Datenfehler Unit) wird das Datenpaket erneut gesendet.
Falls READY ankommt (= Unit hatte keine Daten) wird das Token weitergegeben.

Ad 6)
Sobald das Token weitergegeben wurde hat die Unit keine Sendeerlaubnis mehr.
Wenn ein NAK ankommt werden die Daten erneut gesendet.

* ein Datenframe könnte wie folgt aussehen:

ID | TIME | sender | empfänger | DATA | CRC

** Gültigkeit:

Jede Unit speichert empfangene IDs für eine Zeit von X Sekunden in einer Blocklist und verwift Datenframes mit dieser ID.
Jede Nachricht hat eine Lebensdauer von X Sekunden, wenn diese abgelaufen ist werden Frames auch verworfen. Damit will ich erneutes einsenden vom mitgeschnittenen Frames verhindern.

Weiters möchte ich die Datenpakete mittels AES verschlüsseln um dem ganzen System mehr Sicherheit zu verleihen. Jede Unit soll dabei einfach einen geheimen Key gespeichert haben und damit die Datenframes verschlüsseln.

Mich würde interessieren ob dieses Projekt in der Praxis umsetzbar ist, wo es scheitern könnte, und wie man es verbessern kann.

Vielen Dank,
Markus

[markusj]

Eigentlich ist das kein Token-Passing sondern eher ein Polling-Verfahren bei dem der pollende Master in "Tower" umbenannt wurde.
Zwei Dinge:
1. Du möchtest die Sendeaufforderung evtl. auch wiederholen ("Token-Verlust")
2. AES erfordert einiges an Rechenleistung und außerdem hast du dann für jedes Gerät einen Public-Key. Der Sender verschlüsselt die Daten mit dem Public-Key des Empfängers. Dieser Entschlüsselt dann mit seinem Private-Key.

Normalerweise verwendet man als Medienzugriffsverfahren CSMA (im Falle der RFM-Familie ist keine CD/CA möglich). Der Polling-Ansatz ermöglicht aber prinzipiell gewisse Echtzeitgarantien, wobei das durch die Unzuverlässigkeit des Mediums eingeschränkt wird.

mfG
Markus

[cd_brenner]

1. Du möchtest die Sendeaufforderung evtl. auch wiederholen ("Token-Verlust")

Da ja der Tower die Tokens vergibt und nicht die Unit das Token weitergibt bekommt UnitX nach einer Runde ja sowiso das Token wieder, oder?

2. AES erfordert einiges an Rechenleistung und außerdem hast du dann für jedes Gerät einen Public-Key. Der Sender verschlüsselt die Daten mit dem Public-Key des Empfängers. Dieser Entschlüsselt dann mit seinem Private-Key.

Kann die geforderte Rechenleistung für die Verschlüsselung auf einem AtMega644 bei 20Mhz zum Probem werden?
Ich dachte AES ist ein symmetrisches Kryptosystem bei dem ich einen geheimen Schlüssel zum Ver- & Entschlüsseln habe.

Der Advanced Encryption Standard (AES) ist ein symmetrisches Kryptosystem

Quelle: http://de.wikipedia.org/wiki/Advance...ption_Standard

Eignen sich andere Algorithmen wie XTEA oder Blowfish besser für diesen Anwendungsfall?

Vielen Dank,
Markus

[markusj]

Da ja der Tower die Tokens vergibt und nicht die Unit das Token weitergibt bekommt UnitX nach einer Runde ja sowiso das Token wieder, oder?

Schon klar, aber: Du unternimmst damit noch nicht einmal den Versuch, eine stabile Kommunikation zu schaffen, weil du im Zweifelsfalle schon vor Kommunikationsbeginn aufgibst. Bei einer guten Funkverbindung sollte das eber weniger problematisch sein ...

Kann die geforderte Rechenleistung für die Verschlüsselung auf einem AtMega644 bei 20Mhz zum Probem werden?
Ich dachte AES ist ein symmetrisches Kryptosystem bei dem ich einen geheimen Schlüssel zum Ver- & Entschlüsseln habe.

Mein Fehler. Ich habe AES mit Public-Key-Krypto in einen Topf geworfen (und bin damit eher bei SSL rausgekommen). Davon abgesehen: Es hängt immer davon ab, wieviel Zeit du hast. Der langsamste Kryptoalgo ist kein Problem, wenn du keinen engen Zeitrahmen hast.

Vielen Dank,
Markus

Haha

mfG
Markus

[cd_brenner]

Schon klar, aber: Du unternimmst damit noch nicht einmal den Versuch, eine stabile Kommunikation zu schaffen, weil du im Zweifelsfalle schon vor Kommunikationsbeginn aufgibst. Bei einer guten Funkverbindung sollte das eber weniger problematisch sein ...

Du meinst also, dass ich ähnlich wie bei einer fehlerhaften Datenübertragung auch auf fehlerhafte Tokenübertragung mit direkter Sendewiederholung reagieren soll?
Was bringt mir das für Vorteile wenn die Unit direkt nochmal das Token bekommt anstatt erst in der nächsten Runde?

Es hängt immer davon ab, wieviel Zeit du hast. Der langsamste Kryptoalgo ist kein Problem, wenn du keinen engen Zeitrahmen hast.

Ganz hab ich's sowiso noch nicht heraussen wie ich mein Programm schreiben muss, damit ich den kompletten Controller nicht sperre, wenn ich z.B. 3h FadeIn bei einer Halogenlampe machen will.

Vielen Dank.

[markusj]

Du meinst also, dass ich ähnlich wie bei einer fehlerhaften Datenübertragung auch auf fehlerhafte Tokenübertragung mit direkter Sendewiederholung reagieren soll?
Was bringt mir das für Vorteile wenn die Unit direkt nochmal das Token bekommt anstatt erst in der nächsten Runde?

Nehmen wir Mal an, du brauchst jede Sekunde neue Daten. Wenn das "Token" bei einem Knoten nicht ankommt, wird er im besten Fall eine Sekunde später (bei der nächsten Iteration) regieren. Oder wenn irgendetwas die Verbindung stark verschlechtert, erst noch viel später. Dieser Aussetzer kann unter Umständen zu lange für deinen Anwendungszweck sein.

Ganz hab ich's sowiso noch nicht heraussen wie ich mein Programm schreiben muss, damit ich den kompletten Controller nicht sperre, wenn ich z.B. 3h FadeIn bei einer Halogenlampe machen will.

Ich glaube du möchtest dich Mal ein wenig in Richtung Multitasking auf µCs informieren. Solche einfachen zeitgesteuerten Aufgaben kann man relativ einfach über eine Warteschlange lösen, die in regelmäßigen Abständen (Timer!) gepollt wird. (Stichwort: Delta-Queue). Im Wesentlichen musst du dich einfach darauf einstellen, dass deine Funktionen nicht mehr blockierend warten, sondern sich ihren Zustand merken und dann andere Funktionen weiterrechnen lassen. Das nennt man kooperatives Multitasking.

mfG
Markus