Laden...

TCPClient: Vebindung wird vom Server getrennt

Erstellt von mutzel vor 18 Jahren Letzter Beitrag vor 18 Jahren 4.619 Views
M
mutzel Themenstarter:in
40 Beiträge seit 2006
vor 18 Jahren
TCPClient: Vebindung wird vom Server getrennt

hallo...

Wenn meine Vebindung (TCPClient) vom Server aus getrennt wird, so bekommt das der TCPClient aus mir unbekannten Gründen nicht mit... ein Verbindungsabbruch durch Ziehen des LAN-Steckers funktioniert jedoch einwandfrei...

Ich hab das ganze dann mit Ethereal mal beobachtet und habe folgendes rausgefunden:

mit dem Windows Telnet Tool:_
No. Time Source Destination Protocol Info
1 0.000000 192.168.0.3 192.168.0.2 TCP 2581 > telnet [SYN] Seq=0 Ack=0 Win=16384 Len=0 MSS=1460
2 0.002906 192.168.0.2 192.168.0.3 TCP telnet > 2581 [SYN, ACK] Seq=0 Ack=1 Win=16 Len=0 MSS=1460
3 0.002929 192.168.0.3 192.168.0.2 TCP 2581 > telnet [ACK] Seq=1 Ack=1 Win=17520 Len=0
4 0.005531 192.168.0.2 192.168.0.3 TELNET Telnet Data ...
5 0.107361 192.168.0.3 192.168.0.2 TCP 2581 > telnet [ACK] Seq=1 Ack=47 Win=17474 Len=0
6 29.578807 192.168.0.2 192.168.0.3 TCP telnet > 2581 [FIN, ACK] Seq=47 Ack=1 Win=16 Len=0
7 29.578864 192.168.0.3 192.168.0.2 TCP 2581 > telnet [ACK] Seq=1 Ack=48 Win=17474 Len=0
8 29.579147 192.168.0.3 192.168.0.2 TCP 2581 > telnet [FIN, ACK] Seq=1 Ack=48 Win=17474 Len=0
9 29.581371 192.168.0.2 192.168.0.3 TCP telnet > 2581 [ACK] Seq=48 Ack=2 Win=16 Len=0_

hier sendet der server ein FIN an den Client... und der Client sendet brav ein FIN zurück .. und schon ist die Verbindung geschlossen

Mit dem auf TCPClient basierenden Tool
No. Time Source Destination Protocol Info
1 0.000000 192.168.0.3 192.168.0.2 TCP 2849 > telnet [SYN] Seq=0 Ack=0 Win=16384 Len=0 MSS=1460
2 0.002229 192.168.0.2 192.168.0.3 TCP telnet > 2849 [SYN, ACK] Seq=0 Ack=1 Win=16 Len=0 MSS=1460
3 0.002261 192.168.0.3 192.168.0.2 TCP 2849 > telnet [ACK] Seq=1 Ack=1 Win=17520 Len=0
4 0.004516 192.168.0.2 192.168.0.3 TELNET Telnet Data ...
5 0.108918 192.168.0.3 192.168.0.2 TCP 2849 > telnet [ACK] Seq=1 Ack=47 Win=17474 Len=0
6 29.133158 192.168.0.2 192.168.0.3 TCP telnet > 2849 [FIN, ACK] Seq=47 Ack=1 Win=16 Len=0
7 29.133193 192.168.0.3 192.168.0.2 TCP 2849 > telnet [ACK] Seq=1 Ack=48 Win=17474 Len=0

Hier fehlt die antwort auf das FIN vom Client...

...nun meine Frage... gibt es eine Möglichkeit herrauszufinden ob der socket ein FIN bekommen hat?
Wenn ich das nicht mitbekommen kann so denkt der TCPClient die ganze zeit das er noch verbunden ist.

I
1.739 Beiträge seit 2005
vor 18 Jahren

Ich vermute, im Heimnetzwerk geht der Einsatz eines Sniffers glimpflich aus...

Wer trennt wo die Verbindung?
Die Serverapplikation? Wenn ja könnte der Server auch eine Mitteilung senden("du bist weg") oder ähnliches. Die Clienapplikation kann ohne Rückmeldung nunmal nicht wissen, das sie aus dem Pool geworfen wurde. Das steht halt nicht so im Protokoll, darum muss man es selbst implementieren.

F
529 Beiträge seit 2003
vor 18 Jahren

Richtig. Evlt. muss man auch quasi sowas wie Pings implementiert, um den Server wissen zu lassen, welche der Clients jetzt weg sind.

Besuchen sie das VisualC++ - Forum

M
mutzel Themenstarter:in
40 Beiträge seit 2006
vor 18 Jahren

Die verbindung wird vom Server getrennt ... da der Server aber ein eigenständiges gerät ist, kann ich an der Firmware dort nix ändern...

mal davon abgesehen das der Server ja ein FIN sendet .. das problem ist nur das mir c# nicht sagt das ich das FIN bekommen hab ... denn beim Windows Telnet läuft das ganze ja auch einwandfrei .. der bekommt das FIN und antwortet mit einem FIN .. ohne mein Telnet-Protokoll wirklich zu kennen.

