TCP-IP / Können 2 Pakete vom Router zusammengefasst werden ?

Um die Problematik zu beurteilen, fehlen noch Informationen:

- benutzt du für die Nachrichten zu den Empfängern immer den gleichen 
Socket oder jeweils einen pro Empfänger?

- öffnest und schließt du die TCP-Verbindung jedesmal oder lässt du sie 
nach der Errichtung bestehen?

Bei korrekter Programmierung verschwinden bei einer TCP-Verbindung keine 
Pakete so einfach - genau dafür ist TCP nämlich gemacht ...

Dirk F schrieb:
> Frank E. schrieb:
>> Bei korrekter Programmierung verschwinden bei einer TCP-Verbindung keine
>> Pakete so einfach - genau dafür ist TCP nämlich gemacht ...
>
> Hatte ich ja auch nicht behauptet.
> Ich vermute nur, dass  2 Paketen in ein Paket gewandelt werden.

Wenn die Daten an verschiedene Empfänger gehen, passiert das nicht. TCP 
wird mittels Ethernet transportiert und die Frames werden per 
MAC-Adresse zugestellt. Verschiedene Empfänger - verschiedene Ziel-MAC.

Das ist nicht grundsätzlich ausgeschlossen. Bessere Ethernet-Adapter 
übernehmen die Funktion eines Teils des TCP/IP Stacks selbst. Da 
entspricht die Information im Wireshark Trace nicht der Situation im 
Netz. So kann man darin 64KB Frames sehen, die im sendenden Adapter 
zerlegt und im empfangenden wieder zusammengesetzt werden (nein, das 
sind keine jumbo frames).

https://en.wikipedia.org/wiki/TCP_offload_engine

Dirk F schrieb:
> Ich vermute nur, dass  2 Paketen in ein Paket gewandelt werden.

Und worauf gründet sich deine Vermutung?
Warum sollte irgend wer/was soetwas tun?
Und wiso Router? Ein Router kommt doch bei dir garnicht vor.

Aber bei Kollisionen/Überlastung dürfen Pakete verworfen werden.

Max M. schrieb:
> Und wiso Router? Ein Router kommt doch bei dir garnicht vor.

Aber evtl. ein intelligenter Adapter. Auch wenn das hier ebensogut etwas 
völlig anderes sein kann als Adapter-Offloading.

Es ist bei TCP nicht gewährleistet, dass die Daten in exakt der 
Paketgrösse beim Empfänger einlaufen, wie sie gesendet werden.

Du kannst die Probleme umgehen, statt sie zu lösen, wenn du UDP 
verwendest.

Dann wird das Datagramm auf Anwendungsebene zusammengebaut und bei 
"send" auch genau so gesendet. Beim Empfänger kommt auch nichts anderes 
an, als das was gesendet wurde ... in einem LAN gehen rel. selten Pakete 
verloren.

Zusätzlich könntest du ja auch auf UDP-Ebene einen Handshake 
implementieren, auch wenn das nicht unbedingt im Sinne der Erfinder ist 
...

Frank E. schrieb:
> auch wenn das nicht unbedingt im Sinne der Erfinder ist

Es ist völlig normal, ein Protokoll auf UDP aufzubauen und darin 
Quittungen und Wiederholungen zu implementieren.

Wenn eine Zentrale mit etlichen Knoten Messages austauscht, dann kann 
UDP auch mit selbst implementiertem Quittungverfahren einfacher und 
stabiler sein, als über N einzelne TCP Verbindungen. Es ist ein 
Standardfehler, für alles automatisch TCP einzusetzen.

Bei TCP dürfen keine Packete verworfen werden. Aber TCP-Packete dürfen 
vom TCP Stack beliebig unterzeilt oder Zusammengesetzt werden. Router 
sollten sich auf das Fragmentieren und Defragmentieren von IP Packeten 
beschränken (layer 2), aber das tun sie nicht. Router können TCP Packete 
in unterschiedliche IP Packete unterteilen, statt einfach das IP Packet 
zu fragmentieren, weil damit bei unterschiedlichen Maximalen 
Packetgrössen in layer 1 (z.B. Ethernet) weniger Fragmente mit einer 
grösseren Menge an Nutzdaten übertragen werden können und somit weniger 
overhead entsteht. (Unvolle IP Packete die TCP daten enthalten werden 
aufgefüllt und erst dann, oder wenn das Timeout erreicht ist, oder der 
buffer voll ist, versendet). Ein Router sollte davon abgehalten werden 
können, wenn in den IP Packeten das "do not fragment" flag gesetzt wird. 
Timeouts in TCP durch Cacheing können mit dem Pushflag verringert 
werden. Der Sendende/Empfangend TCP Stack kann dann aber trotzdem noch 
die Packete neu zusammensetzen. Dann gibt es noch das Urgent flag in 
TCP. Ich bin mir nicht sicher, ob Packete mit dem URG flag 
zusamengesetzt werden dürfen, zu dem Kapitel bin ich noch nicht 
gekommen.

