TCP Connections hält man bei solchen Anwendungsfällen eigentlich immer permanent offen. Unter Windows kannst du mit einem
IOCP Server durchaus auch tausende Verbindungen gleichzeitig offen halten. Hierbei wird dann nicht pro eingehender Client Verbindung ein Thread erstellt, sondern ein Thread-Pool genutzt.
Das wären dann aber beides asynchrone non blocking Lösungen.
Zwischenzeitlich war ich der Meinung, dass die Indys vom Ansatz her sinnvoller wären. Sie arbeiten zwar blockierend aber die Kommunikation ist dafür klarer und nachvollziehbarer.
Was mich hier stört, ist die schlechtere Scalierbarkeit.
Es steht zwar aktuell nicht an, aber wenn es mal 1000 gleichzeitige Zugriffe auf einen Server gäbe, käme man mit den Indys halt (offenbar) in Probleme.
Insofern dachte ich mir, jetzt doch die Kommunikation asynchron abzuwickeln und diese selbst zu optimieren (also pro Client nicht mehrfach die selbe Information zu schicken und somit nicht massenweise Events anzuhäufen).
Eigentlich klingt das ganz gut (etwas mehr Aufwand aber auch mehr Leistung als bei den Indys) --- ABER --- ich würde die Events gern in eine eigene Warteschlange stellen und diese in einem eigenen Thread abarbeiten, also keine Windows-Messages erzeugen, sondern eigene in Form von Records oder Objekten.
Diese sollten in einer threadsaven Liste abgelegt werden (wenn sie vom Manger als relevant eingestuft werden) und dann in einem folgenden Schritt verarbeitet werden.
So könnte man z.B. folgendes lösen:
Alle Paar ms liefert der Server mir zur Anzeige meinen aktuellen Kontostand. Da dieser gerade erwartungsgemäß ansteigt 5..34..2345..194322... gibt es ständige Updates.
Da die Client-
GUI gerade so schnell nicht hinterherkommt könnte der Manager die vorherige Konto-Info verwerfen und mit der neusten überschreiben. So hat die
GUI dann nur eine Änderung darzustellen.
Sofern natürlich alle Änderungen relevant sind, könnte der Manager diese chronologisch sammeln.
Also das wäre meine bevorzugte Lösung -> non blocket sockets aber ohne an Windows(-Nachrichten) gebunden zu sein.
Aber so etwas gibt es nicht - oder?
...
ähh
...
halt
...
Ok, man könnte sich in der OnClientRead-Behandlung eine Liste von eigenen Nachrichten erzeugen...
Dann wäre es nur Aufgabe des Mainthreads, die Nachrichten für den Manager aufzubereiten, wo diese dann verarbeitet werden.
Aber damit wäre man immer noch auf Windows festgelegt und könnte nicht so einfach auf eine andere Plattform wechseln.
Also steht die Entscheidung wohl zwischen
1)
Indy als einfache Lösung mit der Option anderer Plattformen, aber eingeschränkter Client-Anzahl
2) non blocket Sockets (oder ICS) als performantere Lösung mit mehr eigenem Verwaltungsaufwand aber Festlegung auf Windows
Ich bin weiterhin verwirrt und für Äußerungen dankbar.
EDIT:
Mein gewünschtes Modell wäre wohl so etwas wie ein IOCP-Server. Das schaue ich mir heute Abend nochmal genauer an. Aber wäre das auch auf anderen Plattformen umsetzbar?
UDP ist für mich kein Thema. Nachrichten müssen sicher ankommen.