große UDP Pakete mit lwIP auf STM32F7

Der Controller hat aber nur einen 100 MBit EMAC und die können afaik 
keine Jumbos, die gibts doch erst seit GigE.

:) die werden aber schon seit vielen Jahren in GigE Kameras eingesetzt 
und passende Switches und Netzwerkkarten sind vorhanden. Nur in uC habe 
ich noch kein Gigabit Ethernet gesehen.

Ich bin da kein TCP Gegner, das ist etwas gewachsenes wo die Daten nicht 
mehr in einen Frame passen und prinzipiell kann UDP bzw IP das ja. Das 
wäre dann einfacher UDP beizubehalten.

Johannes S. schrieb:

> Ich bin da kein TCP Gegner, das ist etwas gewachsenes wo die Daten nicht
> mehr in einen Frame passen und prinzipiell kann UDP bzw IP das ja. Das
> wäre dann einfacher UDP beizubehalten.

Wenn man will, dass Daten vollständig und in der richtigen Reihenfolge 
eintreffen, muss man TCP nehmen, denn genau dafür, dies sicher zu 
stellen, ist TCP gedacht.

UDP hingegen nicht, das kann weder das eine noch das andere 
sicherstellen, denn dafür war es nie gedacht.

Wenn man hofft, dass auf Grund der Infrastruktur schon nix wegkommen 
wird, dann muss man halt damit leben, dass man nur diese Hoffnung hat, 
aber keine Sicherheit. Dabei ist es übrigens völlig Wurscht, ob 
vollständige Pakete oder Fragmente transportiert werden. Wer UDP gewählt 
hat, hat billigend in Kauf genommen, das auch mal was wegkommen darf und 
kann den Fall auf höherer Ebene korrekt behandeln. Wenn nicht, war er 
von vornherein des Wahnsinns fette Beute...

Das vereinzelt Pakete verloren gehen können ist akzeptiert, das passiert 
maximal im kleinen Promille Bereich. Z.B. wenn der Empfänger wegen hoher 
Netzwerklast gerade keine Puffer frei hat. Das habe ich zuletzt mal bei 
NT4 vor 20 Jahren gesehen.
lwIP verwirft beim Senden das erste große Paket aus Sparsamkeit und 
zugunsten eines ARP, aber auch das soll sich abschalten lassen.
Und das mit der falschen Reihenfolge hatte ich noch nie. Das kommt wohl 
aus der Arpanet Zeit oder wenn Pakete über verschiedene Routen laufen, 
habe ich aber nicht.
Ich werde dann selber mal zählen was verworfen wird.

Johannes S. schrieb:
> Nun habe ich im EEVblog den kernigen Spruch 'Friends don't let friends
> fragment their UDP packets....' gefunden. Sicher, wenn ein Fragment
> nicht ankommt ist das Paket fratze

In einem LAN kannst Du das problemlos machen.

Sobald irgendwo eine Firewall dazwischenhängt, kann es haarig werden. Da 
sich Fragmente nur rudimentär filtern lassen, gibt es i.d.R. entweder 
Fragment Reassembly (dann funktioniert es, kostet aber Speicher), oder 
die Fragmente werden verworfen.

Besteht evtl. die Möglichkeit, dass Du die Daten selbst auf mehrere 
(vollwertige) UDP-Pakete verteilst?

Hmmm schrieb:
> Besteht evtl. die Möglichkeit, dass Du die Daten selbst auf mehrere
> (vollwertige) UDP-Pakete verteilst?

das wäre Plan B wenn es tatsächlich unzuverlässig ist.

Durch die Win10 Firewall gehen die lt. Wireshark durch, habe da noch 
keinen Empfänger laufen.

Johannes S. schrieb:

> Durch die Win10 Firewall gehen die lt. Wireshark durch, habe da noch
> keinen Empfänger laufen.

Nochmal etwas höflicher für die Mimose, die planlos zensieren läßt, wenn 
ihr irgendwelche Sachverhalte nicht gefallen:

Das ist witzlos. Wichtig ist einzig, was über alle Protokollebenen 
hinweg passiert, wenn ein Fragment mal NICHT ankommt.

c-hater schrieb:
> Wichtig ist einzig, was über alle Protokollebenen
> hinweg passiert, wenn ein Fragment mal NICHT ankommt.

Richtig. Und deshalb frage ich nach Erfahrung und teste schrittweise. 
Das eine FW eventuell einen Einfluss hat war ein guter Hinweis. Win10 
ist ein mögliches Zielsystem sowie eine SoftSPS. Da gibt es noch mehr zu 
testen, das ist mir sehr bewusst. Und lwIP hat eine Menge Schrauben an 
denen man drehen kann, ich hätte nicht gedacht das es so einfach läuft. 
Da habe ich es manchmal lieber das man erst mehr Fehler bekommt um die 
versteckten Sachen finden zu müssen.

Johannes S. schrieb:

> Richtig.

Wenn du das als richtig erkennst, dann ist die logische Lösung, nicht 
groß rumzufragen, sondern einfach das Szenario zu erstellen und zu 
testen.

Da du offensichtlich den Sender kontrollierst, kann das ja nicht so 
furchtbar schwer sein.

Zumal dir die Erfahrungen von anderen (mit notgedrungen anderen 
Empfängern) ja nach den Gesetzen der Logik garnichts bringen können. Ob 
die mit einem fehlenden Fragment richtig umgehen können, ändert doch 
rein garnichts daran, ob das auch dein Empfänger kann...

Denn der Knackpunkt liegt ja offensichtlich auf dem Anwendungs-Layer, da 
erwiesenermaßen der Transport-Layer hier nichts richten kann und die 
Anwendung eben IMMER mit dem klarkommen muss, was durch den Transport 
durch kommt, wie es auch immer aussehen mag.

