Indy TCP Client data not received

2
votes

Update Seems like this issue is not as close related to Indy as I thought and more a topic on multi threading. I'll keep the question open as I am not 100% convinced.

I have a working application which is exchanging ascii strings with communication partners using Indy TCP client. The communication flow looks like this:

  1. [Indy Level] Sender sends string
  2. [TCP Level] Wireshark tells that this packet was delivered to the recipient
  3. [TCP Level] The recipient sends a TCP ACK to confirm this packet
  4. [Indy Level] The IOHandler.ReadLn method of recipient returns the data
  5. [Indy Level] Via writeLn() a logical Acknowledgement is sent to the original sender

Recently I noticed that there a hickups in that communication, after fiddeling with wireshark I got the following picture:

  1. [Indy Level] Sender sends string
  2. [TCP Level] Wireshark tells that this packet was delivered to the recipient
  3. [TCP Level] The recipient sends a TCP ACK to confirm this packet
  4. [Indy Level] The IOHandler.ReadLn method of recipient does not return any data
  5. Nothing to do as no data is available for recipient

After some timeout the sender send the orginal message again because there was no logical Acknowledgment from the recipient.

So my question is: If wireshark tells me that the underlying TCP mechanics did their work, how is it possible that the Indy Client has no data available?

Regards, Attix

1
socketsnetworkingtcpwiresharkindy
Please provide a Minimal, Complete, and Verifiable example. What you have described should only happen if either 1) your sender is not sending a line terminator to being with to satisfy ReadLn(), or 2) more likely, you have multiple threads reading from the same Indy IOHandler at the same time and are corrupting the content of the IOHandler.InputBuffer such that ReadLn() cannot find the line terminator correctly. DO NOT read from the same IOHandler in multiple threads at the same time. That includes calling Connected, which performs an internal read. - Remy Lebeau
@RemyLebeau you are awesome! Indeed there was a call of Connected outside the reading thread which messed up the InputBuffer. Removing this call fixed this issue. I'll do some more test and will mark this as solved with an appropriate update of my post. - Attix

1 Answers

1
votes

[SOLVED] The hint Remy provided was correct. I was calling Connected of the TCP Client outside its reading thread which messed up the input buffer and caused the non appearing message symptom.

Removing that (unnecessary) check solved this.