Hi,
ich würde mal sagen, eine permanente Verbindung macht (insbesondere bei
TCP/
IP) wenig Sinn.
-> grund? ich denke das ist falsch. jede
tcp app versucht, die verbindung so lang wie möglich dauerhaft zu halten
An sich sollte man möglichst Ereignisorientiert arbeiten.
-> richtig
Bei zustandslosen Protokollen kann es schwer werden eine Verbindung permanent zu halten (geht einfach gar nicht)
-> seit wann ist
tcp zustandslos? es gibt nicht umsonst diverse timeouts und fehlerkorrekturen im protocol
. Natürlich kannst du beliebig lange readln machen, aber es macht (
imho) wenig Sinn.
-> auf clientseite kannste das mit den indys garnicht anderst machen, wenn du auf messages reagieren willst, die vom server kommen, die du aber nicht voraus sehen kannst (anderst wäre es, wenn du eine anfrage an den server schickst und der dir EINE antwort gibt. aber dieser fall ist ja in dieser konstellation nicht vorraus zu sehen )
Damit wird ein solcher Rechner immens viel Zeit (alles was frei ist) damit verbringen auf eine Nachricht zu warten. Da du eher nicht mit ein paar Mhz neue Nachrichten verschickst (geschweige denn mit ein paar GHz), verschwendest du damit eigentlich nur Ressourcen.
-> ganz falsch. bei den indys wartet readln solange bis das timeout einsetzt an dieser codestelle OHNE ressourcen zu verbrauchen. in einer endlosschleife würde das super hinhauen.
Natürlich muss jeder Server (auch Serversocket) auf eine Anfrage reagieren können, in Delphi gibt es dieses Ereignis für dich schon gekapselt.
-> on execute bei den indys
-> readln bei dem client (wahlweise in einer endlos schleife in einem thread)
Wenn du nun ein Programm schreibst, dass als Server dient, der die Rundnachrichten verschickt, kannst du natürlich einfach an alle eingetragenen Empfänger etwas verschicken. Das heißt, ein Server kann sowohl empfangen als auch verschicken. Bietet sich doch irgendwie an, den auch gleich für die "Clients" zu benutzen. Wenn du auch dort Server verwendest, kannst du also leicht auf Nachrichten vom eigentlichen Server reagieren und diesem auch Antworten und das ganze ohne jegliche Art von polling (schont die CPU immens).
-> das verstehe ich jetzt nicht, wie du mit einem server auf einen server connecten willst o_O
Natürlich kann man auch in eine gewissen Interval pollen (mittels Readln), aber dann ist dann die Intervalgrenze eine Schwierigkeit. Wartest du zu lange, so wirst erst verzögert auf ein Ereignis reagieren, ist das Interval zu kurz, kommt es sehr häufig zu unnötigen Aufrufen, optimal ist es natürlich einfach auf ein Ereignis zu reagieren.
-> endlosschleife mit readln ohne verzögerungszeiten = optimal falls nicht ein application layer protocol verwendet wird
Was Threading angeht, da hat Luckie ein Tutorial für.
-> alles was im onExecute vom Server ausgeführt wird, ist schon in einem thread von den indys
d.h. man muss serverseitig nicht einen einzigen thread erstellen - das ist schon in den indys aktiv
man muss allerdings aufpassen und threadsafe in den ereignissen programmieren.
clientseitig bräuchstest evtl maximal einen thread, der die nachrichten vom server empfängt.
ich empfehle die
indy demos zu studieren (tcpserver/client) da ist alles was ich gelabert habe als code einzusehen!