Hi Willy,
Op 16-11-2015 om 7:20 schreef Willy Tarreau:
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.
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?
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)
Could you please confirm exactly what case you wanted to cover here ?
Thanks,
Willy
Regards
PiBa-NL
