Ok, das mit dem Sender ist gewollt, ich will, dass ich einfach (also ohne Umkonfigurieren der anderen Geräten) neue Fkt. hinzufügen kann. So habe ich z.B. (noch im Planung) Außentemperatur, Luftdruck etc. Leicht vorhanden. Multicast will ich nehmen da Unicast absolut keinen Sinn macht und zum Broadcast den Vorteil hätte, dass der NIC die Möglichkeit eine Vorfilterung auf Layer2 Durchführen kann. Dass Multicast und Broadcast von den Meisten Switches gleich behandelt werden (Broadcast ist ja nur eine Sonderform des Multicast) ist mir bewusst. In der jetztigen Variante meines Codes hat der Client also Nutzer der Daten dazu zu sorgen, dass er nur mit Hinreichend Jungen Daten arbeitet. Um es verständlicher zu machen: Sensordaten und Interne Statuse (also Statuse allgemein) eines Gerätes werden verschickt, das war's senderseitig. Jeder Client der einen Status verwenden will, muss sich das aus Node-ID, etc. Sich den Richtigen zusammen sammeln und kann diese dann zum Regeln und Steuern verwenden. Wenn natürlich ein Gerät aussteigt hat die Applikation dafür zu sorgen in einen Fail-Safe status zu gehen. Da eine Regelung mit alten Sensordaten so das unnützeste ist was man haben kann. Um den Datenverlust habe ich mir zu einem noch kein Gedanken gemacht und bin eigentlich der Meinung, dass die Statuse in Regelmäßigen Abständen gesendet werden müssen. Ich werds bald testen. Danke. MfG Marian Kerler
Am 20. Februar 2013 19:18 schrieb Andreas Tauscher <t...@geuka.net>: > Am 20.02.2013 01:44, schrieb Marian Kerler: > > Also ich sehe 1. ihr braucht erstmal mehr code zum nachvollziehen: > > mit der: > > uip_ipaddr_t ip; > > uip_ipaddr_copy(&ip,all_ones_addr); > > uip_udp_connt *test = uip_udp_new(&ip,callback_fcn); > > > > das steht ja sowie so in der init-Funktion. > > 2. Habe ich jetzt gelernt, dass man hier nix ändern darf, da "ip" ja die > > Gegenstelle ist. (Man doch die fcn Beschreibung richtig lesen) > > Zu meiner Frage: Wo teil ich dem ENC mit, dass er die Multicast-MAC > > durchlässt, so dass der IP-STack arbeiten kann? > > Ist im Datenblatt ab Seite 48 beschrieben: > http://ww1.microchip.com/downloads/en/devicedoc/39662c.pdf > > 224.0.0.0/24 ist für lokale Netze ohne Routing. Das sollte für den > Anfang mal reichen. Wenn der Multicast geroutet werden soll kommt ja > dann noch das Problem dazu, das die Router und Switches auch mitspielen > müssen. > > Große Frage aber: Warum Multicast? Bei Multicast gibt es absolut keine > Rückmeldung. Wenn die Daten verloren gehen, dann sind sie weg. Der > Sender hat keinerlei Information darüber ob Daten angekommen sind oder > nicht. Der Sender weiß nicht mal ob überhaupt jemand zuhört. > Der Empfänger hat aber auch ein Problem: Wenn keine Daten ankommen. Wird > gerade nichts gesendet, oder ist es ein anderes Problem. Der Empfänger > kennt ja nicht den Sender, kann also nicht mal nachfragen ob es gerade > eine Störung gibt, oder was los ist. > > >
_______________________________________________ Ethersex-devel mailing list Ethersex-devel@list.zerties.org https://list.zerties.org/cgi-bin/mailman/listinfo/ethersex-devel