c-hater schrieb:
> Wenn man will, dass Daten vollständig und in der richtigen Reihenfolge
> eintreffen, muss man TCP nehmen

TCP ist kein Ersatz für UDP Jumboframes.
Du kannst nicht sicherstellen, dass ein Datenpaket per TCP 
unfragmentiert übertragen wird. Wenn du TCP nutzt, musst du direkt ein 
Protokoll draufsetzen oder gleich http nehmen.

Heinz schrieb:

> TCP ist kein Ersatz für UDP Jumboframes.

Nö, das ist es wohl nicht. Wollte es allerdings auch niemals sein.

> Du kannst nicht sicherstellen, dass ein Datenpaket per TCP
> unfragmentiert übertragen wird.

Nö, das braucht man auch nicht, weil es schlicht niemanden interessiert, 
in wieviele Stücke die Daten auf dem Transportweg ggf. zerlegt werden. 
Wichtig ist nur, dass sie am Ende vollständig und in der richtigen 
Reihenfolge wieder aus dem Socket purzeln. Und genau dafür gibt es TCP.

Heinz schrieb:
> Du kannst nicht sicherstellen, dass ein Datenpaket per TCP
> unfragmentiert übertragen wird.

Das stimmt.

Heinz schrieb:
> Wenn du TCP nutzt, musst du direkt ein
> Protokoll draufsetzen oder gleich http nehmen.

Das stimmt nicht. Der TCP/IP-Stack kümmert sich darum, dass nur intakte 
Pakete in der richtigen Reihenfolge bei Dir ankommen.

Das einzige, was nicht gewährleistet ist, ist die Stückelung der Daten. 
Wenn der Absender z.B. 500 Bytes in den Socket pumpt, ist nicht 
garantiert, dass sie auch hinten als ein 500-Byte-Paket wieder 
rauskommen.

es geht um zwei Anwendungen:
einmal bohre ich einen Sender auf der schon seit ca. 30 Jahren UDP 
verwendet und bisher mit einem Frame auskam. Da wird es einfacher sein 
mehrere unfragmentierte Frames zu verwenden, umstellen auf TCP ist hier 
deutlich aufwändiger.
Die andere ist eine neue Kommunikation und der Kunde hat erstmal naiv 
große UDP vorgeschlagen bzw. auch schon realisiert. Deshalb frage ich 
erstmal nach was es für Pferdefüsse gibt, auch wenn es schon 
funktioniert. Weil ich weiß das 'funktioniert' nicht gleich 'robust' 
ist.
TCP wäre für die neue Anwendung für mich auch eine Option, aber dann 
muss der Gegner auch damit klarkommen. TCP mag keinen Ping Pong mit 
kleinen Häppchen, das muss man im Protokoll berücksichtigen. 
Kontinuierliche Pakete von mehreren kB in kurzen Intervallen lassen sich 
gut per TCP streamen.
Trotzdem muss ja wohl der Vergleich mit (fragmentiertem) UDP erlaubt 
sein, die Qualität der Übertragung liegt bei nahezu 100 %.

Hmmm schrieb:
> ist nicht
> garantiert, dass sie auch hinten als ein 500-Byte-Paket wieder
> rauskommen.

Ja das meinte ich ;)
Dann muss aber auf der Leseseite etwas sein, was die Daten wieder 
zusammensetzt.

Johannes S. schrieb:
> Deshalb frage ich
> erstmal nach was es für Pferdefüsse gibt, auch wenn es schon
> funktioniert. Weil ich weiß das 'funktioniert' nicht gleich 'robust'
> ist.

Es geht nicht um "robust" oder "nicht robust" - in dem oben 
beschriebenen Szenario, dass eine Firewall dazwischenhängt, die 
fragmentierte Pakete verwirft, funktioniert es ganz einfach gar nicht.

Johannes S. schrieb:
> TCP mag keinen Ping Pong mit
> kleinen Häppchen

Das ist TCP egal, es ist halt etwas mehr Overhead dabei.

c-hater schrieb:
> Wichtig ist einzig, was über alle Protokollebenen
> hinweg passiert,
Sinnvoller wäre es wenn die Protokollebenen und deren Anzahl bekannt 
wären.

lwIP fragmentiert IP-Pakete für kleine Ethernet-Pakete --> Transport 
über Netzwork-layer (und/oder Internet-layer; falls bspw. ISDN-Stecken 
dazwischen sind weitere Fragmentierung der IP-Paketfragmente)--> 
Empfänger baut aus Fragmenten IP-Pakete(SCTP/UDP/TCP/...) zusammen und 
falls ein IP-Paket vollständig zusammengebaut ist als UDP/TCP-Paket 
weiter

> wenn ein Fragment mal NICHT ankommt.
Dann würde eine TCP-Verbindung (Layer 3)nachfragen ob das IP-Paket mit 
dem Fragment wiederholt wird. Eine DNS-Abfrage (Layer 4; Anwendung) 
bemerkt vermutlich auch wenn es kein UDP-Paket zurückkommt ;-)

Hmmm schrieb:
> Das ist TCP egal, es ist halt etwas mehr Overhead dabei.

da gibt es zwei Spielverderber: den Nagle, den kann der Sender 
abschalten. und das delayed ACK, das kann der Sender nicht beeinflussen 
und da hat das OS des Empfängers die Hoheit darüber wann er ein oder 
mehrere kleine Pakete quittiert. Das muss man im Protokoll 
berücksichtigen.

Stefan schrieb:

> Eine DNS-Abfrage (Layer 4; Anwendung)
> bemerkt vermutlich auch wenn es kein UDP-Paket zurückkommt ;-)

