Wie erkennt Client wenn Server disconnected

[Dejan Vu]

Zitat von Aphton:

Zitat von Dejan Vu:

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 von stoxx:

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 von Aphton:

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.

[Dejan Vu]

U

Zitat von Aphton:

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

Ich habe mich auch dagegen gewehrt, heartbeats und checksums einführen zu müssen, aber leider ist alles möglich.

[Net7]

Zitat:

Ich habe mich auch dagegen gewehrt, heartbeats und checksums einführen zu müssen, aber leider ist alles möglich.

Jup, man kann das aber auch nachstellen. Man nehme 2 PCs und ein Switch, man verbindet beide PCs via TCP ( Server-Client ) dann aus dem Switch die Netzwerkstecker raus und schon steht der Einsicht doch ein Heartbeat zu benutzen nichts mehr im Weg.

[Nimral]

Zitat von Dejan Vu:

Ä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.

Tschuldigt, wenn ich mich in den Thread drängle, aber das interessiert mich: inwiefern greifen "intelligente" Switches in das TCP Session Management ein?

Thx für Infos

Armin.

[BUG]

Zitat von Nimral:

Tschuldigt, wenn ich mich in den Thread drängle, aber das interessiert mich: inwiefern greifen "intelligente" Switches in das TCP Session Management ein?

Alles was selbst den Status der Sessions überwacht um zu entscheiden, ob Packete durchgelassen werden oder sie entsprechend zu addressieren (zB. NAT und Firewalls), ist schon mal verdächtig