Hi Pieter, On Mon, Nov 16, 2015 at 07:14:33PM +0100, PiBa-NL wrote: > >>But i think thats not so much a problem, it does still make > >>me wonder a little what happens if a packet is lost in the middle of a > >>tcp connection, will it resend like a normal tcp connection? Its > >>difficult to test though.. > >Haproxy doesn't affect how TCP works. We never see packets, the TCP stack > >guarantees a reliable connection below us. > But without the patch only 1 SYN packet is send, shouldn't the normal > tcp stack always send 3 SYN packets when a connection is not getting > established?
Absolutely, so my guess is that it's purely a timeout issue, probably that the default mailer timeout is too short to allow a retransmit to be sent. The default SYN retransmit to an unknown target is 3s usually, maybe we're running with a 3s (or lower) timeout here ? I don't know how they're set, I haven't looked at this part recently I must confess. > >>If you can apply the v2 patch i think that solves most issues that one > >>or two lost packets can cause in any case. > >Now I'm having doubts, because I think your motivation to develop this > >patch was more related to some fears of dropped *packets* (that are > >already properly handled below us) than any real world issue. > My initial motivation was to get 3 SYN packets, but if the tcp > connection is handled through the normal stack i don't understand why > only 1 is being send without the patch, and because only 1 syn packet is > being send i am not sure other ack / push-ack packets would be retried > by the normal stack either.?.(i have not yet tested if that is the case) I agree with you since we don't know the timeout value nor what it applies to (connection or anything). Thus I think that we should first find and change that value, and maybe after that take your patch to permit real retries in case of connection failures. Thanks, Willy
