TCP socket continuously returns EAGAIN

Question

In my testing, I found that when i send packets of bytes 1000-5000 bytes from my sender, they get assembled/bundled at receiver with sizes 8000-14000 bytes. I checked the wireshark capture to confirm this.

I have 2 questions:
1) Who bundles these packets in between, receiver receives these and I use select() to detect data and call recvmsg api ?.

2) When packets of lengths increase at receiver, I implemented partial reception so that 'recvmsg' returns partial data also. In this case after some time, recvmsg call returns EAGAIN with 0 bytes. The connection with peer is still up, because peer is still sending packets, why is recvmsg call returing error with EAGAIN ?.

Comments

Is it possible to share the code here.

I also agree with Salil about root cause of the problem.

Answer 1

Not sure what you are trying to do but assuming that it is something to do with the delimiter or in short you have to design you application-level code so that it's easy to split that stream into messages. Common approaches are to use a length prefix or a message delimiter or something like that.

That was my guess based on what you have listed down as I could not see the logic but let me share my experience long back with some assignment.

We used to send the length of the message say in 3rd and 4th byte where as 1st and 2nd byte was the message type. While receiving we used to peek four bytes and check the length as the first step then read the complete packet in second step. Try something similar.

If my guess of the problem is not correct then share your code that may be helpful.

Comments

Thanks for your quick response. I apologize for not phrasing the question appropriately.

Actually the problem is we have 2 procs which support Fault Tolerance. One proc is Active & the other is stand-by. When there is any switchover, we observe the reported issue when there is larget data to be swapped beteween these 2 procs. This is observed only at high load.
We could see that the proc1 (Sender) is sending the data properly and also proc2 (receiver) is able to receive properly when load is less. But at high load (larget bytes comein), the recvmsg( ) calls returns 0 bytes.
But the socket buffer has still data left. We use ioctl to trace data in recv buffer and call recvmsg for which it returns EAGAIN.
Is there any possibility that if mesg size in recv buffer exceeds some limit and then this issue comes ?

---

Less likely that it exceeds some limit.

But I have seen weird issues with TCP, remember one thing  TCP is not message based its stream based.

However I could not understand the last two lines and very difficult to comment anything without seeing the code...I am also assuming with the problem statement that you are using the select + no-blocking socket.

---

We use select( ) + no-blocking socket.
Please find below for the scenario:
We have data available on the receiver socket, as we use a ioctl call to check the data length in the recv socket buffer. Select returns asking to read from this socket and then when we read it using recvmsg( ), it returns EAGAIN. As earlier mentioned, it works for small data packets, but when the length at recv buffer increases some limit, we face this issue.

---

We have data available on the receiver socket, as we use a ioctl call to check the data length in the recv socket buffer -

Check if you can do something about this. Can message itself contains the length of the packet to be read.

---

@Deepak: any update, if you found the fix please post the solution as it may be helpful for others.

---

No. We are reproducing the scenario to identify the root cause.Once we are able to fix the issue, I would post the solution here.

---

Hi Salil,
We have fixed the problem.
The issue was with typecasting of a parameter which was holding the length of the pending bytes to be read. In our application, we had added a check to restrict max bytes to be read at one time. If it crosses, then we were setting this length parameter to pending bytes to be read. Due to mismatch in typecasting (Short int instead of int), we were observing connection to be closed as the parameter holding pending bytes was getting set -ve value.
Changing typecast resolved this issue.

Thanks for your support.

Regards,
Deepak D