Genau. Das Problem erscheint auf dem Anwendungslayer und muss deswegen 
dagegen getestet (und ggf. auch dort gelöst) werden.

Das ist der Punkt: der ganze Thread ist sinnlos, weil der TO nach 
"Erfahrungen" fragt. Es kann aber keine Erfahrung geben, weil niemand 
den Empfänger der Anwendung des TO kennt.

Viel schwerer wiegt: Es scheint dem TO nichtmal klar zu sein, dass das 
alles so ist, wie es ist...

Wenn du ein Protokoll-Datenpaket - sagen wir mal 128Bytes - per TCP 
sendest, ist nicht sicher, dass es auf der Empfänger-Seite aus der 
TCP-Schicht auch als 128Byte Paket wieder rauskommt. Es ist jede 
erdenkliche Kombination möglich
- Paket komplett empfangen
- Anfang empfangen, Rest kommt im nächsten Paket
- Rest kommt im nächsten Paket, Paket enthält aber auch 13Bytes des 
nächsten Paketes
- usw...

Du musst also etwas schreiben, dass dir einen Frame auf Empfängerseite 
zusammenbaut und erst dann zur Bearbeitung weiterreicht, wenn der Frame 
komplett ist.
Kann man selbst machen oder man nimmt etwas, das schon existiert, 
weltweit milliardenfach robust im Einsatz ist - bspw. http.

Heinz schrieb:
> Wenn du ein Protokoll-Datenpaket - sagen wir mal 128Bytes - per TCP
> sendest, ist nicht sicher, dass es auf der Empfänger-Seite aus der
> TCP-Schicht auch als 128Byte Paket wieder rauskommt.

bei TCP interessieren keine Pakete, sowas habe ich schon hundertfach 
programmiert. Man liest bis man eine Sollanzahl empfangen hat und 
überwacht dabei ob der Gegner die Verbindung zu gemacht hat. Dafür 
braucht man kein HTTP.

Heinz schrieb:

> Wenn du ein Protokoll-Datenpaket - sagen wir mal 128Bytes - per TCP
> sendest, ist nicht sicher, dass es auf der Empfänger-Seite aus der
> TCP-Schicht auch als 128Byte Paket wieder rauskommt.

Natürlich nicht. TCP implementiert einen Stream, Pakete gibt es oberhalb 
von TCP nicht, weder bei der Quelle noch bei der Senke. Der Sender füllt 
seinen Kram rein in den Stream, der Empfänger liest ihn wieder aus.

Um da "Struktur" reinzubringen, muß man halt Struktur schaffen. HTTP ist 
eine Möglichkeit, es gibt unzählige andere.

Johannes S. schrieb:
> und das delayed ACK, das kann der Sender nicht beeinflussen
> und da hat das OS des Empfängers die Hoheit darüber wann er ein oder
> mehrere kleine Pakete quittiert.

Ist aber auch kein echtes Problem, weil der Sender im Rahmen der Window 
Size trotzdem weitersenden kann.

Aber wenn tatsächlich Echtzeit gefordert ist, sollte man ohnehin zu UDP 
greifen - ansonsten gerät das Timing aus den Fugen, sobald zwischendurch 
mal ein Paket abhanden kommt.

Heinz schrieb:
> Kann man selbst machen oder man nimmt etwas, das schon existiert,
> weltweit milliardenfach robust im Einsatz ist - bspw. http.

Wenn man mit festen Paketgrössen arbeitet, ist das völlig trivial zu 
implementieren: Man liest in einen Buffer eben dieser Grösse ein, und 
wenn er voll ist, verarbeitet man ihn.

(prx) A. K. schrieb:
> Bisschen tricky,

ja, nur solche Tricks würde ich vermeiden, vor allem da ich beim 
Protokoll noch etwas Mitspracherecht habe.

Für manche Dinge ist UDP so genial einfach, dass ich sehr schade finde, 
dass es in Javascript im Browser nicht nutzbar ist.

(prx) A. K. schrieb:
> Bisschen tricky, aber wenn der Sender den gleichen Frame
> zweimal hintereinander auf die Reise schickt, kriegt er das ACK sofort.

Jein, damit das klappt, musst Du eigentlich die MSS ausreizen:

A TCP SHOULD implement a delayed ACK, but an ACK should not
be excessively delayed; in particular, the delay MUST be
less than 0.5 seconds, and in a stream of full-sized
segments there SHOULD be an ACK for at least every second
segment.

Kann natürlich je nach Implementation unterschiedlich sein.

Stefan ⛄ F. schrieb:
> Für manche Dinge ist UDP so genial einfach, dass ich sehr schade finde,

und ich finde es eben Schade das es pöse sein soll auch mal 2 oder 4 kB 
Päckchen rauszuhauen...

c-hater schrieb:
>>> Wichtig ist einzig, was über alle Protokollebenen
>>> hinweg passiert,
>> Sinnvoller wäre es wenn die Protokollebenen und deren Anzahl bekannt
>> wären.
> Genau. Das Problem erscheint auf dem Anwendungslayer und muss deswegen
> dagegen getestet (und ggf. auch dort gelöst) werden.
Bei Betroffenen die die unterschiedlichen Protokollebenen nicht kennen 
muss natürlich das Problem dort gelöst werden wo es ihnen erscheint.

C-Automat der auf einen sinnlosen Thread reagieren musste:
> Das ist der Punkt: der ganze Thread ist sinnlos, weil der TO nach
> "Erfahrungen" fragt. Es kann aber keine Erfahrung geben, weil niemand
> den Empfänger der Anwendung des TO kennt.
Die Auswirkungen einer IP-Fragmentierung können Menschen die denen das 
Problem nicht unbedingt auf dem Anwendungslayer erscheint einfach im 
Internet recherchieren:
https://de.wikipedia.org/wiki/IP-Fragmentierung#Auswirkungen

