Re: Network Recommendation

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