Re: xPL bridging loop prevention

["Mal Lansell" <mal@xxxxxxxxxxx>]

--- In ukha_xpl@xxxxxxx, "Mark Hindess" <xpl@b...> wrote:
>
>
> A little while ago, when I asked about bridging subnets, Mal was
kind
> enough to point me at an xPL hub for .net.  I took a quick look but
> didn't grab a copy and it's disappeared now.  I feel stupid not
grabbing
> it while I could because it might have helped me answer my current
> question.
>
> I've decided I definitely do need to bridge some packets.  (At
least,
> OSD messages to the wifi Fujitsu tablet PCs I'm putting on a
couple of
> walls in my house.  So I started writing a bridge to test out my
Perl
> code.
>
> I hit a slight problem.  I started doing the obvious things to
prevent
> loops using a simple cache of hashes of messages the bridge has
seen,
> but it catches some packets that it shouldn't.  Specifically if
someone
> sends two identical x10 bright messages in quick succession, they
have
> the same text in them and so their hashes match and the second is
> suppressed and lights remain dim.  ;-(
>
> I'm a bit stumped as to how to handle this correctly.  Anyone know
how
> the .net version handled this problem?  Or have any suggestions?
>
> Regards,
>  Mark.
>

I'm actually quite a way through writing a non-.NET replacement.  No
use to you of course because you're running in Linux, but I do have
a solution for the problem you mention.

All messages received from the bridge should be broadcast to the
local subnet.  The only blocking you need to do is on the messages
you intend to send over the bridge.

The messages you need to block are the ones that are received are
received from the bridge, broadcast and then received back from the
local hub.  The problem of blocking duplicates will only occur when
identical messages are generated by both a local application and one
on the other side of the bridge - this is very unlikely, but it can
still be avoided.

The trick is to store a list of hashes that allows multiple entries
with the same value.  Each time a message is received from the
bridge, it is hashed and the hash value added to the list.  When a
message is received from the local hub, it is hashed and the list
searched for a match.  If a match is found, the message is not sent
over the bridge, <b>and that entry is deleted from the
list</b>.  If
two identical messages were received, but only one originated from
the other side of the bridge, there would be only one matching hash
in the list, and therefore only one message would be blocked; the
other would be passed as normal.

To avoid the list of hashes growing if a problem occurs with the
hub, hashes should be deleted from the list after a short time (even
a timeout as low as a second should be enough, but you can make it
longer to be on the safe side).

HTH

Mal


You are unlikely to receive a message originating from the local
system