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 -- Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
