[Top][All Lists]

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

[Vrs-development] Re: Goldwater Domains

From: Chris Smith
Subject: [Vrs-development] Re: Goldwater Domains
Date: Tue, 23 Apr 2002 18:04:29 +0100

On Monday 22 April 2002 17:52, Bill Lance wrote:

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

It certainly DOES handshake - at least to make sure 
that the process waiting for reply data still wants it 
(it may have timed out or died).  We don't want to send
megabytes of data across a network to a remote destination
that doesn't want it or know anything about it (any more).

Uni-directional means that the Bridge process only
sends data out.  That is, if sending a request to a
remote domain, the reply does not come in on the same

The reply comes in on the connection the remote domain
has established with our local domain.


  Local          Remote
 -------         -------
   Bridge ----> netServer
netServer <---- Bridge

> Hum, this doesn't sound stateless  :)

Nope, cos you've got data going out on one connection
from one process, and data coming in on another
connection to another process which both need to be tied

The base architecture of Goldwater employs uni-directional
messages, so designing the inter-domain comms this way kind
of makes the implementation drop out of the hat (with a
suitable sprinkling of magic dust of course :o)

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

Well, if you turn the log level up (as you've seen) you see
more internal debugging than you can deal with!
If you know what you're looking for it is very readable, with
a little experience.

To test the inter domain comms, I'm going to allow a
loopback mode, where ALL requests, even for GWServices in
the local domain are routed through the Bridge.
The net effect is that all requests will go Bridge->netServer
and all replies will also go Bridge->netServer.
If I've done the job properly, all messages should be
tracked and delivered to the correct servers/clients.

It will also allow raw performance testing of inter-domain
comms without the network wire in place.

And you only need to configure one domain to get the whole
thing working (which is nice if you're very busy!)


Chris Smith
  Technical Architect - netFluid Technology Limited.
  "Internet Technologies, Distributed Systems and Tuxedo Consultancy"
  E: address@hidden  W: http://www.nfluid.co.uk

reply via email to

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