Re: troubles with caps

[Dave Leimbach <leimySPAM2k@xxxxxxx>]

Dave Leimbach <leimySPAM2k@xxxxxxx> writes:

> Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx> writes:
> 
> > :> Ah, so that's what client.c is doing.  OK, well there's no good reason
> > :> to share the connection; I just wanted to clarify that limitation.
> > :> 
> > :
> > :Yeah... servers are one to many clients.  No two servers should have
> > :the same name, though the current code allows it... Hiten has a patch
> > :that seems to work though :).
> > :
> > :Dave
> > 
> >     That's on purpose.  There is a flag, CAPS_EXCL, that can be used to
> >     disallow namespace overloading.  Namespace overloading is useful when
> >     restarting a service because it allows the new service to register
> >     its port before the old service is killed.  Clients then only see a
> >     single interruption and can immediately (successfully) reconnect.
> > 
> 
> Hmmm... I think that maybe there should be a flag to allow two 
> services with the same name to co-exist rather than one to disallow it?  
> EXCL is an obvious flag choice for the way things are now
> 
> I think having two with the same name is the more rare case and the way it is
> sure confused me :).
> 
> Wouldn't the current situation be a race when calling caps_drop and caps_hold
> to increment and decrement the reference counts?
> 
> Dave
> 

Actually now that I think about it... If it's not really creating a new
CAPS service port when two with the same name are requested... would they
both get duplicate notification of incoming messages?

This would indeed be an interesting choice for some QoS and fault tolerance
situations.  You could do one of the forms of replication that are present
in CORBA's FT models where a group of processes are simulating what the
real active process does.  Internally they can use some kind of mechanism
like gossip or what-not to determine if someone in their group is dead and
needs to be replaced...

That could be very interesting indeed :)

Dave