Re: Re: xPL bridging loop prevention

[Mark Hindess <xpl@xxxxxxxxxxxxxxxxx>]

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.

I assumed the count was going to have semantics not dissimilar to those
of the IP TTL (counting up instead of down but that's irrelevant).  I
think the TTL semantics are logical and consistent.

I've now written a bridge that I think has as much duplicate detection
as is going to be possible with the current xPL message format.  (Thanks
for helping with your excellent description of how you implemented this
in your bridge.)

I managed to create some great loops while trying to write unit tests.
Obviously running both ends of the bridge on the same machine isn't
normal, but it's very useful for automated unit testing and I can
see people accidentally getting in this kind of mess without much
difficulty.  I'd certainly feel more comfortable if any bridge also had
to incremented the hop count.

> The hop isn't really that useful, IMHO, because it doesn't identify
> where the increments occur.

I see why I gave that impression but I wasn't thinking of it as useful
in the context of duplicate detection.

I think it is useful to stop loops becoming catastrophic but only when
used in the simple sense of never transmitting a message if the hop
count is greater than the maximum (9 IIRC).

Of course, it is definitely only useful if you increment it in all the
places you should be.  I think bridges are just such a place.

Regards,
Mark.