Re: Network Recommendation

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