Indy10 TCP Client Readln hangs

[Attix22]

Hi all

I'm using Indy10 TCP Client to communicate with a communication partner. 
To enable reading and writing at the same time I'm using IOHandler.ReadLn(Self.FETX, Self.FEncoding); inside the Execute of a TThread to read data.
And sending is done outside this Thread by the owner of the thread.

Problem is I sometimes (like every 5 - 10 Minutes) experience a hang on the IOHandler.ReadLn call which can last till I send data over the same TCPClient Instance.

Now I'm asking myself if there is a fundamental flaw in using a TCPClient like this?

Code:

procedure TReadingThread.Execute;
begin
 while not (Terminated) do
 begin
   try

      //Logged time here as start
     Self.FData := Self.FClient.IOHandler.ReadLn(Self.FETX,1000ms, -1, Self.FEncoding);
      //Logged time here as end
      //In case of "hang" this can take an infinite amount of time

     if (Self.FData <> '') and Assigned(Self.FOnData) then
     begin
       Synchronize(DataReceived);
     end;
   except
     on EIdException do
     begin
       ;
     end;
   end;
 Sleep(10);
 end;
end;

Code:

//Outside of TReadingThread, but same TCPClient Instance
Self.FTCPClient.IOHandler.WriteBufferOpen;
Self.FTCPClient.IOHandler.Write(Self.STX + Self.FSendDataBuffer + Self.ETX);
Self.FTCPClient.IOHandler.WriteBufferFlush;
Self.FTCPClient.IOHandler.WriteBufferClose;

[rlebeau]

Problem is I sometimes (like every 5 - 10 Minutes) experience a hang on the IOHandler.ReadLn call which can last till I send data over the same TCPClient Instance.

Sending and receiving are completely independent operations. ReadLn() will freeze until it receives what it is expecting (or until it times out). Sending data to the server will not fix that, unless that data triggers the server to send what ReadLn() is expecting.

Now I'm asking myself if there is a fundamental flaw in using a TCPClient like this?

In of itself, no. But what does the rest of your TIdTCPClient code look like? For instance, are you ever calling Connected() on the client? That performs a read operation, so it could corrupt communications by receiving bytes that ReadLn() is waiting for, putting them in the InputBuffer in the wrong order. Just a thought.

[Attix22]

Thanks for your answer.

Indeed I was calling .Connected on the client in quite a regular basis.
Background for this was to detect if the communication partner has gone offline without safely closing the connection first.

I disabled this and the described behavior disappeared, however now I need to check how to safely detected if the communication partner is offline.
Maybe in the except of my reading thread?

[kudzu]

Yes, the try..except is where you should catch premature disconnections.

[Attix22]

Thanks all, with handling unexpected connection issues in the except block the problem appears to be solved.