Read this by @majek04. Then think about the attack this is needed to prevent. TCP as specified is not adversarial. https://blog.cloudflare.com/this-is-strictly-a-violation-of-the-tcp-specification/ …
I still don't get why CLOSE_WAIT exists at all, i.e. why kernel can't handle this transition.
-
-
hmmm, maybe the application might want to control when the FIN is sent (by use of the close call)?
-
I suppose so but I don't understand the motivation.
End of conversation
New conversation -
-
-
there may still be data waiting to be sent. It must happen when a duplex channel is treated as simplex.
-
Whether there is data waiting to be sent is a function of the socket state, tho, not whether fd is closed.
-
The app can't send new data on a CLOSE_WAIT socket, so doesn't seem to justify exposing this state to the app.
-
The FIN means the client has stopped sending. It doesn't imply that the client can't receive.
-
Oh so it's just a one-way shutdown()? That doesn't seem to match the article's analysis though.
-
I know little more than the article, but it checks out to me. The article problem is asymmetric timeout/state.
-
Well in the article the peer close()d socket rather than just shutdown(SHUT_WR). So why can't kernel reap it?
-
no, wait, the client side is reaped. The server side did NOT call close() (root cause), and leaked, and dangled
- 3 more replies
New conversation -
-
-
Conceptually it'd be similar to the kernel dup2'ing a dummy file over top of the dead socket.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.