indy9 Beispiel BasicClientServer Server sendet Nachricht an alle Clients

[Kostas]

Danke für die Info.

Was mich gerade masiv beschäftigt, wenn der Client keinen Event bekommen sollte dass eben Daten anstehen, würde das bedeuten dass IdTCPClient1.IOHandler.Capture(lboxResults.Items); eine Anfrage zum Server senden
würde. Ich habe schon Beispiele gesehen die innerhalb eines Threads in einer Endlosschleife permanent

Code:

if not IdTCPClient1.IOHandler.InputBufferIsEmpty
then IdTCPClient1.IOHandler.ReadString()

ausführen. Damit hätte man permanent Datenverkehr zum Server.
Das kann ich mir nicht vorstellen dass das so sein soll.

Gruß Kostas

[nuclearping]

Im Prinzip ist so eine Endlosschleife richtig, bzw. eine Möglichkeit, Daten abzufragen.

Diese Schleife würde dann aber, ohne getrennte Verarbeitung, wohl ALLE Daten der Kommunikation zw. Client und Server abfangen, also auch die Antworten, die du als Request rausschickst, was einem ziemlich viele Falten auf die Stirn zaubern kann.

Alternativ, statt die Anfragen vom Server aus direkt zu senden, kannst du im Server für jeden Client eine Message-Queue (TIdThreadSafeList) anlegen, in die du die Nachrichten für den jeweiligen Client ablegst. Der Client schickt dann periodisch eine Anfrage á la "Hast du neue Nachrichten?" und der Server antwortet mit der Anzahl der Nachrichten, gefolgt von den Nachrichten selber.

Das wäre die sauberere Vorgehensweise.

[Kostas]

Hallo.

Was mir hierbei nicht gefehlt ist, mit einem Beispiel erklärt.
Angenommen ich habe eine Telefonieanwendung(CTI). Der Server ist mit der Telefonanlage verbunden,
und alle Nebenstellen verbinden sich mit dem Server. Der Client sendet ein Kommando, wähle die Nr.
Der Server führ das aus. Jetzt kommt für die Nebenstelle ein Anruf rein. Der Server soll aus der Datenbank
die Nr suchen und an den Client die Nummer, Firma, und Name senden. Wenn der Server den Client nicht antriggern
kann, und der Initiator nur der Client ist, würde das bedeuten dass der Client mindestens 1/Sec den Server
fragen müsste "Ruft mich irgend eine Sau an " Wenn der Server Pech hat, ruft mich eine ganze Woche
keiner an. Es würde also jede Menge traffic erzeugt für nichts. Das halte ich nicht für sauber.
Dafür auf beiden Seiten ein Client und ein Server zu platzieren gefehlt mir auch nicht da ich dafür zwei Ports benutzen müsste.

Gruß Kostas

[BUG]

Zitat von Kostas:

Damit hätte man permanent Datenverkehr zum Server.
Das kann ich mir nicht vorstellen dass das so sein soll.

So ist es ja auch nicht ... lies dir nochmal den Post von sx2008 durch:

Zitat von sx2008:

Sobald Client und Server verbunden sind, gibt es keinen Unterschied mehr zwischen den beiden Endpunkten.
TCP/IP verbindet die Beiden wie mit zwei Röhren in jeweils eine Richtung.
Beide Partner können jederzeit Daten in die wegführende Röhre schieben.
Beim Empfänger landen diese Daten zunächst in einem FIFO.

Das Problem bei der von dir genannten Lösung ist eher, dass da ein Thread umgebremst in einer Schleife rumfährt (aktives Warten).
Da ist die Frage, ob Indy blockierende Leseoperationen kann ... vermutlich schon.

Der Vorschlag von nuclearping ist nicht so gut:

Zitat von nuclearping:

Der Client schickt dann periodisch eine Anfrage á la "Hast du neue Nachrichten?" und der Server antwortet mit der Anzahl der Nachrichten, gefolgt von den Nachrichten selber

Diese saubere Lösung schickt immer wieder Anfragen an den Server (Polling), ohne das der was zu sagen hat ... im schlechtesten Fall verbrezelst du haufenweise Bandbreite um letztlich keine einzige Nachricht zu bekommen.
Der JavaScript-Gemeinde, die dank HTTP nur solche Protokolle nutzen konnte, wurde mittlerweile mit Websockets geholfen.
Und was können die? Im Grunde das gleiche wie TCP (noch ein bisschen Glitzer drauf).

Wenn also deine Nachricht vom Server kommt, dann sollte der diese ungefragt zu deinen Clienten schieben können => Push.

[Kostas]

Hallo,

jetzt wäre interessant zu wissen wie das mit Indy geht.
Wenn IdTCPClient kein Event dafür kennt. Möglicherweise gibt es Methoden oder irgendeine Technologie
die dafür genutzt werden kann.

Gruß Kostas

[nuclearping]

Zitat von sx2008:

Das ist so nicht ganz richtig.
[...]
Die WinSock API bietet prinzipell die Möglichkeit über bestimmte Events (z.B Eintreffen neuer Daten) informiert zu werden (WSAEventSelect()).
[...]
Ob Indy das benützt müsste man nachforschen.

Ok, das wusste ich nicht. Bei Indy ist es jedenfalls so, dass die Daten erst über die Leitung gehen, wenn der Read-Request vom Client kommt. Zumindest habe ich das hier beim Debuggen festgestellt, dass der Breakpoint im Server erst dann ausgelöst wird, wenn im Client IOHandler.ReadXYZ ausgeführt wird.

Zitat von BUG:

Diese saubere Lösung schickt immer wieder Anfragen an den Server (Polling), ohne das der was zu sagen hat ... im schlechtesten Fall verbrezelst du haufenweise Bandbreite um letztlich keine einzige Nachricht zu bekommen.

Ok, da hast du natürlich recht.

Würde mich aber auch interessieren, wie das Pushen mit Indy funktioniert, da ich momentan ja an einem ähnlichen Problem sitze und das mit der Polling-Methode gelöst habe, was auch sauber funktioniert. Und da in meinem Fall ohnehin immer mit Traffic zu rechnen ist, während der Server läuft, ist das nicht problematisch.

[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.