Re: Network Recommendation

"Ian Latter" <[email protected]> Sun, 16 Apr 2006 16:56:58 +1000
Newsgroups	gmane.linux.cluster.openmosix.devel
Message-ID	<[email protected]>

FYI, found one of the public posts;

  RE: [openMosix-general] Adding Node locked all My other nodes
  Tue, 11 Nov 2003 06:44:31 +1000

  "After I sent this last night .. I was in a hurry and made a bit of a booboo ..
  I booted my laptop with CHAOS v0.7b3 (2.4.22-1 with LOADLIMIT) into
  a cluster of CHAOS v0.7b2 (2.4.22-1 without LOADLIMIT) machines ..
  and crashed them all (all of the b2 machines, that is) :)"


.. definitely a problem with oM to oM.




----- Original Message -----
>From: "Ian Latter" <[email protected]>
>To: "Moshe Bar" <moshe-ay74M1d3r6RWk0Htik3J/[email protected]>
>Subject:  Re: [Openmosix-devel] Network Recommendation
>Date: Sun, 16 Apr 2006 16:32:25 +1000
>
> 
> Hello,
> 
> 
>   Something you're saying either isn't true, or not implemented as
> thought.
> 
>   I've been searching through my old mail, and I only started using
> openMosix during its 2.4.x kernels, onward.  I can't see any of 
> the messages from the era online, but I have found one of my 
> own messages on the subject.  It was to Wim in Oct 2003 .. when
> experimenting with beta version of CHAOS-0.6 and ClusterKNOPPIX
> V3.3-2003-09-24-EN-cl1;
> 
>   "If I run a clusterKNOPPIX node with omdiscd .. then boot 
>    CHAOS .. all is well.  If I disable CHAOS's packet filtering .. all
>    is still well.  If I run omdiscd on CHAOS, then it finds the 
>    clusterKNOPPIX node, and vice versa .. but then 1 or 2 
>    seconds later, the CHAOS node will kernel panic (oM_infoD).
>    If, however, two CHAOS nodes meet, using omdiscd, then 
>    there is no problem (and I presume that this is the case for 
>    clusterKNOPPIX)."
> 
>   This was later traced to the two kernels having different
> oM options compiled in .. and whether or not this particular
> openMosix option was compiled in to the kernel, one node of 
> one state would always trash the other node of the other 
> state.
> 
>   There were public messages on this, but I haven't found
> them yet .. I will have them.
> 
>   I later indicated that this problem hadn't been resolved in the
> 2.4.22-1 kernel, on page 10 of 24, of the "Security and 
> openMosix" paper, due to failed encryption attempts (which
> would also have meant that any "version" information was
> invalid, from an oM perspective).
> 
> 
>   If they "will not communicate" on wrong version info (since 
> the Kernel 2.2 series) then the version checking isn't in good
> order.  Either that, or/and the version implemented is static ... and
> does not take into account the compiled in kernel options ...
> 
> 
>   I need to keep coding, but I know that one node will crash
> another node when they are the same version but with different
> options.
> 
> 
> ----- Original Message -----
> >From: "Moshe Bar" <moshe-ay74M1d3r6RWk0Htik3J/[email protected]>
> >To: "Ian Latter" <[email protected]>
> >Subject:  Re: [Openmosix-devel] Network Recommendation
> >Date: Sat, 15 Apr 2006 22:46:41 -0500
> >
> > Ian,
> > 
> > Yes, we do. They will not communicate if they are on different  
> > protocol versions.
> > 
> > Moshe
> > 
> > 
> > On Apr 15, 2006, at 11:55 PM, Ian Latter wrote:
> > 
> > >
> > > Sooo, you guys aren't checking for these boundaries?  Why
> > > can one node crash another if they're compiled with different
> > > options, if you're checking this version data?
> > >
> > >
> > > ----- Original Message -----
> > >> From: "Moshe Bar" <moshe-ay74M1d3r6RWk0Htik3J/[email protected]>
> > >> To: "Ian Latter" <[email protected]>
> > >> Subject:  Re: [Openmosix-devel] Network Recommendation
> > >> Date: Sat, 15 Apr 2006 22:36:28 -0500
> > >>
> > >> Ian
> > >>
> > >> We do have a denial of service issue (which in a LAN environment is
> > >> not a huge thing), but not due to different protocol versions. In the
> > >> includes directory of oM you'll find the version.h file defines
> > >> version boundaries for oM nodes to work together. It's been there
> > >> ever since oM for kernels 2.2
> > >>
> > >> Moshe
> > >>
> > >>
> > >> On Apr 15, 2006, at 10:53 PM, Ian Latter wrote:
> > >>
> > >>> Hello,
> > >>>
> > >>>
> > >>>   I am currently coding up a smart socket handling library for
> > >>> libMidnightCode and it made me think about openMosix.
> > >>>
> > >>>   Since I started using openMosix (a few years now), oM has
> > >>> suffered from a Denial of Service issue whereby junk data
> > >>> on its listening sockets will ultimately cause it to crash.  This
> > >>> isn't good, but it also isn't what I wanted to see fixed (in this
> > >>> thread).
> > >>>
> > >>>   What stems from this issue is that users compiling different
> > >>> oM versions and adding them to the same cluster will
> > >>> semi-randomly result in nodes crashing nodes upon
> > >>> negotiation or migration.  This seems likely to be a result of
> > >>> changes in the protocol between oM versions - with the
> > >>> mismatch data acting as a trigger for the DoS issue (above).
> > >>>
> > >>>   If you applied a "Version" value to the protocol, in a static
> > >>> (or at least consistent) location, then you could elect not to
> > >>> communicate with incompatible nodes.  Notifying node
> > >>> users of the failure (via a kernel/console message, for
> > >>> example) would then help cluster builders to;
> > >>>
> > >>>   a) avoid building clusters that appear to be highly unstable
> > >>>       due to mismatched protocol versions dumping each
> > >>>       other
> > >>>
> > >>>   b) dodge unpredictable node communication (or node
> > >>>       orphanages) when the "node version lockout" kicks
> > >>>       in
> > >>>
> > >>>
> > >>>   Just a thought.
> > >>>
> > >>>   I don't personally want to have to go through the pain of
> > >>> implementing this type of system in my own library.  But having
> > >>> seen the consequences, thru oM, I'm keen not to let my laziness
> > >>> undermine the quality of the resultant applications that will
> > >>> eventually depend on the lib.  Stability is just too important.
> > >>>
> > >>>
> > >>>   Hope you all scored chocolate .. good luck to the Kiwi's on
> > >>> their big bunny cull this weekend.
> > >>> [http://www.msnbc.msn.com/id/12265571/]
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> Ian Latter
> > >>> Late night coder ..
> > >>> http://midnightcode.org/
> > >>>
> > >>>
> > >>>
> > >>> -------------------------------------------------------
> > >>> This SF.Net email is sponsored by xPML, a groundbreaking scripting
> > >>> language
> > >>> that extends applications into web and mobile media. Attend the
> > >>> live webcast
> > >>> and join the prime developer group breaking into this new coding
> > >>> territory!
> > >>> http://sel.as-us.falkag.net/sel?
> > >>> cmd=lnk&kid=110944&bid=241720&dat=121642
> > >>> _______________________________________________
> > >>> openMosix-devel mailing list
> > >>> openMosix-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> > >>> https://lists.sourceforge.net/lists/listinfo/openmosix-devel
> > >>>
> > >>
> > >>
> > >
> > >
> > > --
> > > Ian Latter
> > > Late night coder ..
> > > http://midnightcode.org/
> > >
> > >
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> > that extends applications into web and mobile media. Attend the live webcast
> > and join the prime developer group breaking into this new coding territory!
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> > _______________________________________________
> > openMosix-devel mailing list
> > openMosix-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> > https://lists.sourceforge.net/lists/listinfo/openmosix-devel
> > 
> 
> 
> --
> Ian Latter
> Late night coder ..
> http://midnightcode.org/
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> openMosix-devel mailing list
> openMosix-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/openmosix-devel
> 


--
Ian Latter
Late night coder ..
http://midnightcode.org/



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642