Hallo zusammen, ich steuere mit meinem PC über VB5 zwei externe LAN Geräte über TCP/IP an. Folgender Ablauf: Kommando an Gerät 1 Warte 100 ms Kommando an Gerät 2 Warte 100 ms Kommando an Gerät 1 Warte 100 ms Kommando an Gerät 2 Warte 100 ms Ein weiterer Task empfängt die Antworten der beiden Geräte und wertet diese aus. Wenn alle 3 Geräte (inkl. PC) an einem Switch hängen, dann klappt alles Bestens. Wenn aber das Programm auf einem PC ausgeführt wird, der über WLAN und einen Accesspoint und einen weiteren Switch ans Netzwerk angekoppelt ist, kommt es zeitweise zu Störungen am Gerät 2. Es sieht so aus, als ob einige Kommandos "verschluckt" werden. Ich habe den Verdacht, dass es zeitweise (bei Datenstau) dazu kommt, dass 2 Kommandos aus 2 verschiedenen TCP-IP Paketen zusammen in ein Paket gepackt werden. Wenn ich direkt ein Datenpaket mit 2 Kommandos an Gerät 2 sende, dann wird in der Tat nur der erste Befehl ausgeführt. Frage: Kann es sein, dass vom wem auch immer 2 Pakete für einen Empfänger zusammengepackt werden ? Gruß Dirk
Dirk F schrieb: > Frage: Kann es sein, dass vom wem auch immer 2 Pakete für einen > Empfänger zusammengepackt werden ? kommt darauf an. Wenn du TCP verwendet hast du keinen wirklichen Einfluss auf Packete. Der IP-Stack entscheidet wenn er das packet absendet und was alles in einem Paket vorhanden ist. Mit TCP_NODALAY kann man das sofortige Senden erzwingen. Bei UDP sind es wirklich Pakete die du aus der Anwendung versendest.
Hallo Peter, danke für die Antwort. Also Gerät 2 ist ja mein Eigenbau, auf dem der TCP-IP Stack von Microchip läuft. Dann werde ich wohl die Firmware im Gerät2 und das VB5 Programm so ändern, dass auch mehrere Befehle pro Datenpaket verarbeitet werden. Danke und Gruß
Dirk F schrieb: > Dann werde ich wohl die Firmware im Gerät2 und das VB5 Programm so > ändern, dass auch mehrere Befehle pro Datenpaket verarbeitet werden. so ganz klar ist das nicht was du meinst. bei TCP gibt es für die Anwendung keine Pakete. Man liest Byte für Byte einen Datenstrom. Wenn ein "Befehl" zu ende ist, dann kannst du ihn doch ausführen. Dann liest man die nächsten Bytes.
Schau dir erstmal mit Wireshark an was an deinem PC passiert - ich tippe mal drauf, dass dein Programm nicht mit klarkommt, wenn Kommandos gleichzeitig verabeitet werden sollen..
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 ...
Frank E. schrieb: > - benutzt du für die Nachrichten zu den Empfängern immer den gleichen > Socket oder jeweils einen pro Empfänger? Ich verwende 2 Sockets in dem VB5 Programm. > - öffnest und schließt du die TCP-Verbindung jedesmal oder lässt du sie > nach der Errichtung bestehen? Die bleibt offen.
TestX schrieb: > dass dein Programm nicht mit klarkommt, wenn Kommandos > gleichzeitig verabeitet werden sollen.. Aber normalerweise sollte es ja nicht "gleichzeitig" sein, da ja immer 100 ms Delay dazwischen sind....
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.
Die werden nicht "in ein Paket gewandelt" - sowas bekommt dein Applikation Layer nicht mehr mit. Allerdings werden bei WLAN Datenpakete zu einem "Burst" zusammengefasst bzw. gepuffert - daher haben deine Delays keine Wirkung mehr. Das Ganze hört sich erfahrungsgemäß nach einem Fehler in deinem VB Programm an ...
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.
Dirk F schrieb: > Ich vermute nur, dass 2 Paketen in ein Paket gewandelt werden. aber das ist doch egal, du liest Byte für Byte die Daten aus. Es spielt doch überhaupt keine Rolle ob es in 1 oder 10 packeten übermittelt wurden ist. TCP ist ein Datenstrom und kein paket-dienst.
TestX schrieb: > Das Ganze hört sich erfahrungsgemäß nach einem Fehler in deinem VB > Programm an ... Soll ich den Quellcode mal hochladen ?
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
Peter II schrieb: > aber das ist doch egal, du liest Byte für Byte die Daten aus. Es spielt > doch überhaupt keine Rolle ob es in 1 oder 10 packeten übermittelt > wurden ist. Ich denke, ganau da liegt das Problem. Wenn ein Paket ankommt, dann werte ich nur die ersten Bytes, die zu einem Befehl gehören aus, der Rest wird verworfen. Dies gilt für das VB5 Programm und auch für die Firmware des "Gerät2"
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.
Dirk F schrieb: > Ich denke, ganau da liegt das Problem. > Wenn ein Paket ankommt, dann werte ich nur die ersten Bytes, die zu > einem Befehl gehören aus, der Rest wird verworfen. > Dies gilt für das VB5 Programm und auch für die Firmware des "Gerät2" dann musst du das ändern, es kann sogar noch schlimmer werden. Das jeder Buchstabe einzeln bei dir ankommt. du musst selber "sammeln" bis du ein Befehl zusammen hast.
Max M. schrieb: > Aber bei Kollisionen/Überlastung dürfen Pakete verworfen werden. spielt bei TCP keine Rolle, dann wird es von Stack wiederholt. > > 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? weil es sinnvoll ist um Overhead zu sparen, das ist die übliche Aufgabe von einen TCP-Stack. Spielt auch gar keine rolle, wenn man die Anwendung richtig Programmiert.
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.
:
Bearbeitet durch User
Dirk F schrieb: > Hier der VB5 Code. wie vermutet, du hoffst das bei einem DatenEvent auch alle Daten vorliegen die du brauchst und wie du schon bemerkt hast, alles was du nicht erwartest wegschmeißt. du brauchst einen eigenen Puffer. Bei jedem Event fügst du die Daten zu dem Buffer hinzu. Dann schaust du nach ob ein vollständiger im Buffer steht, wenn ja führst du ihn aus. Wenn nein, wartest du auf die nächsten Daten.
Peter II schrieb: > wie vermutet, du hoffst das bei einem DatenEvent auch alle Daten > vorliegen die du brauchst und wie du schon bemerkt hast, alles was du > nicht erwartest wegschmeißt. OK. UNd das gilt natürlich auch für die Firmware, weil da mache ich es ganau so..... Danke an alle für die schnelle Hilfe !!
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.
:
Bearbeitet durch User
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. er schafft es ja nicht mal einfache Daten zu übertragen, bei Websocket kommen noch 2 schichten Dazu ( http + websocket ). Was soll daran einfacher sein? Schon die Sachen mit dem key macht die Sache viel komplizierter. WebSocket ist ja ok für Webanwendungen, aber nicht zur Übertragung zu einem primitiven Gerät.
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.
Daniel A. schrieb: > 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? was heißt Rad neu erfinden. Websocket hat das Rad schon zum Wiederholten mal neu erfunden. WebSocket bringt auch nur einen Datentunnel für den Browser, den es schon lange mit TCP gibt. TCP überträgt einen Datenstrom WebWsocket überträgt einen Datenstrom es wird dadurch nichts einfacher für ihn, nur doch 2 Protokolle die er implementieren muss.
@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.
Daniel A. schrieb: > 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. wenn ich bei TCP als erstes eine Länge senden und dann die Daten habe ich das gleiche erreicht.
Dirk F schrieb: > Frage: Kann es sein, dass vom wem auch immer 2 Pakete für einen > Empfänger zusammengepackt werden ? Ja, natürlich ist das (zumindest theoretisch) möglich, das kommt auf den Übertragungsweg an. Der eigentliche Punkt ist aber: Es sollte bei korrekter Implementierung überhaupt keine Rolle spielen, wie genau die Pakete geschnürt werden (oder eventuell auf ihrem Weg durch das Netz auch umgeschnürt werden). TCP bildet einen STREAM ab. Und als Datenstrom sollten darüber ausgetauschte Daten auch behandelt werden. Und schon spielen irgendwelche Paketgrößen überhaupt keine Rolle mehr... Oder anders ausgedrückt: kaum macht man's wirklich richtig, schon funktioniert's...
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.