Telexforum.de

Moin Detlef,

die TCP SYNs verschwinden auf dem Weg zu dir (94.134.35.208:8139) spurlos. Bin ich jetzt auch bei dir im Filter?

Grüße


Björn

BjoernS hat geschrieben: ↑Do 1. Okt 2020, 21:08 die TCP SYNs verschwinden auf dem Weg zu dir (94.134.35.208:8139) spurlos. Bin ich jetzt auch bei dir im Filter?

Klar.

Ne, ich war gerade noch am Updaten. Versuchs bitte nochmal.

Hallo nochmal Detlef,

Wum lief problemlos durch, sieht alles gut aus. Verwendet habe ich piTelex 615ff92, mit i-Telex-konformem Druckpufferfeedback per Acknowledge.

Habe einen Wireshark-Mitschnitt gemacht, eine kleine Unregelmäßigkeit gibt es beim Trennen der Verbindung, was der Funktion aber keinen Abbruch tut. So hätte es theoretisch laufen sollen (Zustandsdiagramm: ):

1. Du leitest "active close" ein mit FIN/ACK: du ESTABLISHED=>FIN_WAIT_1, ich ESTABLISHED=>CLOSE_WAIT [Erste Hälfte der Verbindung wird geschlossen]
2. Mit dem ACK meiner Bestätigung schicke ich noch letzte Daten hinterher (i-Telex End): du FIN_WAIT_1=>FIN_WAIT_2
3. Ich leite "passive close" ein mit FIN/ACK: ich CLOSE_WAIT=>LAST_ACK [Zweite Hälfte der Verbindung wird geschlossen]
4. Du sendest ein letztes ACK: du FIN_WAIT_2=>TIME_WAIT, ich LAST_ACK=>CLOSED

So ist es stattdessen gelaufen, ein Bild sagt mehr als tausend Worte: Scheinbar machst du nach dem Senden deines FIN-Pakets (.close()-Aufruf), bei noch halboffener Verbindung, direkt den Socket platt und springst damit von FIN_WAIT_1 nach CLOSED. Deshalb weist dein IP-Stack mein FIN ab. Aber, Jammern auf hohem Niveau. Der Ausdruck hat funktioniert

Puh, spät is.

Moin, bei Abruf von "Madonna mit Kind" hatte ich - glaube ich - was Ähnliches, Bild lief komplett durch, danach wurde plötzlich getrennt und es kam eine Internet-Fehlermeldung, muss heute nachmittag nochmal gucken, was das für eine Meldung genau war ....

VG

detlef hat geschrieben: ↑Do 1. Okt 2020, 20:05 Ich werde sie dann umgehend auf dem Server zur Verfügung stellen (sofern sie nach den obigen Kriterien geeignet).

Baue doch einfach eine Abfrage ein "sind sie ueber 18?". So machen es andere Seiten doch auch

FredSonnenrein hat geschrieben: ↑Fr 2. Okt 2020, 08:19

detlef hat geschrieben: ↑Do 1. Okt 2020, 20:05 Ich werde sie dann umgehend auf dem Server zur Verfügung stellen (sofern sie nach den obigen Kriterien geeignet).

Baue doch einfach eine Abfrage ein "sind sie ueber 18?". So machen es andere Seiten doch auch

Hallo Detlef,
baue doch einfach ein verstecktes Kommando (Menüpunkt) in den Server ein um ins Dark-Telex zu gelangen.

Moin zusammen,

Franz hat geschrieben: ↑Fr 2. Okt 2020, 07:56 Moin, bei Abruf von "Madonna mit Kind" hatte ich - glaube ich - was Ähnliches, Bild lief komplett durch, danach wurde plötzlich getrennt und es kam eine Internet-Fehlermeldung, muss heute nachmittag nochmal gucken, was das für eine Meldung genau war ....

Nur um Missverständnisse zu vermeiden: Die Trennung passierte bei mir "normal gewollt" (Eingabe "99" im Menü), nur die Ausführung unter der Oberfläche war ungewöhnlich.

Grüße


Björn

Danke für die Rückmeldung, Björn.

Der Disconnect ist eine ewige Baustelle in meinen Server-Routinen. Fred war auch schon aufgefallen, dass das nicht sauber läuft. Das war aber ein anderes Problem.
Anscheinend wurde jetzt der Close überhaupt nicht ausgeführt und der Task ohne Close abgeräumt. Anders kann ich mir das nicht erklären.
Ich habe das jetzt nochmal umgebaut. Wäre nett, wenn du nochmal testen könntest ob sich irgendwas geändert hat.

Ich benutze die Dotnet TcpClient-Klasse. Die ist ziemlich high-level. Ausser Listen (AcceptTcpClient) und Close kann man da gar nicht viel machen.

detlef hat geschrieben: ↑Fr 2. Okt 2020, 11:57 Der Disconnect ist eine ewige Baustelle in meinen Server-Routinen. Fred war auch schon aufgefallen, dass das nicht sauber läuft. Das war aber ein anderes Problem.
Anscheinend wurde jetzt der Close überhaupt nicht ausgeführt und der Task ohne Close abgeräumt. Anders kann ich mir das nicht erklären.
Ich habe das jetzt nochmal umgebaut. Wäre nett, wenn du nochmal testen könntest ob sich irgendwas geändert hat.

Ich benutze die Dotnet TcpClient-Klasse. Die ist ziemlich high-level. Ausser Listen (AcceptTcpClient) und Close kann man da gar nicht viel machen.

Nein, .close() wurde ausgeführt, sonst wäre ja kein FIN von dir gekommen. Alles gut.

Rufst du auch .shutdown() vor .close() auf? Manche APIs machen das automatisch (IIRC Python-Sockets), manche wollen das explizit, um auch die "kommende" Hälfte der Verbindung leerzusaugen und sauber zu schließen. .net will es scheinbar explizit. Über das TcpClient.Client-Attribut müsstest du an den Socket kommen.

When using a connection-oriented Socket, always call the Shutdown method before closing the Socket. This ensures that all data is sent and received on the connected socket before it is closed.

Als Parameter müsstest du auch vmtl. explizit "beide Richtungen" angeben. Ich probiere später gerne nochmal. Wir "Bastler" müssen schließlich zusammenhalten!

Grüße


Björn

Ich hab mal den Shutdown() eingebaut. Das ist aber vom Aufbau der Klasse unlogisch, dass man bei einer High-Level-Klasse irgendwelche Low-Level-Funktionen aufrufen muss. Aber was ist bei Microsoft schon logisch.