@mjustin: Kann man sich die Endlosschleifen irgendwie ersparen und das ganze Event- oder Message-basiert ablaufen lassen?
TCP ist streamorientiert, man erfährt nur dann von der Existenz neuer Daten, wenn man eine Leseoperation auf dem Socket ausführt. Die asynchrone TClientSocket Komponente ist zwar "eventorientiert" in der Anwendung, aber intern nutzt sie die Windows Messageloop und prüft in ihr den Socket.
Wenn der Client aber die Kommunikation mit einem Request startet und der Server dann eine Response zurücksendet, braucht man diese Loop nicht. Ich hatte aufgrund der ersten Beschreibung ("von einem Server an einen Client übertragen") angenommen, dass der Server die Dateiübertragung startet, wenn eine Datei zu senden ist. Das wäre der Fall aus meinem Beispielcode.
Für Request/Response ist HTTP mit
Indy passend, der Client muss keine Schleife verwenden um den Socket zu überwachen, sondern nur IdHTTP.Get ausführen, das dann die Daten zurückliefert.
Sowohl Client als auch Server haben auch genug anders zu tun.
Ein Thread, in dem der Socket in größeren Zeitabständen mittels z.B. CheckForDataOnSource(50) geprüft wird, belastet das System nicht spürbar.
Hat
Indy Vorteile gegenüber TTCPClient/Server?
Remy Lebeau
schrieb zu den TTcpServer/TTcpClient Komponenten:
Zitat:
They are also very poorly implemented, and not very useful,
IMHO. They are
not
VCL components to begin with, they are
CLX components from the Kylix
days. Borland tried to write its own cross-platform socket components, but
narrowed everything down to a VERY bare-bones least-common-denominator
implementation between Windows and Linux that requires ALOT of manual work
in user code. As such, you are better off either re-installing the old
VCL
sockets components, or switch to
Indy's TIdTCPClient and TIdTCPServer
components (
Indy has been bundled with Delphi since D6) or other third-party
library (like ICS or Synapse).