ich teste gerade welche UDP Paketgrößen ich mit einem STM32F746 senden kann. Durch vergrößern von MEM_SIZE (heap für ausgehende Pakete) kann ich jetzt 4k Brocken versenden, lwIP fragmentiert die korrekt. 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, aber es geht um ein kleines LAN Segment, evtl. Punkt zu Punkt und nicht das WWW und damit recht sichere Übertragung. Hat hier jemand Erfahrung mit großen UDP in lwIP, ist das wirklich so unzuverlässig?
Kannst Du nicht auf Jumbo Frames umstellen? Dann gehen auch 8k Pakete unfragmentiert, und das Problem wäre erledigt. fchk
Der Controller hat aber nur einen 100 MBit EMAC und die können afaik keine Jumbos, die gibts doch erst seit GigE.
Frank K. schrieb: > Kannst Du nicht auf Jumbo Frames umstellen? Friends don't let friends use jumbo frames...
:) 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.
Johannes S. schrieb: > Hat hier jemand Erfahrung mit großen UDP in lwIP, ist das wirklich so > unzuverlässig? Nicht mit LwIP. Aber ab Gigabit Ethernet ist NFS über UDP dafür bekannt Daten kaputt zu machen weil UDP Fragemente falsch zusammengesetzt werden. Schau lieber mal ganz genau hin ob nicht TCP besser geeignet wäre. So teuer ist der Handshake nicht.
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?
Angehängte Dateien:
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.
Beitrag #6585888 wurde von einem Moderator gelöscht.
Beitrag #6585894 wurde von einem Moderator gelöscht.
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.
Johannes S. schrieb: > und das delayed ACK, das kann der Sender nicht beeinflussen Doch, er kann. Bisschen tricky, aber wenn der Sender den gleichen Frame zweimal hintereinander auf die Reise schickt, kriegt er das ACK sofort. Nützlich, wenn du einen Sender hast, der gerade genug Puffer für einen einzigen Frame hat.
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...
Was mit gesetzten DF (don't fragment) auf die Reise geht, kommt entweder ganz an, oder überhaupt nicht (=>ICMP).
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...
Johannes S. schrieb: > und ich finde es eben Schade das es pöse sein soll auch mal 2 oder 4 kB > Päckchen rauszuhauen... Hat viel Potential für Ärger, denn es müssen alle brav mitspielen. Üblicherweise lohnt das nicht. Es ist wirklich kein Hexenwerk, 4kB Daten so auf mehrere UDP Frames aufzuteilen, das der Empfänger die Teile identifizieren kann.
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.
Beitrag #6586086 wurde von einem Moderator gelöscht.
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
Johannes S. schrieb: > Und die Fragmentierung hat man in die Basis von IP eingebaut. Eine Folge damaliger realer Übertragungsstrecken und einer unbrauchbar definierten Mindest-MTU. Mittlerweile sind ein paar Tage vergangen. Man hat in IPv6 die Fragmentierung durch Router ausgeschlossen, dafür aber eine brauchbare Mindest-MTU definiert.
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. 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.
:
Bearbeitet durch User
Man sollte zwischen fragmentation/reassembly durch die Endknoten und Fragmentierung durch Router in der Übertragungsstrecke unterscheiden. Das hat recht wenig miteinander zu tun.
:
Bearbeitet durch User
(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
Sebastian schrieb: > So ein Protokoll tut entweder nur genau das was IP > fragmentation/reassembly tut, oder es ist nicht mehr simpel. Was ich soeben schrieb... Der Thread rührt zwei Themen zu einem Eintopf zusammen, die getrennt besser schmecken. Zudem ist hier lwIP im Spiel. Mir ist der nur als betont einfacher Stack bekannt, das könnte aber für die Lösung von Belang sein.
:
Bearbeitet durch User
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.
Man kann eine Lösungen durchaus so definieren, dass sie nur mit Jumbo Frames funktioniert. Das steht dann in den Prerequisites der Lösung halt drin. Man sollte drauf achten, dass diese Eigenschaft alle Komponenten betrifft, die sich innerhalb des IP-Netzes befinden, und die mit jenen Komponenten kommunizieren, die mit Jumbo Frames arbeiten. Sowohl sämtliche beteiligten Switches, als auch alle Endknoten, die in den Genuss solcher Frames kommen könnten. Will man keine Falltür haben, in die man später reintappt, passt man besser alle Komponenten des IP-Netzes an, ob sie anfangs was damit zu tun haben oder nicht. Eine netzgesteuerte Stromleiste, die aussteigt, wenn sie versehentlich einen Jumbo abkriegt, ist zwar Mist, aber mit solchen Spässen muss man rechnen. Baut man das Netz neu auf, oder ist es sehr einfach aufgebaut, ist das kein Problem. Interessant wird es aber, wenn man damit auf ein bereits existierendes nicht-triviales Produktionsnetz mit etlichen bereits vorhandenen Komponenten aus allen Zeitaltern trifft. Es ist ziemlich wahrscheinlich, dass dieses Netz noch nicht darauf eingerichtet ist. Und es ist ziemlich wahrscheinlich, dass die Netzwerker auf eine Idee, das Netz passend zu machen, wenig begeistert reagieren werden. Wenn dieses Produktionsnetz dann obendrein nicht mehr wie vor zig Jahren aus lauter getrenntem Blech für getrennte IP-Netze besteht, sondern massiv mit VLANs durchsetzt ist, dann sind auch jene Netzbereiche betroffen, die auf den ersten Blick überhaupt nichts mit dem Thema zu tun haben.
:
Bearbeitet durch User
(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.
Johannes S. schrieb: > @A. K.: ich nehme an du bist Admin für ein größeres Netzwerk? Ja. > 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. So waren vor 25 Jahren die meisten Netze aufgebaut. Es gab zentrale L3-Router an deren Ports L2-Switches ohne VLANs hingen. Wollte man da in einem IP-Netz mit Jumbos arbeiten, waren die betroffenen Switches gefragt, der Router-Port dazu, und alle Komponenten in diesem Netz. Der logische Aufbau war mit dem physikalischen Aufbau identisch. Sieht heute etwas anders aus. Nicht nur die zentralen L2/L3-Switches haben alle VLANs an Bord, sondern die VLANs können sich aufs ganze Haus ausdehnen. Wer eine bestimmte Geräteklasse - beispielsweise für eine Zugangskontrolle - nicht im normalen Hausnetz haben will, hängt die Teile an den nächsten jeweils passenden Stockwerks-Switch und definiert dessen Port als zu einem ungerouteten oder per Firewall abgetrennten Zugangskontroll-VLAN gehörig. Dieses Spezialnetz durchzieht also potentiell die gesamte Switch-Infrastruktur des Hauses und verbindet sich untereinander über die gleichen Kabel wie die PCs der HR, ist aber auf logischer Ebene davon völlig getrennt, nicht ansprechbar. Wollte man dieses Spezialnetz Jumbo-tauglich machen, müsste man es für sämtliche Komponenten der Netzinfrastruktur tun, bei denen solche Geräte auftauchen können. Also eigentlich für alle. Oder man zieht eigens dafür wieder wie in alten Zeiten separate Kabel nur dafür durchs ganze Haus in die RZs. Obendrein sind die zentralen Server wahrscheinlich kein Blech, sondern sind virtualisiert, das Zugangskontrollsystem inklusive. Die Virtualisierungshosts haben Trunks ins Netzwerk und die VMs lassen sich in beliebige VLANs hängen. Womit also auch die virtuellen Switches in den Hosts ihren Spass mit Jumbos haben können. Hier findet also eine Trennung von logischem und physikalischem Aufbau des Netzwerkes statt, bis hin zu Software Defined Networking: https://de.wikipedia.org/wiki/Software-defined_Networking Rein durch den physikalischen Aufbau definierte Netze haben bei kritischen Produktionsmaschinen durchaus noch ihren Sinn (bis hin zu technisch archaischem aber heute noch genutzem Koax-Arcnet). Aber der Rest hat sich längst davon abgekoppelt.
:
Bearbeitet durch User
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: > 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.
:
Bearbeitet durch User
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.
PittyJ schrieb: > Für Ping oder so etwas wie Arp ist UDP super. Ähem... Ping läuft über ICMP, also nix UDP. ARP ist für die Auflösung der MAC-Adressen im lokalen Netzwerk zuständig und hat ebenso weder etwas mit UDP noch mit TCP zu tun. Einfach mal die gängigen Schichtenmodelle anschauen.
:
Bearbeitet durch Moderator
Frank M. schrieb: > ARP ist für die Auflösung der MAC-Adressen im lokalen Netzwerk zuständig > und hat ebenso weder etwas mit UDP noch mit TCP zu tun. Genau genommen nicht einmal mit IP, EtherType 0x0806 statt 0x0800.
:
Bearbeitet durch User
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.