[nanomsg] Re: understanding of BUS protocol
- From: Martin Sustrik <sustrik@xxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Thu, 10 Apr 2014 11:10:01 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/04/14 10:47, Garrett D'Amore wrote:
> In the everyone to everyone case what keeps the packets from
> getting stuck in a loop? Any cycle would be tragic right? I think
> a TTL is required.
No. The trick is that BUS socket doesn't forward the messages
automatically. It just passes any message it gets to the user and
that's it.
So, if you have a mesh with no devices, you are perfectly OK.
As for devices, they are special applications that re-send every
delivered message back to the socket it was received from. The socket
is then responsible for not forwarding the message to the original sender.
Of course, device admin must make sure that the device connects two
otherwise un-connected meshes. If that's not the case, infinite loops
will happen.
I admit that the design is kind of ugly, but that was the best I could
thought of at the time.
> I'm not sure I like exposing pipe ids to applications. It's
> needed in your implementation because the forwarding is done by the
> app rather than by the library. In my implementation the forwarding
> is handled without the apps awareness.
>
> I think non star graphs will work in my case just as well as yours.
> I think both will suffer catastrophically in a true mesh or any
> other arrangement with cycles in it. The only way I know to fix
> that is to break the cycle with logic at the application. That can
> be done with a device using two sockets explicitly. You can do
> that today with either implementation.
The architecture would be definitely cleaner that way. What made me go
the other was that I wanted to have just a single type of device,
rather then one hub-like and one gateway-like device. For all other
patterns, at least, we have only one device type.
Also, AF_RAW sockets for all other patterns allow for message
interception/filtering/tagging/modification. If the forwarding is done
inside the socket, the application won't be able to do that.
If you have a sane way to address these issues, I'd be happy to change
the design.
> Essentially my approach automates the bus logic. The only messages
> a non device app ever needs to explicitly send are those it is
> originating.
Same is true of for the existing model.
Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTRl/pAAoJENTpVjxCNN9YtXkH/2HpRANw0iNh7dvQ+4kgAS2y
tVvydncaoXCykTvyynb8T7eFoaF5dVKw7ECDC0XKcptfcil6KaG8XAAcXVjZ4qQe
DdkTB1XNcmOrDjk1evaRuA+dgfkM8UcrZ9oTekuzcM6dRwbCGRLxmyvS9S5Q/bjY
7sAuY8SMnkiCLHTd12aeoYEdXVf7K2yCS5ZyYhWaxEDkQo6KNbMZ60STBaOAsppP
5fqt9rYaPXxgRmJ85m4IlcuovYgIVF0zloDyQmDTSqYnAkCP3199towQjbkC56K3
YUgsg7mGEFcvApg7iNepB/stKGxmsa/0oQiwdcrF7HjQ9uIDLdNrHcEkQiM3Xdw=
=t+C7
-----END PGP SIGNATURE-----
Other related posts:
