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

Re: [Linux-cluster] Where to go with cman ?



On Mon, 2005-08-08 at 16:30 +0100, Patrick Caulfield wrote:
> Steven Dake wrote:
> > Thats great news Patrick.  One thing you should be aware of is that I
> > have changed some of the internal interfaces in preparation for others
> > to use libtotem to be extremely more sanitary.  Unfortunately I may have
> > done this a little too late in your case..  But I think you will find
> > things are a little better.  It really only effects totempg_initialize.
> > Also libtotem was renamed to libtotem_pg because of requests from Daniel
> > about a name-space collision with some movie player in fc4.
> 
> Yes I spotted that, my current "nearly-working" cman is based on the latest SVN
> sources.
> 
> > For multihoming, I want to support the totem redundant ring protocol in
> > the totem code.  This is an extension of totemsrp to support multiple
> > nics per processor.  Then data is either actively or passively
> > replicated over multiple links.  There is essentially no failover and
> > multiple links can offer better performance and still operate properly
> > when one entire network fails.  It looks pretty simple to implement.
> > The paper is at:
> > 
> > http://www.rcsc.de/pdf/icdcs02.pdf
> 
> Excellent, thanks. I'll have a read.
> 

Patrick,

Over the weekend I reorged the totem code significantly (although the
totempg interfaces have not changed).  The reorg was painful timewise,
but the result is that redundant ring should be pretty easy to implement
now.  Basically I took all of the network junk out of totemsrp and put
it in "totemnet.c".  It also allows for multiple instances of totemnet
binds.  This is the main feature I needed to implement redundant ring in
a clean fashion.  The ipv6 support should be a little easier to add now
since most of the network code is limited to totemnet.

I should have a patch in a few days with a redundant ring passive and
active implementation.

regards
-steve


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