OpenSSL and concurrent read/write

[rlebeau]

This whole thing could be simplified if there was an TEvent type of feature built into the Indy ReadTimeout system... Is something like possible?

Not consistently in a cross-platform way. You didn't say which platform(s) you are targeting.

On Windows, while there are ways to use event objects with sockets, they only work with non-blocking sockets or overlapped I/O, neither of which Indy uses.

On Nix systems, where sockets are file descriptors, you could create a separate pipe and then select() on both the pipe and socket at the same time. Then write to the pipe when needed.

What if another thread set ReadTimeout to 0 (or another small number), would that work? I could then reset ReadTimeout back to 1000 and run the next loop.

That won't work if a read is already in progress. Also, ReadTimeout=0 is treated the same as ReadTimeout=IdTimeInfinite anyway.

Going with a blocking read only works if I can safely do writes in another thread

That only works if you use plain sockets without TLS. The issue is not limited to OpenSSL specifically, but the protocol itself. Even if you disable renegotiations and such, alerts are still an issue at least, although they are only used at the end of a connection, so maybe not much of an issue.

OR break out of the read timeout when I need to. It appears that the SSL issue eliminates that first option.

And the use of blocking sockets eliminates the second.

If I delete the original Sleep(10) and do this instead:

Code:

if IO.InputBufferIsEmpty then
begin
  IO.CheckForDataOnSource;
  IO.CheckForDisconnect;
  if IO.InputBufferIsEmpty then
  begin
    Sleep(0);
    Exit;
  end;
end;

Wouldn't I still get a 100% CPU spike when nothing much else was going on?

No. But if you are worried about it, you can stick with Sleep(10) (or even Sleep(1)). The point is to sleep only when actually needed (ie, during idle activity), not on every event/packet.

I ended up just going with a blocking read with the timeout set to 100 msec and trapping the timeout exception. Then deleting the unnecessary buffer check and sleep commands. Seems to work better now.

If you stick with the buffer check, you can specify a timeout on it:

Code:

if IO.InputBufferIsEmpty then
begin
  IO.CheckForDataOnSource(10);
  IO.CheckForDisconnect;
  if IO.InputBufferIsEmpty then Exit;
end;