hello yutaka ,
i will give it defenitly a trie !
On 01/04/06(16:18) you firstname.lastname@example.org wrote
in /<_A3098@delegate-en.ML_>/ <http://www.delegate.org/mail-lists/*/_A3098@delegate-en.ML_?Base=mail-lists.delegate-en/3100>
|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
|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
|process is started.
Imagine that there are multiple clients running on the same host, or
accessing via the same proxy host.
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.
D G Yutaka Sato <email@example.com> <http://firstname.lastname@example.org?Base=mail-lists.delegate-en/3100> 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