Johannes S. schrieb:

> und ich finde es eben Schade das es pöse sein soll auch mal 2 oder 4 kB
> Päckchen rauszuhauen...

Das kannst du doch, niemand verbietet dir das. Du musst halt nur die 
potentiellen Empfänger auch auf alle Eventualitäten vorbereiten, die bei 
solchen Sachen passieren können. Das ist der Punkt. Wurde bereits 
dreimal im Thread explizit drauf hingewiesen, auch darauf, wie man 
sinnvollerweise testet, ob die Empfänger tatsächlich hinreichend 
vorbereitet sind.

Deine fortgesetzte Ignoranz der Fakten ändert nunmal nichts an den 
Fakten. So lieb dir das auch sein möge...

Die Anwendungsschicht hat kein Problem mit fehlenden Daten, schrieb ich 
doch schon.
Wenn heute ein Frame verloren geht, ist ein UDP Paket weg. Wenn ein 
Fragment eines größeren UDP veroren geht, ist auch ein UDP Paket weg. 
Nur das in diesem ein paar Daten mehr drin waren. Das Paket ist nicht 
Teil eines Streams der jetzt auf einmal ein Loch hat. Wenn 1 % verloren 
geht ist die Übertragungsqualität 99 %. Wenn die noch schlechter wird, 
dann muss man Fehler suchen. Wenn die von Anfang an bei 0 % liegt, dann 
muss man die Übertragungsstrecke inkl. Firewall prüfen.

Johannes S. schrieb:
> Die Anwendungsschicht hat kein Problem mit fehlenden Daten, schrieb ich
> doch schon.
Soft-Fakter ("der ganze Thread ist sinnlos") können i.A. nicht mit 
solchen harten Fakten umgehen und beanspruchen viel Bandbreite für ihre 
Probleme.

Johannes S. schrieb:
> Wenn heute ein Frame verloren geht, ist ein UDP Paket weg. Wenn ein
> Fragment eines größeren UDP veroren geht, ist auch ein UDP Paket weg.
Das dürfen alle Eventualitäten sein (Soft-Fakter können ohne Erfahrung 
natürlich keine konkreten Eventualitäten nennen)

> Nur das in diesem ein paar Daten mehr drin waren. Das Paket ist nicht
> Teil eines Streams der jetzt auf einmal ein Loch hat. Wenn 1 % verloren
> geht ist die Übertragungsqualität 99 %. Wenn die noch schlechter wird,
> dann muss man Fehler suchen.
0,01+% Paketverlust ist erfahrungsgemäß auf Überlastung des Netzes 
zurückzuführen, wobei ein scheinbarer Paketverlust bspw. bei einer 
schlechten VOIP-Verbindung häufig auf einem Verwerfen 'trödelnder' 
Pakete beruht. Übertragungsqualität 100% bei 1s Latenz hört sich nicht 
nach 100% an ;-)

> Wenn die von Anfang an bei 0 % liegt, dann
> muss man die Übertragungsstrecke inkl. Firewall prüfen.
Die Übertragungsstrecke dürfte normgerecht nach IETF/IEEE-Standards 
ausgeführt sein d.h. wenn unfragmentierte IP-ICMP-Pakete durchkommen 
bleibt  real nur eine Firewall als plausible Eventualität.
Von einigen Firewalls ist bekannt, dass sie fragmentierte IP-Pakete 
verwerfen, weil sich solche gut für DoS nutzen lassen. User bei denen 
das Firewall Problem auf dem Anwendungslayer erscheint bleiben auf Hilfe 
aus dem Netz angewiesen.

Ich kann mir den Kommentar auf Eevblog nicht wirklich erklären, IP 
fragmentation/reassembly zu verteufeln und nur Frames <576 Bytes 
zuzulassen. Dass ein IP stack reassembly nicht beherrscht und also an 
einer Verringerung der MTU auf der Routingstrecke und der dann folgenden 
IP Fragmentierung scheitert sollte eigentlich auch 2015 schon Geschichte 
gewesen sein.

LG, Sebastian

Meine Theorie wäre ebenfalls das man die Fragmentierung früher gut 
gebrauchen konnte für verschiedene Medienübergänge und es ist 
schließlich Teil der unteren IP Schicht, aber die großzügige Auslegung 
mit 64k für unendlich viele Verbindungen heute eher Probleme macht. Wie 
hier schon genannt wurde, wird das in einem dedizierten LAN Segment 
funktionieren, und sowas habe ich. Es geht um Industrie und nicht 
beliebige Geräte die gerade billig sind und sich ständig ändern können. 
Und eine Punkt zu Punkt Verbindung um Störer auszuschließen ist Standard 
hier.
Trotzdem muss man überlegen ob das pflegen dieser Exklusivität die 
Zukunft ist, der Rest der Welt hat Angst vor der Fragmentierung.

Johannes S. schrieb:
> Die andere ist eine neue Kommunikation und der Kunde hat erstmal naiv
> große UDP vorgeschlagen bzw. auch schon realisiert.

Naja, das ist halt, ähm, Käse. Das ist typisches "Works for me".

> Deshalb frage ich
> erstmal nach was es für Pferdefüsse gibt, auch wenn es schon
> funktioniert. Weil ich weiß das 'funktioniert' nicht gleich 'robust'
> ist.

Nun, überall versucht man möglichst, fragmentierte IP-Pakete zu 
vermeiden. Man clampt MSS, macht Path-MTU-Discovery, und, und, und. Die 
Netzwerk-Geschichte ist gesäumt mit Implementierungsfehlern und 
grundsätzlichen Problemen bei fragmentierten IP-Paketen. Bei IPv6 gibt 
es den Mist erst einfach überhaupt nicht. Man hat aus den Fehlern der 
Vergangenheit gelernt.