Ich hab früher mit Borland Builder programmiert dor hat das ganze auch einwandfrei geklappt ... war aber andere Socket Komponenten

Original von ikaros
Ich vermute, im Heimnetzwerk geht der Einsatz eines Sniffers glimpflich aus...

Was meinst du damit?

Original von Franknstein

Richtig. Evlt. muss man auch quasi sowas wie Pings implementiert, um den Server wissen zu lassen, welche der Clients jetzt weg sind.

Das Problem liegt meiner Meinung nicht beim Server da der ja ein FIN sendet.. Das heisst wenn dann muss man ein Ping auf dem Server einbauen damit der Client bescheit weiss .. aber das kann/will ich ja eben nicht ..

lg mutzel

F
529 Beiträge seit 2003
vor 18 Jahren

(Mein Beitrag ist völliger Blödsinn)

Das Fin ist aber vom Telnet-Protokoll implementiert und nicht vom TCP-Protokoll?

Besuchen sie das VisualC++ - Forum

I
1.739 Beiträge seit 2005
vor 18 Jahren

Original von Franknstein
(Mein Beitrag ist völliger Blödsinn)

Nein nicht völlig(der Client könnte auch die Connection prüfen, ähnlich wie ein Ping). Ist aber ein wenig crazy.

Das Fin ist aber vom Telnet-Protokoll implementiert und nicht vom TCP-Protokoll?

Fin ist Teil Telnet-Protokoll. Der Client muss es interpretieren können.

@mutzel
Dein Client muss also das Fin empfangen(tut er sowieso) und daraufhin die Verbindung beenden(implementieren)(tut er derzeit nicht).

Was meinst du damit?

In geschlossenen (Test-)Netzwerken ist der Einsatz ok, in Firmennetzwerken kanns zur Kündigung und noch mehr Konsequenzen führen.
Also nicht unbedingt relevant, aber vielleicht erwähnenswert(deinen Hintergrund kenn ich nicht, hab ja keinen Scanner auf den Forumsserver laufen...)

M
mutzel Themenstarter:in
40 Beiträge seit 2006
vor 18 Jahren

Original von ikaros
Fin ist Teil Telnet-Protokoll. Der Client muss es interpretieren können.

@mutzel
Dein Client muss also das Fin empfangen(tut er sowieso) und daraufhin die Verbindung beenden(implementieren)(tut er derzeit nicht).

Das klingt nicht so als ob du dich besonders gut mit TCP auskennst.


>

FIN
Dieses Finish-Flag dient zur Freigabe der Verbindung und zeigt an, dass keine Daten mehr vom Sender kommen. Die FIN- und SYN-Flags haben Sequenznummern, damit diese in der richtigen Reihenfolge abgearbeitet werden.

Ich hab das Problem jetzt gelöst. Mein Fehler war das ich dachte wenn ich mir ein TCPClient schnappe und ihn mit einem StreamReader auslese wird alles ganz einfach .. kling gut .. war aber nich so... also greif ich vor dem Lesen wieder auf den normalen Socket zu .. irgendwie doof aber geht anscheinend nicht anders...

hier meine Lösung:


if(Client.Available==0 && this.Client.Poll(1000, SelectMode.SelectRead)
{
// Socket ist abgestorben und ein Read gibt nur nullen aus
}

Wenn Poll mir also sagt der er lesen kann und keine Daten verfügbar sind weiss ich die Serverseite das FIN gesendet hat.

Trotzdem Danke für die Antworten! Vielleicht hat ja noch jemand ne idee wie ich auch ohne einen zugriff auf den Socket den Abbruch erkenne.

LG mutzel

ps.

Original von ikaros
In geschlossenen (Test-)Netzwerken ist der Einsatz ok, in Firmennetzwerken kanns zur Kündigung und noch mehr Konsequenzen führen.
Also nicht unbedingt relevant, aber vielleicht erwähnenswert(deinen Hintergrund kenn ich nicht, hab ja keinen Scanner auf den Forumsserver laufen...)

ich würde stark bezweifeln das ich mich strafbar mache wenn ich mit meinem "Debugtool" unverschlüsselte Daten empfange die automatisch weggefiltert werden und nie irgendwo geloggt werden.

Das wäre ja wie wenn ich vor ner gerade überfallenen Bank stehe und mir der Bankräuber den sack mit dem geld in die Hand drückt, ich ihn aber fallen lasse weil ich garkein Bock auf ne runde Katz und Maus mit den bullen hab.

I
1.739 Beiträge seit 2005
vor 18 Jahren

[Das klingt nicht so als ob du dich besonders gut mit TCP auskennst.

Stimmt ich nahm eine besondere Interpretation(im Telnet an) an.

Das Fin-Bit gibt an, dass der Sender ferig ist(keine weiteren Informationen zum senden). Sagt bei mir nicht Wikipedia sondern mein TCP/IP Nachsclagewerk).

Was sagt uns das?
Senden und Close. Aber weiter Lauschen.

Steht also in keiner Verbindung mit deinem Problem.

Viel Spass beim Lösen.