Why might an EventMachine outbound data buffer stop sending and just fill up forever (while other connections can still send)

Question

I have an EventMachine server sending TCP data down to a Mac client (via GCDAsyncSocket). It always works flawlessly for a while, but inevitably the server suddenly stops sending data on a connection-by-connection basis. The connection is still maintained, and the server still receives data from the client, but it doesn't go the other way.

When this happens, I've discovered via connection#get_outbound_data_size that the connection send buffer is filling up infinitely (via #send_data) and not being sent to the client.

Are there specific (and hopefully fixable) reasons why this might occur? The reactor keeps humming along, and other active connections to the server continue working fine (though they sometimes fall into buffer hell as well).

Answer 1

I see one reason at least: when the remote client no longer read data from its side of the TCP connection (with a recv() call or whatever).

Then, the scenario is: the receiving TCP buffer on the client side becomes full. And the OS can no longer accepts TCP pacquets from its peer, since it cannot store them queue them. As a consequence, the sending TCP buffer on the server side becomes full too as your application continue to send paquets on the socket! Soon your server is no longer able to write into the socket since the send() system call will :

1. blocks undefinitively. (waiting for buffer to empty enough for the new paquet)
2. ot returns with an EWOULDBLOCK error. (if you configured your socket as a non-blocking one)

I usually met that kind of use case in TEST environment when I put a breakpoint in my code on the client side.

Answer 2

There was a patch was applied to GCDAsyncSocket on March 23 that prevents the reads from stopping. Did this patch solve your problem?