[Openais] CPG - x86 - sparc heterogenous cluster

Steven Dake steven.dake at gmail.com
Thu Jul 30 20:16:47 PDT 2009


On Thu, Jul 30, 2009 at 5:38 AM, Wojtek Meler <wmeler at wp.pl> wrote:

> Fabio M. Di Nitto pisze:
> > On Thu, 2009-07-30 at 12:55 +0200, Wojtek Meler wrote:
> >
> >> Fabio M. Di Nitto pisze:
> >>
> >>> testcpg is not endian clean. That's why you see them backwards.
> >>>
> >>>
> >> I thought that corosync handles endianess in corosync daemon, and
> >> clients - like testcpg -
> >> don't need to worry about it. Is it true?
> >>
> >
> > No it´s not true. neither corosync or associated libraries have any idea
> > of what kind of data you are transmitting over the wire. They can't
> > randomly swab stuff around.
> >
> >
> Sure, I was not clear - what I ment is services loaded in corosync
> daemon (like service_cpg.lcrso)
> handles endianess in their messages sent over the wire, but client
> libraries (libcpg,so)
> that communicate over coroipcc don't.
> Messages from processes that are in CPG group are not touched (different
> layer).
>
> If it is not I completely misunderstood corosync architecture.
>
> Regards,
> Wojtek
> _______________________________________________
> Openais mailing list
> Openais at lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/openais
>


My take on this is that totemsrp swabs the nodeid when it receives the
message in a cross endian system, and delivers the byte swabbed nodeid to
cpg.  When autogeneration of node ids is used, you may expect that the node
id is the 32 bit ip address in network byte order.  Instead the node id is
autogenerated in host byte order.

We could ensure that the autogenerated node ids are always in little endian
format (ie: swab them on big endian architectures) rather then a mix of
little and big endian as is the case now in cross endian systems which makes
understanding the content of the autogenerated nodeid impossible (and
provides a possible collision of nodeids in an ipv4 network).

Try this patch.  If this doesn't solve it, a swab may be required in testcpg
-i operations on BE arches.

I could be entirely wrong about all this though.  I'm not sure whether the
node id is in BE or LE when generated.  Whatever it is now, we can't swab
during creation on LE architectures because to date LE has been our main
focus and it would cause all sorts of compatibility breakage.

Regards
-steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/openais/attachments/20090730/ff7037eb/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: corosync-trunk-totem-autogen-le.patch
Type: application/octet-stream
Size: 838 bytes
Desc: not available
Url : http://lists.linux-foundation.org/pipermail/openais/attachments/20090730/ff7037eb/attachment.obj 


More information about the Openais mailing list