vrs-development
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Vrs-development] Re: Goldwater Domains


From: Bill Lance
Subject: [Vrs-development] Re: Goldwater Domains
Date: Mon, 22 Apr 2002 09:52:22 -0700 (PDT)

That's great news Chris.  I am really looking forward
to getting my hands on this!

--- Chris Smith <address@hidden> wrote:
> Bill,
> 
> I've had an excellent few days.
> I've redesigned the Domain handling TWICE, with
> the newest proposal being rather smart.
> 
> Even if I do say so myself :o)
> 
> It's not going to get implemented for a few weeks
> as I'm in Manhattan from Thursday (for 5 days)....
> mind you I get a good few hours on the plane to do
> some more explicit design.
> 
> It's mainly procedural stuff and control flow.
> 
> Basically, I've designed a uni-directional Bridge
> process that sends data from one domain to remote
> domains.  This data may be (GWService) requests or
> replies.  Being uni-directional is excellent for
> implementation, scalability and performance reasons.
> So requests sent from the local Bridge, and replies
> are received from remote bridges.
> Bridges talk to remote netServer processes (phoenix
> in the original Domain implementation).
> 

By 'uni-directional', do you mean that there is no
handshaking, or that it is stateless?

> The Bridge processes try to do block transfers too,
> so if more than one request is made for services at
> a remote domain then the Bridge tries to send them
> all in one batch - making efficient use of network
> bandwidth and avoiding sparsely populated network
> packets.
> 
> Now the accounting tables required are far more
> complicated with this design, as there are quite a
> few session variables that need to be persisted
> between sending the request and receiving the reply
> (so we know which server is expecting which reply)
> and to avoid miss-interpreting stale replies that
> are received *after* the issuing server has
> timed out and given up waiting....
> 

Hum, this doesn't sound stateless  :)

> But this is all handled behind the scenes in the
> GW API, so anyone using GW (ie the LDS) just
> calls the service they require, and if it happens
> to be in a remote domain, it gets routed.  The
> caller has no idea, and doesn't care.
> 



> The goldwater command line tool should be able
> to give dynamic stats on the status of the Bridge
> and the state of pending requests/replies by
> querying the accounting tables.  More useful
> administration info!
> 
> Hurrah.
> 
> Oh, and it's based on a spin of some existing
> technology used by Goldwater, so I'm 100% confident
> that it'll prove reliable and managable.
> 
> Me things the redesign/rewrite was a Very good idea!
> 
> If the above seems oh-so-very-complicated then don't
> worry,  you don't really need to know, but if some
> of it sticks then you'll have an good idea what's
> going on if it doesn't seem to be doing what you
> expect!
> 

Speaking of that, do you have any runtime debuging
routine built in at this point?



__________________________________________________
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]