AW: Alfred macke

[mayosemmel]

Hallo zusammen,

Kann man das nicht auf tcp umstellen? Dann ist zwar das Grundproblem, der Fragmentierung nicht behoben, aber die Übertragung sollte wesentlich besser laufen.

Grüße Jan

----- Ursprüngliche Nachricht -----
Von: "Dominik Heidler" <dominik at heidler.eu>
Gesendet: ‎25.‎11.‎2015 16:02
An: "peter.muehlenbrock at nefkom.info" <peter.muehlenbrock at nefkom.info>; "franken-dev at freifunk.net" <franken-dev at freifunk.net>
Betreff: Re: Alfred macke

Hi,

ich habe es jetzt nochmal genau mitgeschnitten:
Die gesamten Daten passen in ca 6 PUSH UDP Pakete (+ ein Transmission
Complete Paket).
Die PUSH Pakete sind größer als die MTU. Deshalb werden sie auf IPv6
Level fragmentiert - jedes Fragment hat 1448 Byte.
Jedes UDP Paket wird also in ca 45 IP Fragmente aufgeteilt.
Insgesamt werden also ca 360 Fragmente in je einem Frame übertragen.
Fragmentierungen auf VPN Level und darunter habe ich jetzt nicht betrachtet.
Wenn auch nur ein einziges Fragment nicht korrekt übertragen wird, ist
die ganze Übertragung fehlgeschlagen.

Grüße,
Dominik

