Porting old Delphi2007 application using TServerSocket....

[rlebeau]

The reason the data is moved into a string is that the bulk of the existing processing (which has worked OK for many years) is using the string type as a container for the data.

Then why not do the conversion to string inside the reading thread, rather than in the event handler?

And in this case all payload data are textual even transfered files because they are hex encoded before transfer (doubles the byte count but makes it possible to deal with as text)

That is just a bad waste of bandwidth.

Now it seems like I am losing some received data when the amount is large like when the content of a logfile is transferred.

You are not framing your data in any way (like with STX/ETX), so it is possible, even likely, that your event handler is dealing with partial/incomplete messages to being with. Remember, TCP is a byte stream, it has no concept of application-level messages, so you MUST frame your messages in such a way that the receiver knows where a message ends and the next message begins. I strongly suggest you deal with the framing in your reading thread, and pass only complete messages to your event handler.

Is this possibly the reason?

No. The size of the data does not matter. TCP is just a stream, it doesn't care how large each message actually is. That is for the application layer to deal with.

How can I safeguard against data loss?

Frame your data properly.

During synchronize, I thought that the read thread is paused until the event procedure returns, is that correct?

Yes. But that doesn't mean your event handler is receiving a completed data message to begin with. It may be receiving only part of a message, or even pieces of multiple messages stringed together. It is your responsibility to separate the messages properly, TCP (and Indy) won't do that for you.