Wie erkennt Client wenn Server disconnected

[Sim_Star]

Hallo, ich bin dabei eine Server und Client Anwendung zu schreiben.

Ich verwende als Server die Komponente ServerSocket und als Client die Komponente ClientSocket.

Bisher erkennt der Server wenn ein Client verbindet oder sich trennt sowie welcher Client dies war.
Wenn man nun aber die Serveranwendung schließt und dann wieder öffnet, so verbindet sich der Client nicht neu, weil er anscheinend noch verbunden ist.

Wie bekomme ich nun hin, dass der Client merkt, dass sich die Serveranwendung schließt.
Serverseitig gibt es ja die Methode ServerClientDisconnect über die ich erkenne wenn sich ein CLient trennt.... gibt es sowas nicht auch Clientseitig?

[Tiffy]

Wie wäre es mit einem Timeout? Client fragt den Server ob er noch da ist. Entweder es gibt eine Antwort, oder es gibt keine.

[Dejan Vu]

Verschicke einfach ein Keep-Alive paket, z.b. innerhalb deines Protokolls ein 'X'. Der Server/die Gegenstelle muss dann mit einem 'Y' antworten. Das machst Du alle paar M Sekunden.

1. Der Client verschickt ein 'X'. Wenn nach M/2 Sekunde kein 'Y' kommt, ist die Verbindung tot.
2. Wenn der Server nicht alle M*1.2 Sekunden ein 'X' bekommt, ist der Client tot.

So wissen beide, wer wann tot ist. Man muss nur das Interval auf beiden Systemen gleich machen.

[Aphton]

Zitat:

Zitat von Dejan Vu (Beitrag 1304423)

Verschicke einfach ein Keep-Alive paket, z.b. innerhalb deines Protokolls ein 'X'. Der Server/die Gegenstelle muss dann mit einem 'Y' antworten. Das machst Du alle paar M Sekunden.

1. Der Client verschickt ein 'X'. Wenn nach M/2 Sekunde kein 'Y' kommt, ist die Verbindung tot.
2. Wenn der Server nicht alle M*1.2 Sekunden ein 'X' bekommt, ist der Client tot.

So wissen beide, wer wann tot ist. Man muss nur das Interval auf beiden Systemen gleich machen.

Ja, wenn es sich um UDP handelt.. Das hat er aber nicht genauer spezifiziert. Wenn es TCP ist, dann ist das irrelevant!

[himitsu]

Auch wenn bei TCP der Server verschwindet, dann bekommt der Client das nicht sofort mit, sogar Windows kann den Port noch etwas offen halten (manchmal sogar stundenlang)
das geht bis dahin, daß man die "kaputte" Verbindung nicht mehr tennen kann.

[stoxx]

> gibt es sowas nicht auch Clientseitig?

ja, gibt es natürlich

Hi .. bei einer TCP Socket Verbindung (z.b. mit einer Indy Komponente) gibt es ein Event "Disconnect".
Beidseitig für Server und Client, sollt einer die Verbindung abbauen.

Sollte jemand einfach nur das Netzwerkkabel ziehen, dann bekommst Du eigentlich immer innerhalb einer Minute das Disconnect dennoch mit.

Bei UDP gibts sowas gar nicht. Pakete werden einfach verschickt und kommen entweder an oder nicht an.

Client und Server müssen selbst die Empfangs-Bestätigung einer Message implementieren, wenn dies gewünscht (z.b. aufsteigende MessageID)

[mm1256]

Zitat:

Zitat von Sim_Star (Beitrag 1280235)

Wie bekomme ich nun hin, dass der Client merkt, dass sich die Serveranwendung schließt.
Serverseitig gibt es ja die Methode ServerClientDisconnect über die ich erkenne wenn sich ein CLient trennt.... gibt es sowas nicht auch Clientseitig?

Wäre das nicht ein klassischer Fall von Exception-Behandlung?

[Dejan Vu]

Zitat:

Zitat von Aphton (Beitrag 1304424)

Zitat:

Zitat von Dejan Vu (Beitrag 1304423)

Verschicke einfach ein Keep-Alive Paket

Ja, wenn es sich um UDP handelt.. Das hat er aber nicht genauer spezifiziert. Wenn es TCP ist, dann ist das irrelevant!

Äh... Nö. Das Verfahren wird in der Steuerungstechnik angewandt. Auch bei TCP-Verbindungen. Im wirklichen Leben bekommen weder Server noch Client immer mit, das eine Verbindung unterbrochen wurde. Dafür sorgen schon die intelligenten Switches.

Zitat:

Zitat von stoxx (Beitrag 1304426)

Sollte jemand einfach nur das Netzwerkkabel ziehen, dann bekommst Du eigentlich immer innerhalb einer Minute das Disconnect dennoch mit.

Genau. 'eigentlich' . Entwickler sollten das Wort "Eigentlich" eigentlich nicht verwenden ("Eigentlich läuft das Programm", "Der Fehler dürfte eigentlich nicht auftreten" ;-) ).

In den Firmen, in denen ich gearbeitet habe, war es den Geräten egal, das sie eigentlich vom Verbindungsabbruch innerhalb einer Minute informiert sein müssten. Sie wurden es nicht. Auch nach 8 Stunden nicht. Und selbst wenn das bei einer normalen Infrastruktur nach einer Minute bekannt wird... Ist das nicht ein wenig lang?

[Aphton]

@Dejan Vu

Es ist etwas lange her dass ich Netzwerk Programmierung betrieben habe, aber meine Erinnerung hat mich nicht getäuscht.. Siehe msdn recv()

Zitat:

Return value

If no error occurs, recv returns the number of bytes received and the buffer pointed to by the buf parameter will contain this data received. If the connection has been gracefully closed, the return value is zero.

Man muss keine Heartbeat Pakete unter TCP schicken. Die Programlogik funktioniert einfach normal weiter, bis bei einem rcv() ein Disconnect erkannt wird. Siehe Codesnippet aus meiner alten Library

Delphi-Quellcode:

  //...
    Result := recv(FSocket, Buffer, BufferSize, 0);
    case Result of
      0: Disconnect;
      SOCKET_ERROR:
      begin
        Result := WSAGetLastError();
        if Result = WSAEWOULDBLOCK then
          Result := 0
        else
          Disconnect;
      end;
    end;
  //...

Disconnect macht ein closesocket und setzt Disconnected boolean auf true..

[BUG]

Zitat:

Zitat von Aphton (Beitrag 1304492)

Man muss keine Heartbeat Pakete unter TCP schicken. Die Programlogik funktioniert einfach normal weiter, bis bei einem rcv() ein Disconnect erkannt wird.

Man muss nicht, man sollte aber vielleicht.
TCP-Verbindungen sollen teilweise auch lautlos den Bach runter gehen, was man dann aber erst beim Senden merken würde.

Gegen einen Heartbeat auf Anwendungsebene kann man afaik nicht so viel sagen.