Und nun basteln (mal wieder) irgendwelche Embedded-Leute etwas zusammen 
und finden fragmentiertes IP toll. Aber man hat ein ungutes Gefühl, 
fragt in Foren nach. Dort gibt's die Antwort: "Kann man machen, ist aber 
Kacke".

Den Rat will man nicht hören, man ist ja schlauer als der Rest der Welt.

Mein Tipp: Mach gigantische, fragmentierte UDP-Pakete und werde 
glücklich damit.

Und wenn es irgendwann halt bei irgendeinem Kunden nicht mehr 
funktioniert, weil irgendeine Netzwerkkomponente dazwischen funkt, oder 
weil ein Betriebssystem-Hersteller mit einem Update, Version 123, 
entscheidet, fragmentiertes IP komplett fallen zu lassen, dann schaut 
halt wie ihr glücklich werdet.

Es gibt nicht irgendwelche Hardware. Wie bei Apple : HW und SW wird als 
Einheit freigegeben. Es wird nix anderes projektiert und gekauft.
Genau wie bei GigE Vision und Jumbos, nix für Admins und ihre IT, aber 
technisch gesetzt. Alternativ kommt CoaxPress rein, dann ist es raus aus 
der IT, aber es wird teuer. Es gibt immer zwei Enden vom Kabel.
Ich kenne auch Admins die den ganzen ground floor als VM im Rack neben 
ihrem Büro haben wollen, aber da müssen sie noch ein bisschen warten bis 
der Rest der Hardware mitspielt.
Und die Fragmentierung hat man in die Basis von IP eingebaut. Das 
nachträglich auszubauen ist wie einem Haus das Fundament wegzunehmen.

Experte schrieb:
> Die Netzwerk-Geschichte ist gesäumt mit Implementierungsfehlern und
> grundsätzlichen Problemen

Das ist wohl wahr. Ich erinnere mich an die Kombination von Multicast 
und redundanter Netzwerkinfrastruktur ...

LG, Sebastian

Johannes S. schrieb:
> Meine Theorie wäre ebenfalls das man die Fragmentierung früher gut
> gebrauchen konnte für verschiedene Medienübergänge und es ist
> schließlich Teil der unteren IP Schicht,
gaanz korrekt wäre: 'die' IP Schicht (gibt nur eine; die 'obere' 
Datagram/Stream-Transport-Schicht ist meist gemeinsam in einem 
IP+TCP-Stack implementiert)
Gab vor einiger Zeit einen Krieg(ähnlich Video2000 vs. VHS)
https://en.wikipedia.org/wiki/Protocol_Wars
die Verlierer hängen häufig noch an ihrem Schichtenmodell und können von 
daher nicht wissen wie viele Protokollebenen im TCP/IP-Modell definiert 
sind.

Je nach Definition könnte man von den Fragmentierungen (nach 
Zweck/Ursache) schreiben: einmal um große Datagramme von Anwendungen 
durch Transport/IP-Stack der Hostrechner zu transportieren und 
netzseitiger Fragmentierung bei Medienübergängen mit kleinerer 
Paketgröße.

> aber die großzügige Auslegung
> mit 64k für unendlich viele Verbindungen heute eher Probleme macht.
Das ist ein Mythos aus den sozialen Netzen.
Probleme machen DAU die versuchen hinter einer Firewall fragmentierte 
Datagramme zu empfangen und die Firewall nicht entsprechend 
konfigurieren können/dürfen (Kindersicherung/Filesharing/ etc.) und in 
ihrer Sprache berichten. Dazu gab es Ende der 1990er einen MTU-Hype: 
durch den zusätzlichen NAT-Eintrag mussten viele TCP/IP-Pakete (ohne 
Nutzen) zu Lasten der Bandbreite/Rechenleistung fragmentiert werden.
Heutzutage geistern noch Expert-Bots durchs Netz die damals am 
DFÜ-Optimizer programmiert wurden. Ein reales 64kB-Datagramm ist für 
solche Bots "gigantisch" weil es nicht in deren Arbeitsspeicher passt 
(AOL-Ausbildung)

Johannes S. schrieb:
> Wie  hier schon genannt wurde, wird das in einem dedizierten LAN Segment
> funktionieren, und sowas habe ich.
Auch über standardkonforme Internet-Routen (ohne Firewall)

> Es geht um Industrie und nicht
> beliebige Geräte die gerade billig sind und sich ständig ändern können.
Da ist eine Anwendung auf bewährten UDP/IP-Stack zumindest vom Grundsatz 
besser geeignet als eine proprietäre Frickellösung "4kB Daten
so auf mehrere UDP Frames aufzuteilen, das der Empfänger die Teile
identifizieren kann."

> Trotzdem muss man überlegen ob das pflegen dieser Exklusivität die
> Zukunft ist, der Rest der Welt hat Angst vor der Fragmentierung.
Die Welt besteht nicht nur aus Soft-Fakern wie man sie aus den sozialen 
Netzen kennt. Dein Kunde ist laut seinem Vorschlag auch nicht 
ehrenamtlich bei Facebook engagiert. Im neuesten Internet(v6) dürfen 
Router keine IP-Pakete fragmentieren (im alten v4 wären bereits deine 
kleinen UDP-Pakete standardkonform bei einer Route mit kleinerer MTU 
fragmentiert worden) aber die Vermittlung von 
(fragmentierten)-Datagrammen wurde natürlich beibehalten.

