Since this seems to apply to everyone ...

I don't have a problem with polling the down server.  Its relatively simple
to ping or attempt a connection to a server with a short timeout.  If it
times out, move on.  Otherwise, you don't know when that server comes back

Your random distribution was the only thing I was commenting on.  Your logic
of whether to 'keep polling' a down server has _nothing_ to do with whether
you use totally random selection or random select then round-robin.

That said, the best way to accomplish this well would be:

Store servers in an array of structs:
struct server {
    ip_addr address;
    int down = 0;
    int try = 0;

struct server * servers; // malloc them ...

1) pick random start # from 0 to (num_servers - 1)
2) if servers[this_server].down > 0 then:
  - servers[this_server].try++;
  - if (try < down), increment, go to (2)
  - else, try = 0 ...
3) connect to server
  - if failed:
  - servers[this_server].down++;
4) (success) increment start, set server.down to 0.
5) if another message, increment, go to (2)

That's off the top of my head -- but it would allow for linear (not
exponential) decrease of use of down servers.  Over time, if a server was
down for a long time, it would stop being polled for a connection as often.

----- Original Message -----
From: "David Dyer-Bennet" <[EMAIL PROTECTED]>
Sent: Wednesday, August 02, 2000 1:03 PM
Subject: Re: updated load balancing qmail-qmqpc.c mods

> JuanE <[EMAIL PROTECTED]> writes on 2 August 2000 at 16:37:36 GMT
>  >
>  > I agree with you both (Jay and Michael), at least partially. I agree
>  > altough what Jay proposes will work, it is too much computation and
that a
>  > simpler round-robin (after picking initial position) would suffice.
>  >
>  > My comment is that in the event of a down server, the simple round
>  > will flood the next server in the chain with twice the load of the
>  > Jay's solution does not do this (at a high computational cost).
>  >
>  > What I proposed earlier is just one of *many* solutions that addresses
>  > flood problem at a lower computational cost.
>  >
>  > Jay, I agree with you that selecting the same server many times in a
row is
>  > not an issue. This is guaranteed by the Law of Averages (for you math
>  > wizzes out there, the Law of Large Numbers).
> Sounds like making repeated random picks is the way to go.
> If no server is down, your one random pick will handle the mail (same
> cost as picking random starting point for round-robin).
> If a server is down *and you hit it*, you pay the cost of a second
> random pick.  This is slightly expensive, but you only pay it when
> you need it.  It's cheaper in elapsed time than trying the next server
> and having it refuse the connection due to overload, for example.  And
> it spreads the load more evenly.
> On the third hand, if the servers can manage their incoming
> connections intelligently (say with tcpserver :-) ), the one after a
> down one in a round-robin, while it will get hit a lot, can refuse
> some of the connections, which will then go on to the next after it.
> So you aren't really constrained to running all your servers at less
> than 50% capacity, and the one after the down one won't actually melt
> down.
> --
> Photos: Minicon:
> Bookworms: SF:
> David Dyer-Bennet / Welcome to the future! / [EMAIL PROTECTED]

Reply via email to