[Chromium-environment] Re: [Fwd: Dynamic Host Markers]

[Robert E. <pa...@tu...>]

 From Joel:

> So here is a way to nicen the syntax.  
> 
> -Every Node type gets a list of constraint attributes.  This is implicit in 
> the "#" dynamic marker syntax as well, I believe.
> 
> -The constructor definitions get changed to be of the form:
> 
> CRNetworkNode( object, tagString="match_string" )
> 
> and the treatment of object depends on tagString.  The default behavior adds a 
> match-this-string-type constraint to the node's constraint list, so that old 
> scripts don't break and old tools and conf writers don't get confused.  The 
> availability of tagString and a new Node.addConstraint() method allows for a 
> lot of future expansion.  One could even do something like:
> 
> CRNetworkNode( "foo", "dynamic_host" )
> 
> to get exactly the internal logic your proposal would give with
> 
> CRNetworkNode( "#foo" )

I've refined this a bit during implementation.

- Every node constructor is of the form:

   CR.*Node(host, constraint = "name", constraintArg = None)

- The "host" argument represents the machine.  By default, it must be the name 
of the connecting machine; but with dynamic hosts, this isn't necessarily the 
case.  With dynamic hosts, it's just a string identifier that can be used to 
differentiate hosts.

- The "constraint" and "constraintArg" allow control over which hostnames will 
match to which nodes.  By default, the "name" constraint only matches incoming 
connecting hostnames to nodes with identical hostnames provided.  Other variants 
include:

   node = CRNetworkNode("server1", "dynamic")

(the "dynamic" test allows the test to match any incoming connecting hostname to 
this node)

   node = CRNetworkNode("server1", "regex", "name[0-9]*")

(the "regex" test only allows incoming connecting hostnames that match the given 
regular expression to match the node)

   pattern = re.compile("name[0-9]*")
   node = CRNetworkNode("server1", "pattern", pattern)

(the "pattern" test works like the "regex" test, but with a precompiled pattern)

   node = CRNetworkNode("server1", "regex_full", ".*\.psc\.edu")

(the "regex_full" test checks the regular expression against the fully qualified 
domain name of an incoming connecting machine)

   pattern_full = re.compile(".*\.psc\.edu")
   node = CRNetworkNode("server1", "pattern_full", pattern_full)

(the "pattern_full" test works like the "regex_full" test, but with a 
precompiled pattern)

- A single node may have multiple constraints added to it, via the new 
node.AddConstraint(constraint, constraintArg) method.  A node will only be 
accepted for an incoming connection name if all constraints are satisfied.

- If all the constraints for a node are static (i.e., allow the name of the 
connecting host to be known before incoming connections are made), the node is 
static.  If any of the constraints is dynamic (i.e., have to be resolved to true 
hostnames before use), the node is dynamic.  For any dynamic node, the "host" 
parameter is a placeholder; it is a variable name, not a machine name.  I use 
special syntax to make it clear that the supplied host name is a dynamic 
variable rather than an explicit host name, such as:

   node = CRNetworkNode("#server1", "dynamic")

or

   node = CRNetworkNode("SERVER1", "dynamic")

but such syntax is not required.

- When an incoming connection is made, all possible static matches are tried, 
then all already-resolved dynamic matches are tried, before any new dynamic 
matches are resolved.  When dynamic matches are resolved, the first node of the 
appropriate type (i.e. a CRNetworkNode for a server, a CRApplicationNode for an 
app faker, etc.) that satisfies all the constraints will be used.  Multiple 
processes running on the same host can resolve multiple dynamic nodes (all to 
the same hostname, of course).

- To define a bank of network nodes that will be resolved to incoming server 
connections, use something like:

	for serverNumber in range(NUM_SERVERS):
		node = CRNetworkNode("server%d" % serverNumber)
		... # configure the node and add it

I believe this satisfies all the requirements we've had to date.  For futures, 
it's easy to add more constraint tests, if more are needed; I think a special 
"or" test would be great, so that you can design configuration files that work 
without change in very different environments... but I'm not planning on making 
these changes at this time.

Bob Ellison
Tungsten Graphics, Inc.