@mterwoord In the OnExecute event handler, I only call AContext.Connection.IOHandler.ReadBytes() to read a byte from the client. After one or more connections have been established, those connections are terminated and TCP server socket are closed very quickly on Windows platform. if the Active property is set to False. However the main thread is frozen for al long time on Linux if the same operation is executed.
well, that is, last 15 years..
@mercedwang Indy uses blocking sockets, and infinite timeouts by default. When the server is deactivating, it closes all of its active sockets. Closing a socket in one thread is not guaranteed to unblock any blocked socket operations in other threads. It does on Windows, but it may not on all platforms. Try setting the
IOHandler.ReadTimeout property to a short timeout and then handle any EIdReadTimedOut errors that occur. Or, before calling IOHandler.ReadBytes() (why not ReadByte()?), you can check IOHandler.InputBufferIsEmptyand if True then call IOHandler.CheckForDataOnSource() with a timeout, and skip ReadByte(s) until the IOHandler.InputBuffer actually has something available to read.
procedure ReadBytes(IOHandler: TIdIOHandler; var VBuffer: TIdBytes; AByteCount: Integer; AAppend: Boolean = True);
const
CheckInterval = 5000;
var
InitialTimeout, Timeout: Integer;
NewDataAvail: Boolean;
begin
Assert(Assigned(IOHandler.InputBuffer));
InitialTimeout := IfThen(IOHandler.ReadTimeout >= 0, IOHandler.ReadTimeout, MaxInt);
while IOHandler.InputBuffer.Size < AByteCount do begin
Timeout := InitialTimeout;
repeat
if Timeout <= 0 then raise EIdReadTimeout.Create(RSReadTimeout);
NewDataAvail := IOHandler.CheckForDataOnSource(Min(CheckInterval, Timeout));
IOHandler.CheckForDisconnect(True, True);
Dec(Timeout, CheckInterval);
until NewDataAvail;
end;
IOHandler.InputBuffer.ExtractToBytes(VBuffer, AByteCount, AAppend);
end;
const
CheckInterval = 5000;
var
InitialTimeout, Timeout: Integer;
NewDataAvail: Boolean;
begin
Assert(Assigned(IOHandler.InputBuffer));
InitialTimeout := IfThen(IOHandler.ReadTimeout >= 0, IOHandler.ReadTimeout, MaxInt);
while IOHandler.InputBuffer.Size < AByteCount do begin
Timeout := InitialTimeout;
repeat
if Timeout <= 0 then raise EIdReadTimeout.Create(RSReadTimeout);
NewDataAvail := IOHandler.CheckForDataOnSource(Min(CheckInterval, Timeout));
IOHandler.CheckForDisconnect(True, True);
Dec(Timeout, CheckInterval);
until NewDataAvail;
end;
IOHandler.InputBuffer.ExtractToBytes(VBuffer, AByteCount, AAppend);
end;
Some users have reported that some linux builds are not doing this, but its incorrect behaviour and can break lots of apps.
It seems to be a recurring problem on Linux from what I can see.
@mercedwang I don't see how your ReadBytes() implementation is much better than the current TIdIOHandler.ReadBytes() implementation. If you set a non-inifinite positive ReadTimeout, an EIdReadTimeout should already be getting raised by TIdIOHandler.ReadBytes() if no data arrives in the specified time period. Otherwise it blocks indefinately waiting for data (well, Indy actually blocks indefinately, yours unblocks after 24 days). All you are really doing is creating a similar loop to the one that already exists in TIdIOHandler.ReadFromSource(), except that you are forcing the loop to wake up every 5 seconds, whereas Indy lets the OS decide when to wake up. As for the Bindings collection, how much more flexible do you want it to be? It already allow you to bind IPv4 and IPv6 sockets concurrently on the same port, if that is supported by the OS. TIdCustomTCPServer.Startup() simply adds default listening sockets if you don't specify your own bindings beforehand. If you want more control, just setup the Bindings collection yourself how you want before activating the server
@mercedwang As Chad stated, closing a socket in one thread should be aborting blocked socket operations in other threads. There should be no need for such a 5-sec loop during shutdown. If the socket is waiting for bytes, the closure will abort the wait with an error, causing the reading thread to terminate (unless it doesn't handle the error correctly). As for the Bindings, read the comment above Startup(): "Linux/Unix does not allow an IPv4 socket and an IPv6 socket to listen on the same port at the same time! Windows does not have that problem..." At the time that comment was written, that behavior was tested and verified as not working. Has that changed? It certainly doesn't work on Android, which runs on top of Linux. Listening on the same port with both IPv4 and IPv6 usually requires a dual-stack socket, which Indy doesn't support yet (IndySockets/Indy#29). However, Linux has a config option (
/proc/sys/net/ipv6/bindv6only) that can automatically bind an IPv4 port when binding an IPv6 port without needing separate sockets or the IPV6_V6ONLY option enabled explicitly in code.
@mercedwang Embarcadero uses Indy in PAServer. In fact, it was Embarcadero that first alerted me to the problem of not being able to bind separate IPv4 and IPv6 sockets to the same port on Linux (when they were working on adding Linux to Delphi), leading to the current implementation in Indy to disable that logic. But like I said, Linux has an option to auto-bind an IPv4 port when binding an IPv6 port, so you might be seeing that behavior at play
In modern Linux distros it apears so - but there are some work around we can apply into the code. Linux appears to have gained dementia and like typical C++ devs they are now apparently calling it a feature rather than a bug that it is - the original socket specs AFAIR are very clear on this and I know other POSIX and *nix distros are.
Ill lok for the ones I read before, but it loks like not just close but shutdown ash to be called.
I cant find the thread.. but basically it seems sometime around 2006 (post Kylix..) Linux started this new behavior and its now become "accepted" although its broken according to socket specs.
I cant tell how widespread it is, but its widespread enough to be in google a lot.
"Calling shutdown() before close() seems to cause the sync Receive to return 0 bytes (i.e. EOF)."
dotnet/corefx#22564
Thats the thread I was looking for
"FYI, for sync Send the behavior is similar: without shutdown it hangs, with shutdown it returns EINVAL -- presumably because the socket is no longer valid for sending."
so probably a simple fix.
found a bug in IdSSLOpenSSL.pas
procedure DumpCert(AOut: TStrings; AX509: PX509);
->
BIO_get_mem_data( LMem, LBufPtr);
if (LLen > 0) and Assigned(LBufPtr) then begin
BIO_get_mem_data expects pointer to pointer
fixed code;
'
var
LMem: PBIO;
LLen : TIdC_INT;
LBufPtr : Pointer;
lPBPtr : Pointer;
begin
if Assigned(X509_print) then begin
LMem := BIO_new(BIO_s_mem);
try
lPBPtr := @LBufPtr;
X509_print(LMem, AX509);
LLen := BIO_get_mem_data( LMem, lPBPtr);
if (LLen > 0) and Assigned(LBufPtr) then begin'
Found a few type errors in IdSSLOpenSSLHeaders.pas:
In definitions of EVP_DecryptUpdate, EVP_DecryptFinal, EVP_DecryptFinal_ex, EVP_CipherUpdate and EVP_OpenFinal, the type of outl parameter should not be TIdC_INT, but PIdC_INT.
The next_proto_select_cb function pointer field in the definition of SSL_CTX record: Its definition should be either 'outlen : PIdAnsiChar' or 'out outlen: TIdAnsiChar' .
In definitions of EVP_DecryptUpdate, EVP_DecryptFinal, EVP_DecryptFinal_ex, EVP_CipherUpdate and EVP_OpenFinal, the type of outl parameter should not be TIdC_INT, but PIdC_INT.
The next_proto_select_cb function pointer field in the definition of SSL_CTX record: Its definition should be either 'outlen : PIdAnsiChar' or 'out outlen: TIdAnsiChar' .
@rkmanaz the original
DumpCert code is fine. Look at the declaration of BIO_get_mem_data() in IdSSLOpenSSLHeaders.pas: function BIO_get_mem_data(b : PBIO; out pp : Pointer) : TIdC_INT; In Delphi, out: Pointer is equivilent to void** in C. The original code was already passing a pointer-to-pointer. Your change is passing a pointer-to-pointer-to-pointer instead
i checked it with d7 as well as with dx
OpenSSL 1.0.2j 26 Sep 2016(VC-WIN32) compiler: cl /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_SSL2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_WEAK_SSL_CIPHERS -DOPENSSL_NO_STATIC_ENGINE
the used indy lib is somewhat older and abit adjusted to make it work under linux as well