Wsrtjtyk

I have a problem regarding the ConnectTimeout from Indy 10's TIdTCPClient.

When setting the ConnectTimeout higher than 125ms the Connect() procedure will block the current thread for 125ms. If it is less than 125ms, it will block for the given time (e.g. it blocks for 30ms if the timeout is set to 30ms). In both cases, the connection is stable and I can transmit and receive data.

Why is the TIdTCPClient behaving like that?

IMHO the Connect() procedure should exit directly after the connection is successfully made and only block the full duration of the timeout if no connection can be opened.

Here's my code for monitoring the duration of the Connect() procedure.

The timer for calling TimerConnectTimer is set to 250ms.

I am using Lazarus v1.6.4 and Indy 10 under Windows 7 Professional.

procedure TForm1.FormCreate(Sender: TObject);

begin

  timer := TEpikTimer.create(self);

  timer.Clear;

end;



procedure TForm1.TimerConnectTimer(Sender: TObject);

begin

  timer.Start;

  client := TIdTCPClient.create();

  logTime(0);

  // Tested with values between 10ms and 1000ms

  client.ConnectTimeout := SpinEdit1.Value;

  try

    logTime(1);

    // choose ip and port for a running server

    client.connect('192.168.2.51', 9912);

    logTime(2);

  except



  end;



  logTime(3);



  try

    client.Disconnect();

    FreeAndNil(client);

  except



  end;



  logTime(4);

  timer.Clear;

end;



procedure TForm1.logTime(ch: integer);

begin

  StringGrid1.Cells[0, ch] := FormatFloat('0.00', timer.Elapsed*1000);

end;

When setting the ConnectTimeout higher than 125ms the Connect() procedure will block the current thread for 125ms. If it is less than 125ms, it will block for the given time (e.g. it blocks for 30ms if the timeout is set to 30ms). In both cases, the connection is stable and I can transmit and receive data.

Why is the TIdTCPClient behaving like that?

That is hard to answer without knowing which version of Indy 10 you are using exactly, as the implementation of ConnectTimeout has changed over the years. But, in general:

If ConnectTimeout is set to IdTimeoutDefault or 0, IdTimeoutInfinite is used instead.

If Connect() is called in the main UI thread, TIdAntiFreeze is being used, and an infinite timeout is used, a hard-coded 2min timeout is used instead.

If any timeout is used, Connect() spawns a worker thread to connect the socket to the server, and then waits up to the timeout for the thread to terminate. If the timeout elapses before the thread terminates, Indy closes the socket and terminates the thread.

Assuming you are using a fairly up-to-date version of Indy 10 (at least SVN revision 5382 on Dec 14 2016, or later), and are not using TIdAntiFreeze, then on Windows only, the wait should exit immediately when the worker thread terminates, as Indy makes a single call to WaitForSingleObject() on the thread for the full timeout and exits as soon as WFSO exits.

If you are using TIdAntiFreeze, or are using Indy on a non-Windows platform, or are using a version of Indy 10 prior to SVN rev 5382, the wait calls IndySleep() (and if needed, TIdAntiFreeze.DoProcess()) in a loop at fixed intervals (125ms, or TIdAntiFreeze.IdleTimeOut, whichever is smaller) until the timeout is exceeded or the thread has terminated. In which case, there may be a slight delay before Connect() exits, as each sleep cycle has to complete before Connect() can check if the thread has terminated, and do so for every sleep interval within the overall connect timeout.

IMHO the Connect() procedure should exit directly after the connection is successfully made and only block the full duration of the timeout if no connection can be opened.

That is exactly what it currently does, on Windows at least. If the connection is successful, the thread terminates, and Connect() exits immediately (even if TIdAntiFreeze is used). The current sleep cycle is ended by the thread terminating itself. That is not the case on non-Windows platforms (for now, may be addressed in a future version).

Note that all of the above only applies when a timeout is used. If no timeout is used, no worker thread is used, either. Connect() simply connects the socket directly and lets the attempt block the calling thread until finished, whether successful or not.

Here's my code for monitoring the duration of the Connect() procedure.

I would suggest something more like this instead:

procedure TForm1.TimerConnectTimer(Sender: TObject);

begin

  try

    timer.Start;

    try

      logTime(0);



      client := TIdTCPClient.create();

      try

        // choose ip and port for a running server

        client.Host := '192.168.2.51';

        client.Post := 9912;



        // Tested with values between 10ms and 1000ms

        client.ConnectTimeout := SpinEdit1.Value;



        logTime(1);

        client.Connect();

        logTime(2);

        client.Disconnect();

        logTime(3);



      finally

        FreeAndNil(client);

      end;



      logTime(4);

    finally

      timer.Clear;

    end;

  except

  end;

end;