Ok, after further investigation, I found what has changed. My code is using TROSuperTCPChannel
and has not changed. However, that very class moved from using a TROIndyClientSuperConnection
to a TROClientSuperTcpConnection
the latter being based on your own implementation of the communication channels, thus not depending on third party libraries.
I can understand the rationale behind this as you control all aspects of the code. However, there is a slight difference in your implementation, when it comes to the isTimeoutError: Boolean
override.
That method is used inside TROBaseSuperChannelWorker.DoExecute
like this:
if not FBaseSuperConnection.isTimeoutError then begin
{$IFDEF uROBaseSCHelpers_DEBUG_ARC}LogARC('--> TryReadByte=False. before Disconnect');try{$ENDIF}
Disconnect;
{$IFDEF uROBaseSCHelpers_DEBUG_ARC}finally LogARC('--> TryReadByte=False. before Disconnect'); end;{$ENDIF}
Break; // disconnected
end;
So, if isTimeoutError
returns true, the failure to read one byte is ignored and the connection is kept open.
In the Indy case, the isTimeoutError
method returns the value of FTimeOutError
which in my real case above is set to True
inside TROIndySuperConnection.TryReadByte
because _ReadFromStack
returned -1
With your own implementation though, the isTimeoutError
method returns False
because fConnection.LastError
is not ETIMEDOUT
. And indeed, inside TROSocket.CanRead
there is no code that takes into account the fact that if RO_Select
returns 0, then it’s because the timeout was reached. If I change the code to now read like this:
x := RO_Select(fSocket + 1, @lFDSet, nil, nil, ptv);
if x = 0 then
fLastError := ETIMEDOUT
else
SockCheck(x);
Then the isTimeoutError
method returns True and the connection is not closed, bringing the situation back to what it was with version 9.4
So, the real error lies inside TROSocket.CanRead
but it also comes from the fact that TROSuperTCPChannel
was changed to use another implementation.
And that does not remove the questioning about the computed timeout value, which to me, does not make sense in network terms.