Re: Network Recommendation

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