Hi Pieter, On Mon, Nov 16, 2015 at 12:13:50AM +0100, PiBa-NL wrote: > >>>>>-but check->conn->flags & 0xFF is a bit of s guess from observing the > >>>>>flags when it could connect but the server did not respond > >>>>>properly.. is there a other better way? > >This one is ugly. First, you should never use the numeric values > >when there are defines or enums because if these flags happen to > >change or move to something else, your value will not be spotted > >and will not be converted. > Agreed it was ugly, but i could not find the enums based equivalent for > that value.. Now i think its only checking 1 bit of it. But that seems > to work alright to.
You could have ORed all the respective flags but even so it didn't really make sense to have all of them. > >Thus I'm attaching two proposals that I'd like you to test, the > >first one verifies if the connection was established or not. The > >second one checks if we've reached the last rule (implying all > >of them were executed). > From my tests both work as you describe. > v1 one retries the connection part, v2 also retries if the mail sending > did not complete normally. > I think v2 would be the preferred solution. OK fine, thanks for the test. > Though looking through my tcpdumps again i do see it tries to connect > with 3 different client ports thats not how a normal tcp socket would > retry right? Do not confuse haproxy and the tcp stack, that's important. Dropped *packets* are dealt with by the TCP stack which retransmits themm over the same connection, thus the same ports. When haproxy retries, it does not manipulate packets, it retries failed connections, ie the ones that TCP failed to fix (eg: multiple dropped packets at the TCP level causing a connection to fail for whatever reason, such as a blocked source port or a dead link requiring a new connection to be attempted via a different path. > 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. > 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. Could you please confirm exactly what case you wanted to cover here ? Thanks, Willy