Porting old Delphi2007 application using TServerSocket....

[BosseB]

Turns out I was close then using IOHandler.ReadLn(ETX), I did not wait for the STX to arrive, though.
Can't I wait for ETX instead so I know a complete message is available?

Yes, which is why I said the call to WaitFor(STX) is optional.  But since the protocol dictates that every message begins with STX, it doesn't hurt to validate that actually happens.  If every message is well-formed, as it should be for compliant clients, then the WaitFor() will be redundant.  But for non-compliant clients, or corrupted communications, waiting for STX before then waiting for ETX can help with recovery efforts.

I will try that out and see what happens.

Regarding the OnExecute call, is there some minimum time between the invocations?

No.  As soon as the OnExecute handler exits, it is called again immediately.

OK, so then if there is a WaitFor() in the code then it will stay here most of the time?
Even when the timeout hits it will come back here, right (since it is immediately re-called).
Is this call coming from a separate thread so it won't slow down the rest of the application, for example if there are two clients connected...

Is there a way to check how much data there is in queue before actually trying to read it?

The IOHandler.InputBuffer has a Size property.  This indicates how many bytes Indy has already read from the socket and stored in the InputBuffer's memory buffer (which the rest of the IOHandler's reading methods then extract their bytes from).

OK, then I will probably have a first check if there are at least 3 bytes in there (STX-Databyte-ETX) before going on. It would make the OnExecute exit much quicker most of the times, because I would think client data will not arrive very often, after all it will be triggered by a human clicking some action button in the client application.

If you want to check how many bytes are in the socket's internal buffer, you will have to access the underlying platform's socket API directly, such as using ioctlsocket(FIONBIO) on Windows.  You can get the underlying platform socket handle from the AContext.Binding.Handle property.

This is probably not necessary if I check for 3 or more bytes here...

I think it will not be a big problem but I have noted when testing that there seems to be a lag in the handling, for example when I connect the client it connects immediately as witnessed by activity in the OnConnect, where I print out the connection message on the console, yet it takes several seconds or more before the client app shows the login dialog to the user in preparation for actually logging in. It is raised as soon as the client discovers the connection succeeded.

Same when sending the login request it is immediately shown in the console but the client takes some time to discover that a valid login has been accepted even though my test code sends the reply immediately after the console has been written to.

Did you have that same problem when using TServerSocket?  It sounds like maybe the client's logic has a bug or design flaw in it, where it is not handling socket activity in a timely manner.  Maye a buggy socket handler, or a laggy message queue, or something like that.  I can't really help you with this without seeing the client's code.

Could well be, the client app was created some 16 years ago (for WinXP) and is a low-usage app, basically just for casual monitoring of activity and possibly modifying some configuration items.
So it is not a big deal.
The server's main task is managing recurring measurement operations on a remote site so mostly it is on its own.

Oh, regarding the Windows10 issue:
It is a problem with hardware compatibility. We have designed an interface box which attaches by USB to the server computer and now Windows has decided that the driver that has worked fine for many years is no longer allowed on the system! It is an FTDI USB-RS232 chip we integrated on the board.
So we face two ways of resolving this:
1) Redesign the hardware, meaning that all customers need to be updated if the server computer updates its Windows.
2) Port the server to run on Linux, which is what I am occupied with. Then we can replace the Windows PC server with a small Raspberry Pi box and keep all of the proprietary hardware we have used earlier.
The FTDI driver on Linux works just fine for all of the converters I have tested...