Sebastian schrieb:
> Ich kann mir den Kommentar auf Eevblog nicht wirklich erklären, IP
> fragmentation/reassembly zu verteufeln
hamster_nz hätte wohl beinahe ein längeres E-mail per smtp over 
Postcard-IP bekommen (private Protokollgröße unkenntlich gemacht)
G-Translate:
> Überarbeiten Sie Ihr Protokoll, um XXX Bytes oder weniger pro Paket zu
> verwenden.
> Wenn Sie dies nicht tun, senden Sie einen langen Brief auf mehrere
> Postkarten, die von zufälligen (aber im Allgemeinen vertrauenswürdigen)
> Fremden zugestellt werden.
Eine lange Wikipediaseite auf mehreren IP-Postkarten die von zufälligen 
Fremden zugestellt wird, dürfte den Neuseeländer auch beunruhigen.

Johannes S. schrieb:
> Und die Fragmentierung hat man in die Basis von IP eingebaut. Das
> nachträglich auszubauen ist wie einem Haus das Fundament wegzunehmen.
Im realen Internet wird die Datagram-Basis ja auch weiter ausgebaut 
(IPv4:64KB --> IPv6:4GB)
https://en.wikipedia.org/wiki/Jumbogram
Soft-Faktern aus sozialen Netzen fehlt halt ein Fundament, um Software 
aus  C/IP-Stacks nutzen zu können

NB: richtige Experten zeichnen sich dadurch aus, dass sie zur Sicherheit 
noch mal nachfragen können, während Soft-Fakter mit ihrem Problem "der 
ganze Thread ist sinnlos" ausdrücken, dass sie für irgendwie alle 
Protokollebenen Hilfe benötigen

(prx) A. K. schrieb:
> Diese "Frickellösung" wäre einfach nur ein simples Protokoll oberhalb
> von UDP.

So ein Protokoll tut entweder nur genau das was IP 
fragmentation/reassembly tut, oder es ist nicht mehr simpel.

Z.B. ein Reliable Multicast Protocol auf Basis von UDP multicast. NACKs, 
Sendercache, Mengen an Timeouts, und Corner Cases ohne Ende ...

LG, Sebastian

Johannes S. schrieb:
> und ich finde es eben Schade das es pöse sein soll auch mal 2 oder 4 kB
> Päckchen rauszuhauen...

Ich finde das nicht böse. Im lokalen Netz kein Problem. Durchs Internet 
geht es halt nicht (oder nur mit Glück).

Danke an die Stefans und A.K., da sind  ja doch noch sehr nützliche 
Beiträge zusammen gekommen.
Ich werde noch weiter testen wie das bei hoher Last läuft. Mit IPv6 
machen wir noch nix, aber ich nutze den lwIP in Mbed-os und da ist das 
schon konsequent drin und kann einfach aktiviert werden.

(prx) A. K. schrieb:
> Man kann eine Lösungen durchaus so definieren, dass sie nur mit Jumbo
> Frames funktioniert.

Ich hatte bisher angenommen das es Jumbo Frames nur in Gigabit Netzen 
gibt. Habe nochmal in das Manual vom F746 geschaut, der EMAC erlaubt 
Frames bis zu 16 kB. Ob das durchgängig in lwIP und im OS unterstützt 
wird weiß ich nicht, wäre interessant zu testen, ist aber vermutlich 
auch dünnes Eis auf das man sich begibt. Praktisch werden die Jumbos in 
verwendeten Komponenten bis 8 kB eingesetzt.

@A. K.: ich nehme an du bist Admin für ein größeres Netzwerk? Liest sich 
so auch aus anderen Threads.
Ich bin da im Maschinenbau/Messtechnik unterwegs, da ist mein Netz in 
diesen Fällen eine eigene Punkt zu Punkt Verbindung. Die wird komplett 
mit allen Kabeln und Komponenten vorgegeben. Es gibt dicke 
Stromlaufpläne in denen alles drin ist und da werden Kabellisten 
rausgezogen. Diese bekommt ein Sub und der hat die genauso von A nach B 
zu verlegen wie in der Liste. Da gibt es dann Null Spielraum und bei 
GigE Switches wird immer noch der Typ eingesetzt der 2005 mal eingeführt 
wurde. Es kam noch eine Alternative dazu weil es mal Lieferprobleme gab, 
aber das war es dann.
Also was die Komponenten angeht sind Jumbos kein Problem und in Kameras 
seit <2005 Standard.

Ich habe beruflich auch mit Gigevision zu tun. Dort läuft alles über 
UDP. Und da kann man ein Lied von den Problemen singen. Sobald ein Paket 
nicht ankommt, und das ist nicht selten, muss der Empfänger es nochmals 
anfordern. Dazu müssen Resendbuffer gehalten werden, es gibt Raten von 
Paketverlusten, wo das Protokoll abbricht. Die Implementierung enthielt 
auch oft genug Fehler, dass Buffer nicht wieder freigegeben wurden etc.
Bei einer Lösung über TCP hätte man sich die Probleme ersparen können. 
Da macht TCP/IP das selber. Dauert vielleicht etwas länger, ist im 
Normalfall aber sicherer und angenehmer.

Für Ping oder so etwas wie Arp ist UDP super. Aber sobald man eine 
Datenstrom verschicken möchte, ist TCP/IP besser. Möchte ich nicht mit 
UDP machen. Das gibt nur Kopfschmerzen. (Erfahrungen der letzten 10 
Jahre)

Stefan ⛄ F. schrieb:
> Durchs Internet geht es halt nicht (oder nur mit Glück).

Das ist dann doch übertrieben. Normalerweise geht es, mit Pech 
funktioniert es nicht.

Es gibt nämlich ein paar alltägliche Szenarien, wo man oft 
UDP-Fragmentierung antrifft: DNSSEC, IKE (den standardisierten 
Workaround in IKEv2 beherrscht erst Win10) oder auch SIP, weil manche 
Anbieter der Meinung sind, einen unsinnigen Header-Rattenschwanz 
mitschicken und dabei die RFC verletzen zu müssen.

