Stabilität einer INDY 10 Anwendung

[geskill]

Hey,
werden mit der Komponente möglicherweise mehrere Verbindungen zur exakt gleichen Zeit geführt. Also in Millisekunde xyz ein Update-Check und xyz ein Anwendungsrequest "whatever"?

Indy benutzt blockierende Sockets.

Ich habe festgestellt, dass in einem Programm mit vielen Verbindungen (zur exakt gleichen Zeit) dies zwangsläufig zu Problemen führt. Entweder musst du dies komplett Kontrolliert ausführen (mit maximal einer Verbindung zur gleichen Zeit) oder du benutzt ICS, welche nicht blockierend arbeitet.

Diese Erfahrung habe ich jedenfalls gemacht :/

Grüße

[mjustin]

Zitat von geskill:

Indy benutzt blockierende Sockets.

Ich habe festgestellt, dass in einem Programm mit vielen Verbindungen (zur exakt gleichen Zeit) dies zwangsläufig zu Problemen führt. Entweder musst du dies komplett Kontrolliert ausführen (mit maximal einer Verbindung zur gleichen Zeit) oder du benutzt ICS, welche nicht blockierend arbeitet.

Diese Erfahrung habe ich jedenfalls gemacht :/

Konkurrierender Zugriff auf einen Socket kann nur in einer Multithreading Anwendung gut gehen.

Es liegt nicht am blockierenden Zugriff, falls Indy bei vielen Verbindungen "Probleme" macht, sondern meist an Fehlern im Code, vor allem bei der Kommunikation mit dem Hauptthread der VCL geschieht das gern.

Auch das Betriebssystem spielt eine Rolle, zum Beispiel wenn die Socket-Verbindungen nicht wiederverwendet werden, sondern der Client immer wieder neue Sockets öffnet und schliesst. Die geschlossenen Sockets bleiben dann für einige Zeit in Warteposition (Status TIME_WAIT), und das System wird sehr schnell überlastet. Das kann man mit netstat oder TCPView leicht nachvollziehen.

Jede Indy Client Komponente baut ihre eigene TCP Verbindung über einen eigenen Socket auf. Bei einem Indy Server gibt es für jede Verbindung einen separaten Thread, und jeder Socket wird immer nur von einem Thread bedient.

[geskill]

Zitat von mjustin:

Auch das Betriebssystem spielt eine Rolle, zum Beispiel wenn die Socket-Verbindungen nicht wiederverwendet werden, sondern der Client immer wieder neue Sockets öffnet und schliesst. Die geschlossenen Sockets bleiben dann für einige Zeit in Warteposition (Status TIME_WAIT), und das System wird sehr schnell überlastet. Das kann man mit netstat oder TCPView leicht nachvollziehen.

Jede Indy Client Komponente baut ihre eigene TCP Verbindung über einen eigenen Socket auf.

Vielen Dank für die Information! Also bei mir lagen die Fehler dann wahrscheinlich an den vielen einzelnen Instanzen der Client-Komponenten (z.B. TIdHTTP). Die nur kurz benutzt wurden und danach wieder zerstört wurden.

[bernhard_LA]

wenn ich die TCP Server Anwendung incl. der Madshi Konponente laufen lasse kann ich innerhalb von 2 Tagen aktuell ~75.000 Client Server Verbindungen auf und wieder abbauen, und ca.30.000 größere Datenpackete austauschen.

Kann ein MemoryLeak meiner Anwendung zu diesem "komischen Laufzeitverhalten führen" ??