Leider läßt sich dagegen nichts machen. (wir haben alles Mögliche versucht)
Zum Teil ist das auch ein Problem von Windows, denn dieses schließt die Ports nicht, wenn die Connection abreißt, womit
Indy (im Server oder auch im Client) nicht darüber informiert wird, daß die Connection eigentlich weg ist.
Kann man da wirklich nichts gegen machen? Da unsere Leute sich recht gerne aus dem WLan-Bereich entfernen und sie auch mal gerne vergessen, die Geräte in die Ladestationen zu stellen, kommt es leider öfters zu diesen Netzwerkabbrüchen.
Der Rechner, auf dem der Server läuft, wird aus bestimmten Gründen jede Nacht neugestartet (automatisiert!) Da ist ein nicht beendenbarer Server sehr hinderlich
Es ist bei
TCP völlig normal, dass der Server nicht erfährt wenn ein Client nicht mehr im Netzwerk ist. Der
Indy TCP Server kann damit auch problemlos umgehen, und sich sauber beenden, ohne dass die Clients dazu noch irgendetwas tun müssen.
Ist das Problem auch mit der aktuellen
Indy 10.5.8 Version nachvollziehbar?
Um die Ursache einzugrenzen würde ich eine Testversion der Anwendung bauen, in der das Problem ohne Zugriff auf externe Hardware nachvollziehbar ist, durch einen "simulierten" Client. Danach würde ich die Anwendung so weit reduzieren wie es möglich ist und der Fehler noch nachvollziehbar ist.
Zitat:
* Client meldet sich an Server an, verliert die Connection und kommt nicht wieder ins Netz. Server wird beendet: Es wird die Meldung an den toten Client gesendet und Server hängt sich auf. KEINE
Exception, keine andere Meldung.
Wenn es kein WLAN wäre, entspricht das "Anmelden, dann Netzwerkkabel des Clients entfernen", oder einfach "Anmelden, dann den Client abschalten".
Zitat:
* Client meldet sich an Server an, verliert die Connection, meldet sich nach Herstellung der Netzwerkverbindung erneut an Server an. Server wird beendet: Es sind zwei Connections in der Liste aufgelistet. Eine tote und eine aktive. An beiden wird das Ende-Signal gesendet. Der Server bekommt eine
Exception (Socket-Error 10054) und beendet sich dann sauber.
Bei welcher der beiden Connections kommt die
Exception? Seltsam, dass das zweite Anmelden dazu führt, dass die erste (dann "tote") Verbindung beim Herunterfahren keinen Hänger mehr auslöst - und wenn das zweite Anmelden nicht erfolgt, der Hänger auftritt.