Problem with TCP RST (reset) packets

[kgizdov]

Hi,

It seems that when I close a socket I get an PSH ACK (acknowledgement) packet (after the fact) that isn't handled and then the router issues a RST packet.

I'm a bit concerned this will come to be a bigger issue in prolonged usage. I tried to reproduce with python & jquery and it does not seem to be a server issue but directly related to when I use easywsclient.

I think ws->close() does not handle the ACK packet and closed prematurely. Any thoughts on how to mitigate this?

[dhbaird]

Thanks for reporting this. Which side is initiating the close? When initiating close from easywsclient, it will do this:

1. It will queue a opcode=close (0x8) message for transmission in txbuf.
2. On the subsequent calls to pull(), easywsclient will try to flush out the tx queue (txbuf).
3. Finally, call close() on the socket when txbuf is empty (which should send RST from easywsclient).

Question for you: after step 3, what ACK packet is there to be handled? Let me know if I misunderstood this. Thanks.

[kgizdov]

So, after the pull() the other side sends an ACK and then easywsclient sends a RST. I'm guessing the RST is actually sent my the kernel as easywsclient has closed the socket already. I'm not sure if this ACK is handled or not to be honest and I'm not sure how to test it.