5

In my application, I found my send() call on a TCP connection is blocked occasionally. And whenever this happens, the Recv-Q of the TCP connection is very high from netstat output:

tcp   314238      0 10.8.8.21:47302         10.8.8.11:5672          ESTABLISHED
tcp   313276      0 10.8.8.21:47294         10.8.8.11:5672          ESTABLISHED

What could possibly cause the recv buffer of a TCP connection to be filled up? And how does it cause my send() call to hang indefinitely?

p.s. This may or may not be relevant, this TCP connection is between my app and a RabbitMQ server.

NeoWang
  • 17,361
  • 24
  • 78
  • 126
  • Recv buffer would fill up when your app is not reading from the socket for a while. But it shouldn't affect sending from your end. Can you check what's going on on the opposite side? BTW here are some helpful tips and scenarios of Recv-Q and Send-Q having non-zero values: http://stackoverflow.com/questions/36466744/use-of-recv-q-and-send-q – Oleg Kuralenko Aug 12 '16 at 14:18
  • @ffeast Of course it affects sending. TCP will close the receive window, whereupon the sender must stop sending. RFC 793. – user207421 Aug 18 '17 at 09:51

2 Answers2

3

What could possibly cause the recv buffer of a TCP connection to be filled up?

The receiver receiving slower than the sender is sending.

And how does it cause my send() call to hang indefinitely?

When the receive buffer fills, TCP closes the receive window, which inhibits the sender from sending. The sender can't send more data than the receiving TCP advertises in its receive window.

user207421
  • 305,947
  • 44
  • 307
  • 483
-1

What could possibly cause the recv buffer of a TCP connection to be filled up? And how does it cause my send() call to hang indefinitely?

Provided that you have the same thread calling send() and recv(), when it is blocked in the send() call, it naturally doesn't get to call recv() and the received data must be queued. So, it's not the filling of the recv buffer to cause send() to hang - it's the other way round.

Armali
  • 18,255
  • 14
  • 57
  • 171
  • There is nothing in the OP about the send and receive happening in the same process, let alone the same thread. Final sentence is completely incorrect: the send buffer being full cannot cause `recv()` to hang. – user207421 Aug 18 '17 at 09:52
  • @EJP - There is nothing in the OP about the send and receive happening in different processes. Moreover, I did explicitly qualify my answer for the case of the same thread of execution with _Provided that …_ And the case I described wasn't the send buffer being full causing `recv()` to hang, but the hanging of `send()` causing `recv()` to not be called. Perhaps you care to re-read my answer with this explanation in mind. – Armali Aug 18 '17 at 10:43