Indy 10 asyncrone ServerInfo an Clients?

[stahli]

Ich habe erfolgreich eine Client/Server-Anwendung mit IdTCPServer und IdTCPClient (10) angefangen.
Die Kommunikation funktioniert perfekt (Client fragt an, Server antwortet).

Nun möchte ich, dass der Server gelegentlich von sich aus alle Clients über Neuigkeiten informiert. Die Clients entscheiden dann, ob und welche Daten sie abrufen.
Mit den Sockets war das ja recht einfach.

Wie macht man´s mit den Indys 10 am besten?


Diesen Schnippsel habe ich gefunden:

Delphi-Quellcode:

var
   cList: TList;
   Count: Integer;
 begin
   cList := IdTCPServer.Contexts.LockList;
   try
     for Count := 0 to cList.Count -1 do
       with TIdContext(cList[Count]) do
         Connection.IOHandler.WriteLn ('...');
   finally
     IdTCPServer.Contexts.UnlockList;
   end;
 end;

Ist das der beste Weg? Wie sieht die Cielt-Seite aus? Ohne Timer oder Thread wird es nicht gehen - oder?

[sx2008]

Normalerweise sollte das so laufen:
Server sendet an Client eine Message.
Im Client wird ein Event ausgelöst. (WinSock kann hier eine WM_SOCKET Message in die Message Queue legen)
In der Klasse TClientSocket aus der Unit ScktComp.pas gibt es dazu das Event OnRead.
http://docwiki.embarcadero.com/Libra...mSocket.OnRead

Der Client liest die bisher angekommenen Daten aus dem Socket und hängt sie an einen Puffer an.
Dann wird untersucht, ob der Puffer eine vollständige Message enthält (erkennbar am abschliesenden Return-Zeichen).
Jede vollständige Message wird aus dem Puffer ausgeschnitten und ausgewertet/bearbeitet.
Die Bearbeitung kann im Hautpthread (da das Event als Windows-Message erzeugt wurde, befinden wir uns im Kontext des Hauptthreads) durchgeführt werden oder einen anderen Thread übergeben werden.

Ich würde Indy nur dann verwenden, wenn gleichzeitig auch ein Protokoll wie z.B. POP3, SMTP, FTP, ... eingesetzt werden muss.
Wenn man sein eigenes Protokoll benützt und im Prinzip nur TCP/IP braucht, dann hat man mit Indy eine riesige Bibliothek aus der man nur 2% des Codes braucht.
Leider gibt es in Indy auch keine Trennung zwischen Datentransport (also TCP/IP oder UDP/IP) und dem eigentlichen Protokoll.

[Bummi]

(sorry für OT)

[stahli]

Ich hatte mein Testprojekt mit den Sockets angefangen. Das funktionierte dann auch ganz gut, allerdings kam ich mit der Übertragung von Streams und der GUI-Syncronisation (noch) nicht zurecht.

Daher habe ich es mit den Indys versucht und das soweit auch ganz gut realisieren können: http://www.delphipraxis.net/170904-i...ml#post1188420

Die syncrone Verbindung (ein Client fragt an und der Server antwortet ihm über die durch die Anfrage geöffnete Verbindung) finde ich auch nicht schlecht.

Da bis hierher mein Projekt sehr gut läuft würde ich (zumindest vorerst) bei den Indys bleiben wollen. Später kann man das ja imnmer noch umstellen, aber ich würde jetzt erst mal gern inhaltlich weiter kommen.
Mir fehlt eigentlich erst einmal nur die Realisierung einer eigenmächtigen Info vom Server zum Client.

Also falls jemand dazu einen Indy10-tauglichen Tipp hat...

[bernhard_LA]

ich hatte mal hierzu was auf Stackoverflow gefunden,
aktuell kann ich nur diesen Link anbieten http://stackoverflow.com/questions/5...-transfer?rq=1

[bernhard_LA]

oder mak nach two communication suchen http://boardreader.com/thread/Two_wa...3hwX584ep.html

[stahli]

Hmm, ich habe am WE mal nach einer Lösung, bin aber nicht weiter gekommen.

Vom Server aus kann ich ja offenbar alle Clients mit der o.g. Funktion anschreiben.
Ist auch hier so beschrieben.

Aber wenn das so gelingt, wie bekommt denn der Client dann das Ereignis mit?

Notfalls würde ich die Clients (vorerst) zyklisch beim Server einen Zeitstempel der letzten Änderung abfragen lassen, aber so richtig schön ist das ja nicht...

[Zacherl]

Die Indy Komponenten sind alle blocking, das bedeutet sie reagieren nicht (wie z.b. die standard Socket Komponenten) auf bestimmte Window Messages, sondern müssen selbst für eingehende Daten lauschen.

Normalerweise geht man hier so vor, dass man pro Client einen Thread erstellt, welcher die Datenempfangsschleife implementiert. Prinzipiell kann das bei den Indys ein einfaches ReadLn() sein. Der Call blockiert solange, bis tatsächlich Daten anliegen.