Delphi/Indy. Long delay in procedure TIdStackWindows.Connect

Question

My app is hanging in the call to procedure TIdStackWindows.Connect. When the TCP/IP address exists there is no problem, but if it doesn't, I get the hang. The IP address is a literal- there is no DNS lookup involved. I was expecting the connection attempt to fail after the timeout (TCPClient.ConnectTimeout) I have set of 1 second but the app hangs for up to 30 seconds on this call (the call from my app isn't threaded. I intend to move the TCP connection to a thread, but the long connect timeout will still be an issue).

If I pause execution in the Delphi IDE when the app is unresponsive, I an positioned at:

ntdll.KiUserApcDispatcher:
7C90E450 8D7C2410         lea edi,[esp+$10]

I then F8 a couple of times until I see a stack frame. I am then at:

IdStack.TIdStack.RaiseSocketError(10038)
IdStack.TIdStack.RaiseLastSocketError
IdStack.TIdStack.CheckForSocketError(-1)
IdStackWindows.TIdStackWindows.Connect(912,'10.8.2.170',5001,Id_IPv4)
IdSocketHandle.TIdSocketHandle.Connect
IdIOHandlerStack.TIdConnectThread.Execute
:00451fc1 HookedTThreadExecute + $2D
Classes.ThreadProc($254B910)
System.ThreadWrapper($5456CB0)
:00451ea3 CallThreadProcSafe + $F
:00451f10 ThreadExceptFrame + $3C
:7c80b729 ; C:\WINDOWS\system32\kernel32.dll

I note after a bit of poking around that this topic has received a bit of traffic. The common answer seems to be "put it in a thread". I intend to, but the long timeout will still be problematic. Why does the connect timeout not work? I'm using Indy 10.5.5 and Delphi 2006 - if I upgrade to the latest build of Indy will there be much migration involved?

Answer 1

Blocking sockets have no concept of a connect timeout at the API layer, so Indy's ConnectTimeout is a manually implemented timeout. Indy calls TIdStack.Connect() in an internal worker thread while TIdTCPClient.Connect() runs a sleep loop that waits for that thread to terminate. If the loop detects the ConnectTimeout period has elapsed, it closes the socket, which is supposed to cause the blocked TIdStack.Connect() to exit immediately, but that is not a guarantee. There is OS overhead in creating and terminating a thread as well. It should definitely not take 30 seconds to react to a 1 second timeout, but on the other hand 1 second is usually too small. It is possible that the thread will not even begin running within 1 second. You should typically set the ConnectTimeout to 5-10 seconds at a minimum to give the OS enough time to do its work.