OpenSSL and concurrent read/write

[rlebeau]

Code:

// now check for incoming packet 
if IO.InputBufferIsEmpty and not(IO.CheckForDataOnSource) then Exit;

On a side note, you should call CheckForDisconnect() after CheckForDataOnSource(), eg:

Code:

// now check for incoming packet 
if IO.InputBufferIsEmpty then
begin
  IO.CheckForDataOnSource;
  IO.CheckForDisconnect;
  if IO.InputBufferIsEmpty then Exit;
end;

All this has worked fine for many years now but there is a limit to how many connections (a few hundred) this system can support.

You are really only limited by available memory. TIdTCPServer uses 1 thread per connection, and the default thread stack size is 1-4MB, depending on your project settings. If you are running out of memory for threads, you can try lowering the stack size.

I'm having Claude Code look at this and it's telling me the Sleep command is the main bottleneck as the system will eventually spend most of its time thread switching rather than running the game.

That is true. Try using Sleep(0) instead. Alternatively, don't sleep at all. Indy uses blocking socket I/O. It will sleep the calling thread for you while reading/writing data. Or, at the very least, sleep only when there is no data present, ie when InputBufferIsEmpty is true. If there is data, you usually want the next iteration to read the next data immediately and not delay.

It initially suggested using a blocking read command with a timeout (allowing me to delete the Sleep)

Indy already does that. If you want a timeout, use the IOHandler's ReadTimeout property, or the ATimeout parameter of CheckForDataOnSource(), etc.

and then moving the outgoing packet writes to a separate worker thread.

That is certainly an option, IF your OnExecute handler only reads and never writes. If that is the case, then it can just block on ReadByte() and you won't need CheckForDataOnSource().

That all sounded good until we got into the details and now it's telling me "OpenSSL isn't safe for truly concurrent SSL read / SSL write on the same connection without locking". So is this true?

Yes. In OpenSSL, a read operation may also perform socket writes, and a write operation may also perform socket reads. This typically happens only during handshakes, session renegotiations, alerts, etc. But it does mean you need to be careful about overlapping your I/O operations. A write on one thread may read packets that another thread is waiting for.