Re: Re: xPL bridging loop prevention

[Mark Hindess <xpl@xxxxxxxxxxxxxxxxx>]

On 26 November 2005 at 11:50, Mal Lansell <mal@xxxxxxx> wrote
>
> 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.

Yes.  That's exactly what I was thinking it should be used for.

> 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.

Ick!  That sounds horrible.

Apart from the "hop >= 9 then drop", I'd not anticipate the
hop count
being used for anything else.  The only exception is that on IP networks
the TTL can be used to derive information about structure of the network
and I would think you could use the hop count for similar things in
"simple" xPL networks, but really 99% of people wouldn't care -
just
like they don't care about it on IP networks.

> 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 :-(

Yeah.  Or with two on the same subnet as my first late night attempt
at a unit test did!  It's worryingly easy to do which is why I wanted
to make sure we agreed to increment the hop count in our bridges.  I
don't think the duplicate message algorithm can be improved within the
confines of the current protocol.  IP networks tend to use sophisticated
routing protocols to avoid creating loops while maintaining redundancy.
xPL in it's current form will have to forego such redundancy or accept
the very significant overhead of loops.

[ The following comments are not a request for change, just food for
thought. ]

It would be possible to do reliable duplicate detection if each message
contained a sequence number - an incrementing integer for instance.
Since you could hash the source and sequence number to get something
that was "unique" - at least until the sequence number overflowed
back
to zero by which time you'd have cleared the cache.

It should be noted that UDP transfer does not guarantee that you wont
get duplicates even without any bridges so strictly they should be
handled gracefully anyway.  Of course, in practice this isn't really
a problem - just as UDP's lack of assurances about order (or indeed
delivery at all) tend not to be an issue when working within a single
subnet.

Whether this sort of thing becomes an issue really depends on whether it
is hoped/intended for xPL to grow beyond simple subnets and perhaps one
or two bridges.

Regards,
Mark.