The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Re: Re: xPL bridging loop prevention


  • Subject: Re: Re: xPL bridging loop prevention
  • From: Mal Lansell <mal@xxxxxxxxxxx>
  • Date: Sat, 26 Nov 2005 11:50:35 +0000

I think it depends on how apps are using hop counts at the moment.  If
they are just doing a "drop message if hop >= 9" approach to
stop a
buildup of looping messages, then fine, lets have the bridges do that
too.  However, if apps are using "hop >= 2" as a way to detect
the first
instance of looping then I'd say no - because the bridge would then
cause these messages to be dropped by other parts of the network.

One thing I noticed with my own bridge design is that even with the
filters, it would still be possible to create a endless message circle
using 3 bridge apps :-(

Mal




Mark Hindess wrote:

>
> [ Answer your own messages is always a bad sign. ;-) ]
>
> On 18 November 2005 at 20:34, Mark Hindess <xpl@xxxxxxx> wrote:
> >
> > On 17 November 2005 at 22:53, Mal Lansell <mal@xxxxxxx>
wrote:
> > >
> > > Actually, no :-)  The hop count should be left as it is.  I
asked this
> > > very same question a few weeks ago, and the answer was that
the hop is
> > > incremented only when the underlying network changes - such
as when a
> > > message moves from an RS232 to an IP network.
> >
> > Oh no, that's another decision, I struggle to understand. :-(
> > I'll have to read the mailing list archive.
>
> Ok.  I've read the previous discussion at:
>
>   http://www.ukha-archive.com/ml/xpl/2005-oct/msg00080.html
>
> specifically statements like:
>
>   it's there are a safety feature given that xpl was always intended
to
>   run across multiple network systems (and therefore encounter
possible
>   bridging issues)
>
> and the statement in the spec that says:
>
>   This is incremented each time the xPL message is transferred from
one
>   physical network to another, for instance by a bridge application
>   passing traffic between an RS485 Serial bus and Ethernet.
>
> It seems to me that my bridge is transferring messages from one
physical
> network to another - wifi to ethernet for instance or just different
> physical ethernets.
>
> I think (and my unit testing has shown!) that if anything it is easier
> to create catastrophic loops with "virtual" links like a
software bridge
> than it will be with bridges that link physical networks.
>
> With this in mind, any bridge code I release will be increasing the
hop
> count by default.  I'd not feel happy releasing code that didn't take
> this simple step to protect users.  Users will have the option to turn
> this behaviour off but I'd certainly not recommend it.
>
> I'm really not trying to be deliberately controversial.  If anyone
> feels that I am please tell me and I'll stop this discussion and, with
> regrets, keep my bridge code private.
>
> Regards,
> Mark.
>
>
>
>
> xPL Links: http://www.xplproject.org.uk http://www.xplhal.com
> http://www.xpl.myby.co.uk
> To Post a Message: ukha_xpl@xxxxxxx
> To Subscribe:  ukha_xpl-subscribe@xxxxxxx
> To Unsubscribe:  ukha_xpl-unsubscribe@xxxxxxx
>
>
>
------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
>     *  Visit your group "ukha_xpl
>       <http://groups.yahoo.com/group/ukha_xpl>"
on the web.
>
>     *  To unsubscribe from this group, send an email to:
>        ukha_xpl-unsubscribe@xxxxxxx
>       <mailto:ukha_xpl-unsubscribe@xxxxxxx?subject=Unsubscribe>
>
>     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
>
------------------------------------------------------------------------
>




xPL Main Index | xPL Thread Index | xPL Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.