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