|
Hello Jacob,
> Time Client Server Comment
> | | |
> v |----- SYN isn1 --------->| initiate connection
> |<- SYN isn2 ACK isn1+1 --| this my not pass through the
> LB
> | |
> ** CHECK HERE: |----- ACK isn2+1 ------->|
> | |
> What the LB could do is to check the timediff between "SYN isn1" and "SYN
> isn2 ACK isn1+1".
Don't do that! What would the timediff be? I reckon it's higher then your
userspace 1HZ.
> But this packet may not return through the LB, when configured as tunnel or
> gate.
> But LVS could check for "ACK isn2+1". If that time expires, You can bet that
> the real server
No, what about retransmit? SACK? tao? The current implementation is rfc89x TCP
friendly. This means no artificial intelligence to the kernel. You're proposing
some sort of connection tracking.
> is dead. Then You may set its weight to lets say -weight and give the
> responsability to
> the monitoring software, which may readd the realserver after is came back.
Who checks if it is back? What if I misconfigured my iptables rules on the
realserver and I open it again?
> I think it should not be too difficult to implement this, or am I wrong?
IMHO it would be very difficult to implement it. First, timers in kernel are
bitchy, second, you cannot rely on the fact that if the ACK isn2+1 doesn't
show up within timediff your service is not available anymore, unless you
set the timediff very high.
Try to convince me ...
Best regards,
Roberto Nibali, ratz
--
mailto: `echo NrOatSz@xxxxxxxxx | sed 's/[NOSPAM]//g'`
|
