[Openais] Re: [Linux-cluster] new userland cman

[Patrick Caulfield]

Steven Dake wrote:
> Patrick
> 
> Thanks for the work
> 
> I have a few comments inline
> 
> On Fri, 2005-09-30 at 14:44 +0100, Patrick Caulfield wrote:

>>- Hard limit to size of cluster (set at compile time to 32 currently)***
>>
> 
> 
> I hope to have multiring in 2006; then we should scale to hundreds of
> processors...

Nice :)

I have some ideas for shrinking the size of the current packets which will help
the current system and lower the ethernet load. I'll start on those shortly.

> 
>>neutral
>>-------
>>- Always uses multicast (no broadcast). A default multicast address is supplied
>>if none is given
> 
> 
> If broadcast is important, which I guess it may be, we can pretty easily
> add this support...
> 

I was going to look into this but I doubt its really worth it. It's just any
extra complication and will only apply to IPv4 anyway.


>>- libcman is the only API ( a compatible libcman is available for the kernel
>>version)
>>- Simplified CCS schema, but will read old one if it has nodeids in it.****
>>
>>internal
>>--------
>>- Usable messaging API
>>- Robust membership algorithm
>>- Community involvement, multiple developers.
>>
>>
>>* I very much doubt that anyone will notice apart from maybe Dave & me
>>
>>** Could fix this in AIS, but I'm not sure the patch would be popular upstream.
>>It's much more efficient to run them on different ports or multicast addresses
>>anyway. Incidentally: DON'T run an encrypted and a non-encrypted cluster on the
>>same port & multicast address (not that you would!) - the non-encrypted ones
>>will crash.
>>
> 
> 
> On this point, you mention you could fix "this", do you mean having two
> clusters use the same port and ips?  I have also considered and do want
> this by having each "cluster" join a specific group at startup to serve
> as the cluster membership view.  Unfortunately this would require
> process group membership, and the process groups interface is unfinished
> (totempg.c) so this isn't possible today.  Note I'd take a patch from
> someone that finished the job on this interface :)  I for example, would
> like communication for a specific checkpoint to go over a specific named
> group, instead of to everyone connected to totem.  Then the clm could
> join a group and get membership events, the checkpoint service for a
> specific checkpoint could join a group, and communicate on that group,
> and get membership events for that group etc.
> 
> What did you have in mind here?


Actually something /very/ simple. the old cman just had a uint16 in every packet
which was a cluster_id. If the cluster_id in an incoming packet didn't match the
one read from the config file then the packet was dropped. It's really just a
way of simplifying configuration for those using broadcast or a default
multicast address.

In my more evil moments thought it might be worth hijacking the commented out
"filler" in struct message_header :)
-- 

patrick