Telexforum.de

Ich glaube das liegt er auf meiner Seite es liegt nach ein Zeichen im Buffer was nicht abgeholt wird.

Problem behoben und mir ist noch aufgefallen. Beim Aktivitätstimeout schließt du einfach den Socket. Es wäre schön wenn du vorher ein END senden würdest, weil die Verbindung sauber beendet wurde. Das führt auf meiner Seite zum reconnect, weil ich denke da da ist was schief gelaufen. Den Timeout kann man ja frei einstellen und ich kann auf meiner Seite nicht ahnen weshalb der Socket geschlossen wurde.

Schaue ich mir an. Reconnect habe ich übrigens gar nicht implementiert.

Vielleicht kann man über eine checkbox nachdenken, ich fand es jetzt ganz praktisch zu schauen was passiert wenn die Verbindung geschlossen wird.

Hmm also wer sich über eine Wlan Verbindung über verlorene Zeichen Wundert das hat offenbar Ursachen im TCP/IP Stack. Es gibt zwar keine mindestens Größe der Payload, mir war aber mal so das man mindestens 64byte senden sollte. Die kleinen Pakete gegen augenscheinlich durch eine schlechte Wlan Verbindung verloren und können durch den TCP/IP Stack nicht gerettet werden.

Er unwahrscheinlich das bei dir Delef was faul ist, du musst jetzt auch nicht aktiv werden.

Es sei nur erwähnt das mit Wlan Pakete also Zeichen verloren gehen können und das ist am iTelex auch reproduzierbar.

Bei mir läuft hier alles über LAN. WLAN nutze ich nur bei piTelex-Systemen und dort auch nur testweise.

Nicht so ganz trivial das Problem, wenn man sich mal wieder mit TCP/IP beschäftigt

https://en.wikipedia.org/wiki/Nagle%27s_algorithm
https://learn.microsoft.com/en-us/previ ... cp-winsock

Werde mal die Sockoption TCP_NODELAY setzen und Probieren was passiert. Wie gesagt über Ethernet geht nichts verloren, passt man den remote Buffer an so das auch größere Pakete kommen minimiert sich das Problem.

Hast du das mal mit Wireshark geprüft?
Das kann doch nicht sein, dass TCP/IP-Pakete einfach so verloren gehen.

Auf welcher Plattform programmierst du denn da gerade?

damarco hat geschrieben: ↑Do 15. Mai 2025, 16:50 Hmm also wer sich über eine Wlan Verbindung über verlorene Zeichen Wundert das hat offenbar Ursachen im TCP/IP Stack. Die kleinen Pakete gegen augenscheinlich durch eine schlechte Wlan Verbindung verloren und können durch den TCP/IP Stack nicht gerettet werden.

Nichts ist unmöglich - Toyota....

Aber ich habe im Kopf, dass TCP eine Sicherungsschicht für IP ist und verlorene Pakete anhand der Sequence number identifiziert und erneut angefordert werden?
Und bei meinen sieben über WLAN verbundenen piTelex Installationen konnte ich bisher keine Zeichenverluste feststellen...

Ja wenn ein TCP ACK feht wird das Paket nochmal angefordert. Ich suche schon eine weile nach der Ursache, selbst dem Code habe ich umgebaut von einst select() und jetzt epoll verwendet. Es ist ja was im Grundsatz das Paket geht auf OS Seite verloren und ob nun select oder epoll bedient am ende die syscalls.

Ich habe den Remote Buffer von winTlx mal auf 1 gestellt und es gibt einen unerwarteten Effekt. Erwartet habe ich das nun alle 150ms bei 50 Baud gesendet werden, die Ausgabe erfolgt sehr verzögert. Das Verhalten kommt von der Flusssteuerung vermute ich, erst wenn wieder der Buffer leer ist wird wieder gesendet. Es macht also Sinn dieses Wert auf sinnvolle Values zu begrenzen.

Ich habe aber schlechte Nachrichten, es scheint laut Wireshark keinen Übertragungsfehler zu geben und trotzdem fehlt am Ende was