Am 25.11.2015 um 10:48 schrieb Dominik Heidler:
> Ich habe den Server gepingt und konnte bei 60 pings keinen Paket loss feststellen.
> 
> Am 25. November 2015 09:48:32 MEZ, schrieb peter.muehlenbrock at nefkom.info:
>>
>>
>> Hallo Dominik, 
>>
>> nachdem ich die Firewall Rule geändert habe, funktioniert das Announcen
>> des Masters jetzt auch auf meinem Router (s.a. auch den Patch, den ich
>> verschickt habe) 
>>
>> Ich bekomme jetzt manchmal alle Infos der Knoten, meistens aber nur
>> eine
>> Teilmenge. Letztere sind vermutlich die Router die ich lokal habe, dazu
>> kommen aber immer noch ein paar wenige andere. ich vermute es gibt noch
>> weitere master im netz, nicht nur der am gateway. 
>>
>> Ich denke das Problem liegt daran - wie Du ja auch geschrieben hast-
>> dass der Transfer der gesamten Datenmenge in einem Rutsch oft nicht
>> klappt und dann die Pakete verworfen werden. 
>>
>> Eine Abhilfe wäre vielleicht, ein paar mehr Master zu betreiben, so das
>> die Einzeltransfers nicht so lang sind. Aber ein bischen seltsam ist es
>> schon, dass anscheinend doch so viele Paketverluste auftreten, dass ein
>> Transfer von ein paar hundert KB oft schon nicht klappt. Und das ja
>> nicht via Funkstrecken, sondern Gateway--Router mit VPN 
>>
>> Peter 
>>
>> Am 2015-11-25 09:29, schrieb Dominik Heidler: 
>>
>>> Hi,
>>>
>>> ich habe das Problem jetzt mal reproduziert und dabei gleich mal
>> einen
>>> FASTD Dissector für Wireshark geschrieben [1 [1]] (einen ALFRED
>> Dissector
>>> gab es zub Glück schon [2 [2]]).
>>>
>>> Wenn man mit Alfred die id 64 abfragt, wird der ALFRED_REQUEST per
>> UDP
>>> an den Master geschickt, der daraufhin antwortet. Der Master Packt so
>>> viele "Facts" (=Die Infos zur ID x über genau einen Router) wie
>> möglich
>>> in je ein PUSH Paket. Die Pakete sind durchnummeriert. Am Ende sendet
>>> der Master ein TRANSACTION_FINISHED Paket, dass die Anzahl der
>>> gesendeten PUSH Pakete enthält. Wenn das Transaction
>>> TRANSACTION_FINISHED Paket verloren geht, kommt es zu dem längeren
>>> Timeout vor dem Fehler. Sobald z.B. PUSH_id=1 verloren geht, aber
>>> PUSH_id=2 ankommt, wird auch abgebrochen, da ja auch hier ein
>>> Übertragungsfehler sichtbar ist. Genau diese beiden Fehler habe ich
>>> immer wieder reproduzieren können.
>>>
>>> Wenn man die id 65 abfragt, liegen keine Daten vor, sodass keine PUSH
>>> Pakete sondern nur das TRANSACTION_FINISHED Paket (mit Eintrag: 0
>> PUSH
>>> Pakete übertragen) korrekt empfangen werden muss.
>>>
>>> [1] https://github.com/asdil12/fastd-dissector [1]
>>> [2] https://github.com/basros/alfred-dissector [2]
>>>
>>> Grüße,
>>> Dominik
>>>
>>> Am 22.11.2015 um 19:25 schrieb Peter Muehlenbrock:
>>> Hallo Dominik die Funktionsweise vom Alfred mit Master/Slave/Client
>> habe ich schon verstanden. Den Mastermode hatte ich nur testweise
>> aktiviert, um zu prüfen ob die Kommunikation wenigstens zwischen 2
>> Mastern auf FF Routern funktioniert. Was sie ganz offensichtlich nicht
>> tut. Dito nicht zwischen Master/Slave. Das mit Curl/wget/crawl ist mir
>> auch bekannt, Genauso mache ich das aktuell so. Mir erschien es nur
>> ganz reizvoll, die Monitoringdaten von einem Router abzuholen und nicht
>> jeden einzeln zu crawlen. Zumal sie ja jetzt eh schon im Netz per
>> Alfred verschickt werden. Und das ja wohl auch der Sinn von Alfred ist,
>> das diese Daten bei Bedarf im gesamten Netz verfügbar sind. Den Tipp
>> mit dem Firewall ist hilfreich. Das könnte der Grund sein und das werde
>> ich mal ausprobieren bei Gelegenheit. Vielleicht können die Experten
>> die Alfredpakete ja defaultmässig in der nächsten Version auch durch
>> den Firewall durchlassen :-). Das hat keinen Nachteil, aber den Vorteil
>> dass man bei
>> Bedarf Alfred dann auch auf einem FF Router sinnvoll nutzen kann. Peter
>> Am 22.11.2015 um 16:54 schrieb Dominik Heidler: Hi, ich nehme mal an,
>> du hast versucht, alfred als master auf dem Freifunk Router laufen zu
>> lassen. Lass Alfred bitte nicht im Master mode laufen, da sonst die
>> Alfred-daten aller router deiner Hood auch über deinen Router laufen.
>> Wenn du alfred nicht als master laufen lässt und "alfred -r 64"
>> eingibst, fragt der alfred dienst auf deinem Router beim alfred-master
>> nach, welche Daten es für id 64 gibt. Der alfred-master schickt die
>> daten an den alfred dienst auf deinem router und der wiederum gibt sie
>> an den alfred-client zurück, der sie dann ausgibt. Wenn der
>> alfred-dienst auf deinem Router im master mode läuft, sendet er alle 10
>> sekunden ein MASTER_ANOUNCEMENT Paket an alle Router deiner Hood. Die
>> Router entscheiden dann, zu welchem alfred-master die Verbindung am
>> bessten ist und schicken ihre statusdaten dorthin. Unser alfred-master
>> empfängt die
>> MASTER_ANOUNCEMENT Pakete von deinem Router ebenfalls. Jedes mal, wenn
>> ein Router Statusdaten an unseren alfred-master sendet, leitet dieser
>> die Daten an alle ihm bekannten alfred-master weiter. Das selbe macht
>> auch dein Router in die andere Richtung. Wenn du hier auf deinem Router
>> "alfred -r 64" eingibst, wird nur beim lokalen alfred-master angefragt,
>> der diese Anfrage ohne weitere Netzwerkkommunikation beantworten kann,
>> denn jeder alfred-master hollte immer alle Daten des Netzwerks (also in
>> unserem Fall der Hood) haben. Den Request failure bekommst du vmtl wenn
>> der Request zwischen deinem alfred-dienst und dem alfred-master bei der
>> Übertragung verloren geht. Es ist immerhin eine größere Datenmenge, die
>> ohne Fehlerkorrektur per UDP übertragen wird (wenn die Daten verloren
>> gehen, ist es nicht so schlimm für uns - sie werden ja nach 5 Minuten
>> erneut gesendet). Am 22.11.2015 um 07:30 schrieb Peter Muehlenbrock:
>> zuverlässig die xml Daten des eigenen Knotens an, aber nicht die der
>> anderen. Dann gibt es auch keinen read request failure. Evtl verhindert
>> die Firewall deines Routers das versenden deiner Master Anouncement
>> Pakete. Die Firewall filtert ja broadcasts um Traffic zu sparen. Das
>> Versenden der xml Daten an die FF Map monitoring.franken...
>> funktioniert aber wie erwartet, auch im Mastermode. Was also ist anders
>> bei dem Alfred Master auf der FFMap Serverseite, dass es dort hinhaut ?
>> Unser alfred-master läuft nicht auf einem Router sondern auf einem
>> Server, der per VPN direkt im Freifunk Netz hängt, und hat auch eine
>> andere Firewall Konfiguration, sodass die Master Anouncement Pakete
>> (hoffentlich) alle Router erreichen. Wenn ich jetzt "alfred -r 64" auf
>> unserem Server aufrufe, fragt der nur über eine lokale Verbindung (ein
>> UNIX Socket bei dem Übertragungsfehler ausgeschlossen sind) beim
>> alfred-master-dienst an und bekommt die geforderten Daten direkt aus
>> dem cache vom alfred-master. Aber wie gesagt: Wenn du die statusdaten
>> deiner Router holen willst,
>> empfehle ich dir, sie per http mit curl zu holen. Grüße, Dominik
>>
>>
>>
>> Links:
>> ------
>> [1] https://github.com/asdil12/fastd-dissector
>> [2] https://github.com/basros/alfred-dissector
> 

-- 
franken-dev mailing list
franken-dev at freifunk.net
http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20151125/b0b0a7ab/attachment-0002.html>