Hi,
Benoit <[email protected]> wrote:
> Maik Broemme a écrit :
> > Hi,
> >
> >
> > Multiplex means traffic duplication. If you have multiple server
> > configuration options in one listen group, the incoming traffic is
> > sent to all servers.
> >
>
> Hum, i'm sorry but no, multiplexing is not duplication. In fact it's
> more like the opposite,
> it's the process of combining multiple data stream into one (long descr.
> here: http://en.wikipedia.org/wiki/Multiplexing)
Sorry multiplexing was the wrong word for it, I rellay talk about
duplication.
> >
> > tcpdump is not perfect in that case, because it has to run the hole time
> > you want to duplicate the traffic and sent it to server1 and server2.
> >
> So let's say you pacth haproxy and he duplicate traffic to two servers
> and is able to forget
> data from one (the dev/test one) and keep the other (the prod one).
>
> How will haproxy been able to react to the different responses/timing
> from each servers ?
> Let's say you duplicate MX traffic, with the test server being used to
> validate a new configuration
> to keep away spammers (simple example).
> Let's say both server are able to answer at the exact same time or
> aren't too frisky about having the answer
> before the question, when the prod server will accept the mail message
> and start listinening from it's main
> part the other could have rejected it, however he still will receive the
> main part, while not expecting it,
> which depending of the implementation could lead to troubles, like if
> the originating mail server try to
> send another mail using the same connection.
>
I am thinking about the timing issues, my guess is to add a option for
the duplicate balance algorithm, lets say 'async' or 'sync'. In 'async'
state haproxy will send traffic to dev/test and only take care of
response from dev, regardless if test respond or not. Later answer from
test will be dropped by haproxy. In 'sync' state the haproxy will wait
until dev/test has answered and send the answer from dev to client.
For short:
- async will drop everything from test, regardless of answer
time and send everything to test regardless if it is expected or
not.
- sync will drop everything from test, but wait until it has answered.
There will be - for sure - not much scenarios were you need such
feature.
>
> This is a very simple example and most MX implementation could react
> correctly but that's not the case of
> everything
>
>
--Maik
