Hmm, also dem Code nach, der im Indy-Quelltext steht zu urteilen, werden ja erst alle Clients nacheinander vom Server getrennt. Dann wird geschaut, ob in der (threadsicheren) Clientliste noch Einträge vorhanden sind. Falls ja, wird gewartet, und dann nochmal versucht, die verbleibenden Clients zu trennen. Wenn dann immernoch welche da sind, dann wird darauf geschlossen, dass ein oder mehrere Clients einen TimeOut haben, da man ja vorher schon versucht hat, deren Verbindungen zu trennen. Ob noch Einträge in dieser Liste vorhanden sind, wird in einer Boolean-Variable gespeichert. Und am Schluss wird abhängig davon, ob noch Clients verbunden sind, eine Exception ausgelöst, dass eben nicht alle Clientverbindungen getrennt werden konnten, eben durch einen TimeOut der Clients.

So, nachdem ich das jetzt alles getippt hab merk ich grade, dass ich nicht sicher bin, ob du eine Erklärung haben wolltest, wie eine Exception durch TimeOuts hier allgemein zustandekommt, oder was an deinem Code falsch ist, dass die Exception kommt

Aber ich muss noch was hinzufügen^^
In den Prozeduren TTCPIP.StartServer und TTCPIP.ConnectToServer hast du jeweils ein try-try-except-finally Konstrukt, soweit is das auch okay. Aber wenn jetzt ein Fehler auftritt udn der except-Code ausgeführt wird, wird eine Fehlermeldung ausgegeben. Sopäter wird aber immer der finally-Code ausgefürht, welcher meldet, dass alles einwandfrei geklappt hätte. Das wollte ich noch zur Programmlogik schreiben^^

Achja, noch was klitzekleines *g*
Es heißt nicht DisconnectToServer, sondern DisconnectFromServer

Damit ne gute Nacht