Hallo, mit diesem Beitrag möchte ich euch meine Projektidee zu einem Meshed Network Stack bzw. einer Middleware vorstellen und hoffentlich auch ein paar Anregungen euererseits sammeln. Ziel ist es - grob gesagt - eine Middleware / einen Stack (OpenSource) zu schreiben, der es verschiedenen Geräten ermöglicht andere Geräte oder deren Dienste automatisch zu finden und miteinander zu kommunizieren. Und das soll weitestgehend unabhängig von der verwendeten Art der physikalischen Verbindung funktionieren. Sprich, es sollte möglich sein z.B. mehrere XBee Clients auch mit z.B. CAN-Bus Clients kommunizieren zu lassen. Um das ganze noch etwas detaillierter darzustellen, liste ich hier mal Eckpunkte auf, die mir bisher zu dem Thema eingefallen sind: #ANSI C90 Standard, 8Bit optimiert, geringer RAM/Flash Bedarf, keine floats etc. Damit möchte ich erreichen, dass der Stack auf möglichst vielen Mikrocontrollern läuft bzw. für diese compilierbar ist. #Der Stack benötigt vom System lediglich Sende-/Empfangsroutinen und ein zyklisches Zeitsignal Damit soll es jedem Entwickler möglich sein den Stack zum Laufen zu bekommen. #Jeder Client hat eine eindeutige ID #Jeder Client publiziert im Netz sein Angebot an Daten und andere Clients können diese abonnieren #Es gibt mehrere Sendemethoden: Broadcast, direkte ID2ID Übertragung und Gateway-Anfragen #Ein Client kann zwischen verschiedenen physikalischen Netzen vermitteln, falls er beide Schnittstellen implementiert hat, oder die Reichweite eines Netzwerkes erweitern. Damit nimmt er die Rolle einer "Gateway" ein. Somit können ID2ID Übertragungen theoretisch überall hin geroutet werden. #Fehlerhafte oder entfernte Clients werden allen Clients gemeldet. #Eine Übertragung endet immer mit einer Empfangsbestätigung #Eine Information kann auf mehrere Nachrichten aufgeteilt werden. Was fällt euch noch so ein bzw. was ist euch unklar, oder sorgt für Ungläubichkeit? Was würdet ihr euch an Funktionsumfang von einem solchen Stack wünschen (z.B. gültiger Timestamp für Daten o.Ä.)? Danke schon mal für's mitdenken. Josef
Josef Kaeufl schrieb: > Ziel ist es - grob gesagt - eine Middleware / einen Stack (OpenSource) > zu schreiben, der es verschiedenen Geräten ermöglicht andere Geräte oder > deren Dienste automatisch zu finden und miteinander zu kommunizieren. Keine schlechte Idee, ich hoffe du hast viel Zeit und ein paar Jahre Geduld. Respekt ... Nein im Ernst - weißt du was das für ein Aufwand ist? Ich würde da mit einem mehrköpfigen Entwicklungsteam bis zur ersten Alphaversion ca. 1 Jahr einplanen. Josef Kaeufl schrieb: > keine > floats Wieviel hast du denn schon mit all diesen Schnittstellen gemacht? Bei welcher Schnittstelle hast du Floates gesehen?!!!!! Ich habe die Befürchtung, dass du weder mit CAN, USB, RMF12 oder DMX gearbeitet hast... Das wird ja ein Unendlichkeitsprojekt. Josef Kaeufl schrieb: > #Der Stack benötigt vom System lediglich Sende-/Empfangsroutinen und ein > zyklisches Zeitsignal > Damit soll es jedem Entwickler möglich sein den Stack zum Laufen zu > bekommen. > > #Jeder Client hat eine eindeutige ID Na das geben die Schnittstellen ja teilweise vor oder nutzen es eben auch nicht. Das bestimmt ja die Schnittstelle und nicht du. Wenn du da dann dagegenarbeitest, dann machst du ja die komplette Systematik und Sinn der jeweiligen Verbindungsart kaputt. Contrabeispiel: CAN Josef Kaeufl schrieb: > #Fehlerhafte oder entfernte Clients werden allen Clients gemeldet. > > #Eine Übertragung endet immer mit einer Empfangsbestätigung Das geben genauso die Bus-/ Schnittstellensysteme vor Josef Kaeufl schrieb: > #Eine Information kann auf mehrere Nachrichten aufgeteilt werden. Das ist ungefähr eine Aussage wie: Ein Auto fährt. Das ist trivialste Grundlage eines jeden Bus- oder Schnittstellensystems. Josef Kaeufl schrieb: > Was fällt euch noch so ein bzw. was ist euch unklar, oder sorgt für > Ungläubichkeit? > Was würdet ihr euch an Funktionsumfang von einem solchen Stack wünschen > (z.B. gültiger Timestamp für Daten o.Ä.)? 1. Was für Schnittstellen bzw. Bussysteme sollen denn implementiert werden? 2. Was ist der Sinn dieses Projektes? Was ist der Ansporn dieses mehrjährige Projekt anzugehen? Wer braucht das? *Wozu?* 3. Hast du die nötigen Grundlagen? Nachrichtentechniker? Hast du schonmal mit all diesen Bus/ Schnittstellen gearbeitet?
Eine Frage der Groesse des Netzwerkes. Ich denke an ein mehr oder weniger statisches Netzwerk, wo die Erreichbarkeit schwanken kann, der Nachbar aber da ist, oder sein sollte. Wenn ein neuer Knoten einige Zeit braucht, bis er erkannt wurde ist das ok. Netzgroesse in meinem Fall einige Hundert bis einige tausend Knoten >#Jeder Client publiziert im Netz sein Angebot > an Daten und andere Clients können diese abonnieren Wuerd ich nur auf Anfrage machen, nicht per Broadcast. >#Fehlerhafte oder entfernte Clients werden > allen Clients gemeldet. Per Broadcast ... wer macht denn das ? Alle, die herausgefunden haben, dass ein Nachbar fehlt oder spinnt ? Scheint mir ergibt zuviele Broadcasts. Ich wuerd dem Netzwerk von extern eine Lebensdauer (als variable) der Knoten vorgegeben werden kann. Solange erinnern sich die Nachbarn daran, resp solange wird gesucht. Zusaetzlich wuerd ich knoten eine eigene Lebensdauer zuweisen koennen wollen. Es wird einen Mechanismus brauchen, mit dem sich neue Knoten anmelden koennen, und es wird einen Routing mechanismus brauchen.
>#Eine Information kann auf mehrere Nachrichten aufgeteilt werden
Wenn man mit Quittierungen arbeitet sollte der Knoten zustandsfrei
betrachtet werden. Mit den Quitierungen muss man aufpassen.
Angenommen ein Knoten ist zustandsfrei, dann bedeutet das, dass auf eine
Anfrage entweder die Antwort, oder eine andere Statusmeldung kommt. Der
urspruengliche Frager quittiert die Antwort nicht nochmals.
Hi, wäre es nicht einfacher Avahi(Zeroconf) entsprechend zu adaptieren ? http://avahi.org/wiki/AboutAvahi#Features http://avahi.org/download/avahi.service.5.xml http://de.wikipedia.org/wiki/Zeroconf n.
Viel Spass das "schlank" auf einen 8 Bitter zu portieren.
Moin, guck dir doch mal die gerade als Opensource freigegebene netpp/dclib (siehe auch Beitrag "OpenSource: Universelle library zum Ansteuern von Geräten") an und bau dazu - wenn nötig - einen neuen logical layer (in netpp-Terminologie: "Hub"). Das meiste, was man normalerweise an Geräte-Interkommunikation braucht, ist damit möglich. Als Anmerkung zum Design: KEEP IT SIMPLE und bleib bei einem einfachen Master/Slave-Verhältnis der Geräte. Alle darüber hinausgehende Push/Pull-Funktionalität lagerst Du am besten auf die Low-Level-Seite aus - wie beim Ethernet-Protokoll. Als Transport-Layer gibt es eigentlich nichts schlaueres als das...damit ist die Frage also auch berechtigt, warum Du das Rad neu erfinden willst - denn es ist inzwischen billiger, auf einen netzwerkfähigen 32 ARM-Core umzusteigen, als möglichst viel Intelligenz in einen 8051 Core reinzutricksen (als Beispie). Gruss, - Strubi
Hallo, schon mal danke für das rege Feedback. Ich versuche mal ein paar Sachen zu beantworten so gut ich kann bzw. so weit ich mir selber über manche Sachen im Klaren bin. Lehrmann Michael schrieb: > Keine schlechte Idee, ich hoffe du hast viel Zeit und ein paar Jahre > Geduld. Respekt ... Nein im Ernst - weißt du was das für ein Aufwand > ist? Ich würde da mit einem mehrköpfigen Entwicklungsteam bis zur ersten > Alphaversion ca. 1 Jahr einplanen. Ich ging bisher von einem Zeitaufwand von ca. 9 Monaten aus, wobei ich daran nur abends arbeiten werde. Mir schien bisher der Zeitrahmen vernünftig, da ich erst nach OSI-Layer 2 ansetzen werde und dann den Stack bzw. dessen Funktionsumfang auch so simpel wie nur möglich halten möchte. Wenn bis dahin eine funktionierende Alphaversion fertig ist, wäre ich für mich im Zeitplan :) Lehrmann Michael schrieb: > #Jeder Client hat eine eindeutige ID > > Na das geben die Schnittstellen ja teilweise vor oder nutzen es eben > auch nicht. Das bestimmt ja die Schnittstelle und nicht du. Wenn du da > dann dagegenarbeitest, dann machst du ja die komplette Systematik und > Sinn der jeweiligen Verbindungsart kaputt. Contrabeispiel: CAN Das stimmt schon irgendwie. Ich muss doch aber meine Clients im Knoten auf eine Weise adressieren können. Was spricht dagegen z.B. aus einer CAN ID oder einer MAC Adresse etwas zu berechnen, was in diesem Stack/Layer auch verstanden wird. Gehst du bei deinem Contrabeispiel davon aus, dass die Knoten in diesem Stack Daten auch zyklisch versenden? Lehrmann Michael schrieb: > #Eine Übertragung endet immer mit einer Empfangsbestätigung > > Das geben genauso die Bus-/ Schnittstellensysteme vor Das schon, was ist aber bei einer Gateway. Falls die Gateway über Schnittstelle A korrekt Daten empfängt, diese aber nicht über Schnittstelle B ordnungsgemäß weiter leitet, würde dem Sender nicht auffallen, dass die Daten nicht an den Empfänger weitergeleitete wurden. Lehrmann Michael schrieb: >> #Eine Information kann auf mehrere Nachrichten aufgeteilt werden. > > Das ist ungefähr eine Aussage wie: Ein Auto fährt. Das ist trivialste > Grundlage eines jeden Bus- oder Schnittstellensystems. Naja, für ein Bussystem ist das nicht so selbstverständlich glaube ich. Kann man mit dem CAN-Bus wirklich mehrere Segmente übertragen? Das geht ja erst, sobald man sich eines Transportlayers (z.B. TP1.6) bedient. Der Bus an sich kann nur Extended Frames, oder? Ich wollte damit eigentlich ausdrücken, dass ein Knoten bzw. dessen versendete Daten nicht durch die definierte Größe eines Pakets limitiert werden soll. Lehrmann Michael schrieb: >> Was fällt euch noch so ein bzw. was ist euch unklar, oder sorgt für >> Ungläubichkeit? >> Was würdet ihr euch an Funktionsumfang von einem solchen Stack wünschen >> (z.B. gültiger Timestamp für Daten o.Ä.)? > > 1. Was für Schnittstellen bzw. Bussysteme sollen denn implementiert > werden? > 2. Was ist der Sinn dieses Projektes? Was ist der Ansporn dieses > mehrjährige Projekt anzugehen? Wer braucht das? *Wozu?* > 3. Hast du die nötigen Grundlagen? Nachrichtentechniker? Hast du > schonmal mit all diesen Bus/ Schnittstellen gearbeitet? 1. Ich will keine Schnittstelle implementieren. Ich will daran anknüpfen. 2. Für mich persönlich macht es Sinn, da ich dadurch hoffentlich nicht dümmer werde. "Wer braucht das?" ist eine gut Frage und ich glaube ich kann sie auch nicht zufriedenstellend beantworten. 3. Ich habe schon einige Grundlagen. Bin ja auch nicht mehr der jüngste, aber Nachrichtentechniker bin ich keiner, nein. Es wäre hilfreich, da stimme ich aber zu. :) Hex Oschi schrieb: >>#Jeder Client publiziert im Netz sein Angebot >> an Daten und andere Clients können diese abonnieren > > Wuerd ich nur auf Anfrage machen, nicht per Broadcast. Stimmt eigentlich. Macht in großen Netzwerken sicherlich mehr Sinn. Hex Oschi schrieb: >>#Fehlerhafte oder entfernte Clients werden >> allen Clients gemeldet. > > Per Broadcast ... wer macht denn das ? Alle, die > herausgefunden haben, dass ein Nachbar fehlt oder > spinnt ? Scheint mir ergibt zuviele Broadcasts. Ich dachte eher daran, dass die Verfügbarkeit bzw. Funktionsfähigkeit nur zwischen zwei Knoten, die untereinander Daten austauschen geprüft wird. Dementsprechend sollte dann nur einmal ein Broadcast ausgelöst werden. Nickname schrieb: > Hi, > > wäre es nicht einfacher Avahi(Zeroconf) entsprechend zu adaptieren ? Ja, daran habe anfangs auch schon gedacht. Habe es aber aus verschiedenen Gründen verworfen. Hast du Erfahrung mit Zeroconf? Könnte ich dich dazu ein paar Sachen fragen? Strubi schrieb: > Moin, > > guck dir doch mal die gerade als Opensource freigegebene netpp/dclib > (siehe auch Beitrag "OpenSource: Universelle library zum Ansteuern von > Geräten") an und bau > dazu - wenn nötig - einen neuen logical layer (in netpp-Terminologie: > "Hub"). Das meiste, was man normalerweise an Geräte-Interkommunikation > braucht, ist damit möglich. Lese ich mir in den nächsten Tagen mal durch. Danke für den Tipp! Strubi schrieb: > Alle darüber hinausgehende > Push/Pull-Funktionalität lagerst Du am besten auf die Low-Level-Seite > aus - wie beim Ethernet-Protokoll. Als Transport-Layer gibt es > eigentlich nichts schlaueres als das...damit ist die Frage also auch > berechtigt, warum Du das Rad neu erfinden willst - denn es ist > inzwischen billiger, auf einen netzwerkfähigen 32 ARM-Core umzusteigen, > als möglichst viel Intelligenz in einen 8051 Core reinzutricksen Wie meinst du das? Ich will kein Protokoll wie Ethernet etc. ersetzen. Ich will darauf aufsetzten. Ich möchte mit diesem Stack einerseits verschiedene physikalische Kommunikationsarten miteinander verbinden und andererseits dem Bastler/Entwickler eine einfach Möglichkeit bieten unter verschiedensten Geräten Daten auszutauschen und das so einfach wie möglich. Ein vielleicht blödes Beispiel dazu: Es gibt einen µC (A) mit XBee und Tempsensor im Garten und einen (B) im Haus. Ein anderer (C) möchte diese Daten mittels seines kleinen Webservers im Heimnetzwerk ausgeben. C nutzt dabei Ethernet(...) und XBee. A und B nur Xbee. Der Stack soll die Geräte untereinander verbinden und den Konfigurieraufwand für die Kommunikation so gering wie nur möglich halten. Ich hoffe ich habe damit einiges beantwortet und danke schon mal allen für die Vorschläge. Ich hoffe bei den nächsten Posts ist auch einer dabei, der der Sache etwas positiver entgegen sieht ;)
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.