Ich muss doch nochmal nachfragen weil die Aussage von QuickAndDirty mir ein wenig komisch vorkam.
Liefern alle
Indy nur einen Datenstrom oder hast du nur
TCP/
IP Client und Server gemeint?
Hintergrund:
Ich habe für ein ganz anderes Projekt erfolgreich UDP im Einsatz und dort kann ich mit folgenden Befehl
IdUDPClient.SendBuffer(IdUDPClient.Host, IdUDPClient.Port, outMsg);
direkt Telegramme von 32000 Byte verschicken und beim Empfänger kommt auch nur 1x das OnUDPRead Event mit 32000 Byte an.
Klar, dass Betriebssystem zerlegt die Telegramme noch aber fügt sie beim Empfang auch wieder zusammen, sodass ich nur 1x das OnUDPRead Event erhalte.
Das habe ich soeben getestet und ist auch wirklich so.
Bei TCPIP ist es allerdings so, dass ich vom Server (Windows Anwendung) ein 8000 Byte langes Telegramm abschicke und mit der in Post 1 beschrieben Lesefunktion, die Daten abrufe. Allerdings wird das Event mehrmals getriggert, nicht nur 1x. Je nach dem wie mir die
Indy die Telegramme aufteilen. Ich hätte eigentlich gerne die gleiche Funktionalität wie bei UDP.
Dort gibt es auch beim Server die Eigenschaft BufferSize, die habe ich auch entsprechend gesetzt. Bei TCPIP gibt es diese nicht. Gibt es einen anderen Weg bei TCPIP, dass ich nur 1x Telegramm abschicke und nur 1x Empfangsevent erhalte, so wie bei UDP?
TIDTCPClient, TIDTCPServer, TIDUDPClient und TIDUDPServer liefern einfach nur einen Datenstrom.
Die
SOAP Clients und
Soap Server von
INDY liefern naturlich SoapRequest und SoapResponses...
http clients und http server liefern HttpRequests und HttpResponses.
Ich weiß nicht genau wann OnUDPRead gefeuert wird, aber ich vermute mal das passiert wenn der Readbuffer eine bestimmte zeit nicht mehr gefüllt wurde oder Voll ist. So würde ich es machen. Da UDP eine paketlänge codiert kann es natürlch sein, dass deine Message genau ein einziges OnUDPRead event auslöst sobald ein Paket vollständig gelesen wurde...aber es muss nicht zwinged so sein das eine Payload nur in einem einzigen UDP paket gesendet wird!
Bei
TCP wird die länge/größe der Pakete dynamisch an die Qualität der Leitung angepasst.
Ich würde mich in keinem Fall auf Mechanismen der darunter liegenden Protkolle verlassen!