Wenn es scheitert, dann auch nicht "im Internet", sondern an den 
Firewalls der Kommunikationspartner. Im Backbone sind Fragmente egal, da 
interessieren nur die IP-Header.

Johannes S. schrieb:

> Hat hier jemand Erfahrung mit großen UDP in lwIP, ist das wirklich so
> unzuverlässig?

Wer UDP nutzt sollte wissen was man tut.

PittyJ schrieb:
> Ich habe beruflich auch mit Gigevision zu tun. Dort läuft alles über

ditto. Wir nutzen Jumbo-Frames + IP (Multicast + DF bit) + UDP + eigenes 
Protokoll um fehlende Fragmente zu erkennen. Dazu ein Netzwerkdesign mit 
garantierten Bandbreiten.

> UDP. Und da kann man ein Lied von den Problemen singen. Sobald ein Paket
> nicht ankommt, und das ist nicht selten, muss der Empfänger es nochmals

Ich finde es etwas seltsam, dass du "nicht selten" schreibst. Wir nutzen 
UDP zur Bildübertragung in Echtzeitsystemen (500 Hz - 1 kHz frame rate + 
low latency + low jitter) machen das alles auf 10 bis 100 GbE. Eine 
Bitfehlerrate von max. 1e-13 ist für DirectAttach Kupferkabel 
spezifiziert (real sind die i.d.R. besser; optisch ist noch besser). Da 
kann man Terabytes an Daten senden ohne, dass irgendwas verloren geht. 
Wenn du Paketverluste hast, hast du Probleme mit deinem Netzwerk.

> anfordern. Dazu müssen Resendbuffer gehalten werden, es gibt Raten von
> Paketverlusten, wo das Protokoll abbricht. Die Implementierung enthielt
> auch oft genug Fehler, dass Buffer nicht wieder freigegeben wurden etc.

Bei uns: kommt ein Bild nicht an, wird das erkannt und das Bild als 
verloren angesehen und die Regelung mit einer Heuristik überbrückt. Gibt 
es zu viele Bildverluste (>1 pkt/viele Terabytes Daten), wird ein Alarm 
ausgelöst.

> Bei einer Lösung über TCP hätte man sich die Probleme ersparen können.
> Da macht TCP/IP das selber. Dauert vielleicht etwas länger, ist im
> Normalfall aber sicherer und angenehmer.

TCP Implementationen sind m.M.n. der Horror. Viel zu viele 
Fehlerquellen.

> Für Ping oder so etwas wie Arp ist UDP super. Aber sobald man eine
> Datenstrom verschicken möchte, ist TCP/IP besser. Möchte ich nicht mit
> UDP machen. Das gibt nur Kopfschmerzen. (Erfahrungen der letzten 10
> Jahre)

Meine Erfahrung ist das komplette Gegenteil. Im Zweifelsfall lieber das 
ganze Bild nochmal senden, als einzelne Teile anzufragen.

(prx) A. K. schrieb:
> PittyJ schrieb:
>> Aber sobald man eine
>> Datenstrom verschicken möchte, ist TCP/IP besser.
>
> Nicht immer. Video/Tonübertragung bei Telefonie oder Konferenzen hat
> zwar Stream-Charakter, TCP ist dabei aber eine ausgesprochen schlechte
> Idee. Denn da ist ein jitterarmes Zeitverhalten wichtiger als
> gelegentliche Datenverluste.
>
> Ebenso sollte man vermeiden, mehrere Layer mit Retries übereinander zu
> stapeln. Also beispielsweise einen TCP/IP-Tunnel in SSL/TCP zu
> implementieren, wie manche das bei OpenVPN machen. Bei schönem Wetter
> funktioniert das gut, bei schlechtem bricht es u.U. aufgrund
> Vervielfachung der Retries und explodierender Latenz zusammen.

Exakt. Daher funktioniert Wireguard auch so gut.

PittyJ schrieb:
> Ich habe beruflich auch mit Gigevision zu tun. Dort läuft alles über
> UDP. Und da kann man ein Lied von den Problemen singen

habe ich ja auch und ab 2005 wurden mit GigE das CameraLink bei uns 
ersetzt. Es geht immer um Verbindungslängen >100 m mit Glasfaser, und 
die Konverter für CL waren die Schwachstelle. Mit GigE konnte man eben 
Standardkomponenten verwenden, und da wurde darauf geachtet das die auch 
Jumboframes konnten. Glasfaser war dann einfach über die SFP Module im 
Switch möglich. Und eben Punkt zu Punkt Verbindungen um den Traffic aus 
dem restlichen Netz zu halten, eine GigE Kamera kann ja mittlerweile 
locker >100 MByte/s kontinuierlichen Datenstrom erzeugen. Bei mehreren 
Kameras an einem Strang muss man mit Einstellungen wie InterpacketDelay 
drehen und triggern. Ich kenne da keine größeren Probleme, manchmal 
waren es schlecht gecrimpte Stecker oder defekte Glasfasern.

Aber das ist ja nicht ganz das Thema hier. Ich habe mir inzwischen auch 
den ST EMAC Treiber in Mbed angesehen, da ist die MTU ein fixes define 
mit 1500. Und da müssen mehrere Module mitspielen, das ist mir zu heiß.

Johann-Wolfgang schrieb:
> TCP Implementationen sind m.M.n. der Horror. Viel zu viele
> Fehlerquellen.

ja, und das läuft in den Kameras ja im FPGA ab. Das macht da sicher noch 
weniger Spaß als UDP.

