Pending feed-back from the Linux netdev mailing list as to whether this can be considered a bug in the kernel's implementation of TCP_DEFER_ACCEPT on this basis:
An RFC standard TCP handshake requires three stages: client SYN > server LISTENING client < SYN ACK server SYN_RECEIVED client ACK > server ESTABLISHED client PSH ACK + data > server TCP_DEFER_ACCEPT is designed to increase performance by reducing the number of TCP packets exchanged before the client can pass data. client SYN > server LISTENING client < SYN ACK server SYN_RECEIVED client PSH ACK + data > server ESTABLISHED At present with TCP_DEFER_ACCEPT the kernel treats the RFC handshake as invalid; dropping the ACK from the client without replying. There is a case for arguing the kernel is operating in an enhanced handshaking mode when TCP_DEFER_ACCEPT is enabled, not an alternative mode, and therefore should accept *both* client responses (ACK, then PSH ACK + data, or PSH ACK + data). I've been unable to find a specification or RFC for implementing TCP_DEFER_ACCEPT aka BSD's SO_ACCEPTFILTER. It seems incorrect to penalise a client that is trying to complete the handshake according to the RFC specification, especially as the client has no way of knowing ahead of time whether or not the server is operating deferred accept. I'll update once the kernel net-devs have given their views. -- Unexplained random HTTP connection failures in hardware load-balanced web-server farms https://bugs.launchpad.net/bugs/134274 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
