On 01/04/06(16:18) you ppefabdyi.ml@delegate.org wrote
in <_A3098@delegate-en.ML_>
 |i was wrong about the recent post. it is not accurate,
 |that multiple masters are not tried in order ! 
 |but i observed a problematic behaviour when selecting multiple masters.
 |for each request , the whole process of selecting a master is started all
 |over again. i tried the TIMEOUT=hello:5 , to speed up the selection 
 |process ,
 |but without sucess. however it does not make sence to try all the masters 
 |on each request.
 |instead it would be usefull to set a separate value, after wich the 
 |re-election
 |process is started.

Imagine that there are multiple clients running on the same host, or
accessing via the same proxy host.

                                (MASTER)
    clientA               +---- DeleGateX ----+
    clientB -- DeleGate --+                   +-- server      
    clientC               +---- DeleGateY ----+

Even a client will make multiple requests on multiple TCP connections.
So there is no way to detect whether or not there are multiple clients
or not on the client-host in TCP level.  Thus DeleGate cannot distinguish
whether a request sent in a TCP connection is the "first" one or not.

Such session can be realized in an application layer protocol, for example
using Cookie header in the HTTP protocol (or using Digest-Authentication).
The DeleGate can send Set-Cookie:MASTER=Y to a client in response when
DeleGateY is selected as a master.  The client will echo Cookie:MASTER=Y
in request, then the DeleGate use the DeleGateY without trying DeleGateX.
I implemented this scheme and it seems working.  I'll open the patch
if you will give it a try.

Cheers,
Yutaka
--
  D G   Yutaka Sato <pfqcabdyi-jmfhzlyimedw.ml@delegate.org> http://delegate.org/y.sato/
 ( - )  National Institute of Advanced Industrial Science and Technology
_<   >_ 1-1-4 Umezono, Tsukuba, Ibaraki, 305-8568 Japan
Do the more with the less -- B. Fuller