Bei UDP sollten Router auch nur die IP Packete fragmentieren. Aber da 
UDP Packete verworfen oder ein teil davon Abgeschnitten werden darf, tun 
das die Router auch. Bei W-Lan Routern habe ich schon erlebt, dass 
hunderte UDP Packete gleichzeitig verworfen wurden! Es ist aöso 
definitiv keine gute Idee mehr Packete zu Senden als der Router in der 
Zeit weitersenden kann, weil man  dann alle packete verliert. Als ich 
den Fehler damals machte nützte auch meine logik um diese erneut zu 
Senden nichts mehr, weil diese einfach wieder verworfen wurden :/

In deinem Code fehlt eine weitere Unterteilung in Packete. Du musst die 
Länge der Befehle noch irgendwie mitsenden. Du kannst das mit deinem 
eigenen Protokoll machen, ich empfehle dir jedoch das Websocket 
Protokoll, dieses ist extrem Simpel und erlaubt eine ansteuerung vom 
Webbrowser aus.

http://tools.ietf.org/html/rfc6455#section-1.3
http://tools.ietf.org/html/rfc6455#section-5.2

Daniel A. schrieb:
> ich empfehle dir jedoch das Websocket
> Protokoll, dieses ist extrem Simpel und erlaubt eine ansteuerung vom
> Webbrowser aus.

LOL, simpel, WTF??? Websocket ist so ziemlich der aufgeblähteste Bloat 
(in 42 verschiedenen inkompatiblen Varianten erhältlich) der seit langer 
Zeit von irgendwem auf dieser Erde verbrochen wurde.

Peter II schrieb:
> er schafft es ja nicht mal einfache Daten zu übertragen,

Doch, im fehlt nurnoch das passende Protokoll.

> bei Websocket kommen noch 2 schichten Dazu ( http + websocket ).

Nein, nur eine Schicht. HTTP ist wirklich einfach, man hat immer ne 
Linie mit "Key: Value\r\n", und so die Upgrade Requests rauszufichen ist 
nicht schwer. Nach dem HTTP-Handshake gibt es das HTTP Layer nichtmehr, 
dafür das WebSocket layer drauf. Insgesamt gibt es somit nur eine 
schicht mehr, nicht 2.

> Was soll daran einfacher sein? Schon die Sachen mit dem key macht die Sache viel
> komplizierter.

Gut, der Key beim Handshake ist tatsächlich unnützer mist, es macht die 
Sache nicht sicherer und nen SHA1 Algorithmus zu Implementieren ist 
nicht trivial, aber das ist ja nur einmal beim HTTP Handshake und da 
hätte ich notfalls irgendwo noch eigene Implementierungen rumliegen. 
Aber nach dem Upgrade besteht jede Frame nur noch aus dem FIN und MASK 
Flag, einem Typ, ner länge und ner xor Maske, ich denke dies ist eines 
der simpelsten Formate überhaupt.

> WebSocket ist ja ok für Webanwendungen, aber nicht zur Übertragung zu
> einem primitiven Gerät.

Das Ding hat einen vollständigen TCP/IP Stack, es mag ja sein dass das 
einfacher geht, aber wenn man dazu später doch einmal eine Webanwendung 
schreiben wollen sollte ist dies extrem praktisch. Ausserdem, wieso das 
Rad neu erfinden wen man solch coole Standards implementieren kann?

Bernd K. schrieb:
> in 42 verschiedenen inkompatiblen Varianten erhältlich

Alle Browser verwenden Version 13, ich weis nicht wo du 42 Versionen 
gefunden haben willst, aber die von mir verlinkten RFCs wurden vor 
Jahren in Firefox, Chrome, IE10, Edge, Opera und Safari Implementiert.

@Peter II (Gast)

Das ist einfach falsch. Bei WebSocket hat man KEINEN Datenstrom. Man hat 
Pakete mit einer definierten Länge. Man kann sich bei WebSocket darauf 
verlassen, dass ein Gesendetes Paket mit genausovielen und den selben 
Daten ankommt wie beim Senden.

Also um die Ursprüngliche Frage zu beantworten, nein ein Router darf 
keine 2 Pakete zusammenfassen, falls er das doch macht so ist er 
kaputt....


aber... was Dein TCP/IP Stack daraus macht ist nicht definiert. Es kann 
durchaus sein, dass wenn Du 2 Schreibzugriffe machst, das in ein Paket 
gebündelt wird. Und es kann auch sein, dass Du ein Paket in 2 
Lesezugriffen bekommst. Das ist nicht definiert und 
implementationsabhängig. Somit muss Du, wenn Du Botschaften per TCP/IP 
schickst, Dich selbst um die Botschaftsgrenzen kümmern. Sinnvoll ist es 
zum Beispiel alle Botschaften als Text zu nehmen, und die Botschaften 
untereinander durch ein Zeilenende oder eine Leerzeile zu trennen.