digi_c - Sa 11.02.06 16:15
Titel: Sockets/Indy zeitkritisch?

---

Mahlzeit,
ich da wir in unserem Betrieb wohl ein ähnliches Problem haben, würde mich mal folgendes interessieren:

Situtation:
-beides per TCP Indy Sockets
-sehr viele Clientanwendungen(natürlich Stoßzeiten :roll: )
-eine Serveranwendung
-diese nimmt Anforderungen auf einen Port entgegen
-bearbeitet sie in eigenen Threads, was durch DB Rückfragen recht lange dauert(~1s)
-schickt Antwort und verbindung wird durch Client getrennt

Problem:
Bei Belastungstest durch mäßig viele(~20) Clients werden einige Abfragen schon nicht beantwortet.
Lokal mit 5 Clientprogrammen ging alles glatt(aber Loopback Adressen verkürzen das Ganze IMHO ja erheblich).
Simulation auf virtuellem Server im Netz klapt mal besser mal schlechter(mit dessen Auslastung kann es eigentlich nicht zusammenhängen da der 1.Belastungstest in der Nacht war wo keiner arbeitete->Auslassungen, Nachmittags wo noch andere auf dem Server arbeiteten waren viel weniger Aussetzer :eyecrazy: )

Die Frage ist wie das kommt. Probleme beim Multithreading? Oder läuft da das Timeout bei den Clients ab?
Da die Verbindung aber angenommen werden(viele Wartend bei netstat Ausgabe) weiß ich nicht so recht aber ich habe es auch nicht programmiert.

Narses - So 12.02.06 23:53

---

Moin!

Na, du hast ja Fragen... :wink:

Wenn du es nicht programmiert hast, wie willst du denn da qualifizierte Aussagen von uns haben? :gruebel: Wenn du ja quasi gar nicht beschreiben kannst, was da genau passiert... ?! :|

Deshalb nur Allgemeines: Wenn es TCP-Verbindungen sind, dann gibt es entweder eine Fehlerbedingung oder korrekte Datenübertragung, da ist zwar auch ein Timeout mit drin, aber das ändert nix an der gesicherten Verbindung. Also an den Sockets (der WSA, konkret) wird das sicher nicht liegen. Fazit: Es kommt eben darauf an, was da wirklich gemacht wird, in dem Code. Wenn dann auch noch eine DB beteiligt ist, sind da ja noch viel mehr potentielle Fehlerquellen im Spiel. Die Situation ist IMHO für uns hier viel zu komplex, um irgendetwas sinnvolles dazu sagen zu können.

cu
Narses

digi_c - Mo 13.02.06 09:37

---

Ja ich ahnte schon das das vielleicht "ein wenig" zu theoretisch ist.

Es ging mir eigentlich nur darum:
Kann eine SocketVerbindung die den Zustand warten hat ein Timeout beim Client erzeugen, weil der Server noch keine Nutzdaten schicken konnte?

Narses - Mo 13.02.06 10:50

---

Moin!

digi_c hat folgendes geschrieben:

Kann eine SocketVerbindung die den Zustand warten hat ein Timeout beim Client erzeugen, weil der Server noch keine Nutzdaten schicken konnte?

Es gibt keinen "Warten-Zustand" bei einer TCP-Verbindung, die ist entweder verbunden, oder sie ist es nicht. Die Timeouts kommen idR von einem Router oder ähnlichen aktiven Netzwerkkomponenten, wenn es eine NAT/Porttranslator-Funktion gibt. In einem "Minimal-LAN" - Crossoverkabel - würde eine TCP-Verbindung, die einmal aufgebaut ist, praktisch ewig bestehen bleiben, solange die Hosts aktiv sind.

AFAIK ist es beim Anlegen des TCP-Sockets möglich, einen keep-alive-Mechanismus per Option zu setzen; ist aber aus dem Kopf, schau halt ins MSDN bei der WSA-Doku.

cu
Narses

digi_c - Mo 13.02.06 12:29

---

Ich bin doch echt zu doof, ich mein natürlich nicht Sockets sondern die Indys :roll:
Ich sagte bloß Sockets weil ab und zu "Socket Errors" kommen .

"och mönsch...."

Narses - Mo 13.02.06 15:14

---

Moin!

Also, wenn ich ganz ehrlich bin, glaube ich nicht, dass das an den Indies liegt; wenn die so buggy wären, würde das auch schon andern aufgefallen sein. :wink:

Fazit: das liegt an diesem ominösen Prog (gerade bei multithreaded-Anwendungen, naja...)... :|

cu
Narses

digi_c - Mo 13.02.06 16:18

---

Ja wir konnten den Fehler schon einschränken, das der Client da vermutlich irgendwie nen Schuss weg hat.

Danke dir nochmal :)