(prx) A. K. schrieb:
> Stefan schrieb:
>> Da ist eine Anwendung auf bewährten UDP/IP-Stack zumindest vom Grundsatz
>> besser geeignet als eine proprietäre Frickellösung "4kB Daten
>> so auf mehrere UDP Frames aufzuteilen, das der Empfänger die Teile
>> identifizieren kann."
> Diese "Frickellösung" wäre einfach nur ein simples Protokoll oberhalb
> von UDP.
Die Funktion 4kB UDP Datagramm (ugs.Frame) so auf mehrere IP 'Frames' 
(eng. fragments) aufzuteilen, dass der Empfänger die Teile (anhand der 
16-Bit ID und des Tupels) identifizieren kann ist im "betont einfachen" 
lwIP Stack (GNU HURD & CO) unterhalb von UDP eingebaut.
Experten die 16-bit Datagramm Funktionen oberhalb von 8-bit Datagramm 
C-Funktionen reimplantieren, weil in den sozialen Netzen suggeriert wird 
der "betont einfache" AVR-GCC hätte Fehler bei der Fragmentierung von 
längeren Datagrammen, sind mMn. Frickler.
Gibt halt im Netz immer wieder C/IP-hater die lieber frickeln als 
bewährte Bibliotheken zu nutzen und im Falle eines Fehlers in den 
Bibliotheken die Autoren über den Fehler zu informieren, anstatt FUD zu 
verbreiten

(prx) A. K. schrieb:
> Insofern allgemein üblich, praktisch jede Anwendung setzt auch
> TCP oder UDP noch einen Layer drauf. Egal obs dafür einen RFC gibt, oder
> selbst gebacken.
Johannes alte Anwendung hat 30 Jahre lang einen Layer 'drauf' gesetzt 
bzw. implementiert. Das genial simple UDP Frame Protokoll wäre Layer 3,5

Die RFC-Blogger hatten vor Jahren praktisch das gleiche Problem wie 
Johannes bei ihrer verteilten DNS-Anwendung:
- 512 Byte Limit, weil unbekannte(!) IP-Host nur 576 Byte IP-Buffer 
sicher bereitstellen
- TCP: Ressourcen teuer
- 30 Jahre UDP Erfahrung
Die neue IETF-Entwicklung EDNS lässt bzgl. der Thread-Frage grob mit:
- Know your customer/client/friend: Auskunftwillige geben bei Anfrage an 
wie groß ihr UDP/IP-Buffer ist
- recommended UDP size:4kb ("A good compromise may be the use of an EDNS 
maximum payload size of 4096 octets as a starting point").
- einfache Proxies etc.: fix 4kb+("proxies SHOULD be capable of 
forwarding UDP packets up to a payload size of at least 4096 octets").
- kein simple "UDP Frame/Fragment"-Layer zwischen Layer 4 und 3
- fallbacks für friends-exchange-Segmente die schon länger simple 
Protokolle u.ä. als 'workaround' verwenden (Tipps&Tricks aus dem 
Internet sind praktisch rekursiv in Teilen des IEFT-Networks 
implementiert)
beschreiben.[Blog-Einträge:#2671(obsolet);#5625;#6891]

Johannes modifizierter STM32F7 könnte bei der IEFT als EDNS-Proxy 
arbeiten.  Wenn aus dem simplen Protokoll nichts wird (dürfte schon 
klappen) bliebe als Fallback EDNS Tunnel, um 4kb(-Header) ohne 
Extra-Layer zu transportieren. In Friend-Nets fehlt letztere Möglichkeit 
natürlich, wenn die Administratoren keine 4kb-Jumbo-IP Host als Freund 
in ihren Netzen dulden.

Das Blog der IETF hat sicherlich nicht so viele kernige Sprüche "Friend 
dont'l let Friends..." wie die Blogs der Konkurrenz drauf, aber häufig 
hat sich gezeigt, dass kernige Sprüche inhaltlich wertlos sind. Für eher 
technisch interessierte Menschen ist das IEFT-Blog mMn. zumindest eine 
sinnvolle Ergänzung zu den werbefinanzierten Friends-Blogs, um nicht nur 
eine Seite zu kennen.
Ob am Ende eine Anwendung ähnlich wie IETF-Anwendungen oder gemäß der 
Friends-Expert-Group besser funktioniert kann natürlich nur ein 
Feldversuch entscheiden.

danke, ich bin mittlerweile auch davon überzeugt das ich mich auf die 
Fragmentierung in lwIP verlassen kann. Ich bevorzuge Standards vor 
eigenen Erfindungen, denn da haben sich einige Leute schon viele 
Gedanken gemacht und das Wissen muss man sich erstmal aneignen. Für 
Echtzeit ohne nachträgliche Anforderung verlorener Pakete ist das zwar 
überschaubar,
Wichtig ist natürlich das die Rahmenbedingungen passen:
- es kann Probleme beim Routen geben. Das habe ich nicht, es geht um 
Daten von A nach B in einer exklusiven Verbindung.
- die Firewall könnte Fragmentierte Pakete ablehnen. Diese ist aber Teil 
'meiner' Anlage und kann konfiguriert werden.
- höherer Speicherbedarf für lwIP. Hier ist mir noch nicht ganz klar 
wieviel genau für die großen Pakete eingestellt werden muss. Aufpassen 
muss man bei mehreren möglichen Sockets das auch unter Maximallast 
genügen Puffer bereitstehen.

Als Nebenkriegsschauplatz habe ich mir erstmal IPv6 angesehen, das wird 
hier bisher nicht eingesetzt und entsprechend habe ich das links 
liegengelassen.
Dafür mache ich einen neuen Thread auf weil das ja ein anderes Thema 
ist.
Den IETF Blog werde ich mir auch mal ansehen, aber so tief wollte ich 
gar nicht da rein.