indy9 Beispiel BasicClientServer Server sendet Nachricht an alle Clients

[Bummi]

wenn man auf TCPServer und TCPClient aufbaut und gezwungen ist in GetThread ohnehin seinen eigene Clientthread zu implementieren, könnte man IMHO diesen um ein Messaging erweitern, in dem er dem Client bei Anforderung einfach weiter Daten schicken kann, beenden dann per spezieller Message. Der Client müsste dann nur entsprechend per WaitforData (Application.Prozessemassages) reagieren, gegf. sogar in einem eigenen Thread erzeugt/verwendet werden.

[Kostas]

Hallo,

so wie ich das sehe, könne das die Indy Komponenten nicht.
Die Komponenten ICS von http://www.overbyte.be haben ein TWSocket
welcher ein Event OnDataAvailable hat. Dieser wird getriggert sobald Daten vom Server an den Client
eingetroffen sind.

Mich wundert das sehr das Indy hier einen anderen Weg geht.
Gruß Kostas

[Kostas]

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.

[Furtbichler]

Ich verwende Indy für Standardaufgaben, d.h. mal schnell ne TCP-Kommunikation nach dem Query-Response Prinzip aufbauen (Client sendet Anforderung, bekommt Antwort).

ICS ist -wie erwähnt- eventbasiert. Für eine Unterhaltung muss man aber eine State-Machine bauen, was an sich kein Problem ist, aber dem sequentiellen Gedanken widerspricht.

[Kostas]

Hallo,

ich denke beide Technologien haben ihre Berechtigung. Für mein Projekt ist der Event getriebene
Ansatz besser. Um es nochmal zu betonen, Indy wird durch den blockierenden Thread nicht mehr traffic
verursachen. Es ist viel mehr eine Frage der Anforderung und der persönlichen Sympathie, für welche
Technologie man sich entscheidet. Beide Komponenten Suites sind stabil.

Gruß Kostas