TJ [EMAIL PROTECTED] writes:
Therefore, anyone deploying apache web servers in a web-farm behind the
Juniper DX load-balanders and using TCP multiplexing (for which they pay
a hefty licence fee!)
If they ask for that much money they can surely fix it to work
properly too?
-Andi
-
To
On Fri, Aug 24, 2007 at 01:08:25AM +0100, TJ wrote:
An RFC 793 standard TCP handshake requires three packets:
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
Hello!
At present with TCP_DEFER_ACCEPT the kernel treats the RFC 793 handshake
as invalid; dropping the ACK from the client without replying so the
client doesn't know the server has in fact set it's internal ACKed flag.
If the client doesn't send a packet containing data before the
On Fri, 2007-08-24 at 12:40 +0400, Alexey Kuznetsov wrote:
There is no protocol violation here, ACK from client is considered as lost,
it is quite normal and happens all the time. Handshake is not complete,
server remains in SYN-RECV state and continues to retransmit SYN-ACK.
If client tried
TJ wrote:
Right now Juniper are claiming the issue that brought this to the
surface (the bug linked to in my original post) is a problem with the
implementation of TCP_DEFER_ACCEPT.
My position so far is that the Juniper DX OS is not following the HTTP
standard because it doesn't send a request
I'd welcome the views of those familiar with TCP_DEFER_ACCEPT on a
recent issue I've worked on where connections between a Juniper DX (aka
redline) load-balancer and Apache 2.2 cluster caused random connection
failures.
Today, after 2 weeks debugging the issue, we confirmed the problem was
TJ wrote:
client SYN server LISTENING
client SYN ACK server SYN_RECEIVED (time-out 3s)
server: inet_rsk(req)-acked = 1
client ACK server (discarded)
client SYN ACK (DUP) server (time-out 6s)
client ACK (DUP) server (discarded)
client SYN ACK (DUP) server (time-out 12s)
