Hallo,
ich habe jetzt einiges gelesen über
Indy und ICS.
Indy arbeitet nach dem blockierenden Ansatz.
und ICS mit dem nicht blockierenden, event gesteuerten Ansatz.
Indy Arbeiter sozusagen Sequenziell
die Datenpakete ab und warten auf die nächste Aktion indem er den Thread in dem er läuft blockiert.
Die leseroutine muß also zwingend in einen eigenen Thread laufen welcher die Datenpakete abholt, und blockiert werden darf.
Hat einen gewissen Vorteil wenn das ausgehandelte Protokoll einen sequenziellen Ablauf zulässt.
Hiermit ist auch meine Vermutung dass der Client permanent Daten an den Server sendendet, höchstwahrscheinlich wiederlegt(Nicht getestet mit einem Port Sniffer).
Der Ansatz von ICS ist meines Erachtens deutlich besser. Da es Event gesteuert ist, kann die Kommunikation
ruhig auf dem Main Thread laufen. Was ich absolut Genital finde der WSocketServer verwaltet alle angemeldete
Client. Dabei wird eine Klasser erzeugt die mein Nutz-Objekt beschreibt und von TWSocketClient erbt.
Mein Nutz-Objekt aus sicht des Servers beinhaltet das WSocketClient Objekt auf dem entfernten Rechner.
Allerdings gibt es auch für
Indy ausreichend Anwendungsfällen die eine
Serialisierung fordern. Vermutlich ist das Thema so komplex dass es nicht möglich ist beide Technologien
in einer Komponenten Suite zu packen.
Gruß Kostas
[Edit] //http://edn.embarcadero.com/article/20465 ist ein für jeden verständliches Beispiel für ICS.