[nanomsg] Re: understanding of BUS protocol
- From: Garrett D'Amore <garrett@xxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx, Martin Sustrik <sustrik@xxxxxxxxxx>
- Date: Thu, 10 Apr 2014 01:05:14 -0700
On April 10, 2014 at 12:34:28 AM, Martin Sustrik (sustrik@xxxxxxxxxx) wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Garrett,
Thanks for your reply Martin.
> a) is my interpretation of the BUS protocol code correct? (I
> suppose I could write some tests… :-)
BUS protocol is trying to simulate broadcast-style messaging as
commonly used in the financial services industry.
To get an idea, check PGM (RFC 3208).
I’ll have a look.
In short, any message sent by anyone gets delivered to everyone else
in the topology. The protocol is not fully reliable.
Right. I think my implementation has the same attributes. Everyone gets a
copy of the message *provided* that buffers for receipt are available. There
is no back-pressure applied — we just drop packets that are undeliverable.
It's not a nicest communication pattern out there, but it's used by a
lot of applications, so nanomsg tries to support it.
Sure.
As for the actual implementation, it's not set in stone and if you
find a better way to implement it, we can change nanomsg as well.
Finally, the tagging of the message is done so that when a nn_device()
gets a message, it will route it forward to everyone, except for the
peer it received it from. If this was not the case, any device in the
topology would result in infinite sending of the same message back and
forth.
I understand that is why you were using the pipe in the header. My
implementation achieves the same thing, by moving this “device” functionality
into the protocol itself. In other words, anytime someone in the bus gets a
message, he sends it to everyone *except* the pipe he got it from. I do this
immediately, without needing to push it up to the application (the device in
this case) to do the forwarding.
What this means is that each “bus” acts as a local star (usually — although I
guess you could have a client dial multiple different servers and have it act
as a point.) I am assuming that we are not a fully mesh connected network, but
more like a star.
We can connect multiple stars together with devices. But if there is a loop in
the network, it will not be possible to prevent message
duplication/amplification with just the sender ID. You’d really need to
introduce a TTL, along the lines of IP networking. I don’t think we want to
get into that. Applications should just take care not to create loops.
Once again, if you have a better idea about implementing devices in
BUS topologies, feel free to propose it.
> b) what are the opinions folks have on the semantics? I happen to
> think my semantics are more elegant for the application. But maybe
> I’m missing some point? I *definitely* think that these semantics
> are better for BUS. I can imagine that for XBUS, giving this to
> the application *may* be interesting. But I really really don’t
> like giving pointers to applications as part of the message
> contents — even in the header. :-)
I think assuming there's only one device in the topology is too limiting.
The typical use case for more complex topologies would by two
datacenters, connected via WAN. In each datacenter the local bus runs
on top of PGM, but there's a device in each datacenter that consumes
the PGM messages and sends them to the other datacenter via TCP. At
the same time it consumes TCP messages from the remote datacenter and
re-boradcast them on the local network.
Does that make sense?
Yes. In this topology you really would have two stars connected by a device.
I guess the device could reside either in the application layer (two separate
sockets), or by connect() from one side to the next (you have to figure out
which one does the connect and which ones does the accept, to avoid creating a
tiny loop, though.)
What do you think?
> c) If my API semantics are different from nanomsg’s (but the wire
> protocol is compatible), is this going to cause grief?
The semantics of the socket are part of the spec (see the req/rep
RFC). That ensures that a topology will behave in a consistent and
predictable manner, even if composed from different implementations of
the protocol (similarly to. say, how TCP specification specifies
semantics of packet re-retransmission).
Right. I hope that the semantics here are “right” — certainly the underlying
behavior should be compatible. The question really looks to me more like do we
expect the device functionality to be performed up in the application, or
handled further down in the protocol itself. I think the latter is far more
robust and elegant. You can still build devices to cross topologies or do
“conditional” forwarding, etc., but within a local star (or even group of
stars) the protocol can take care of it entirely without application help.
- Garrett
Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTRkljAAoJENTpVjxCNN9YgLoIAJszCWqELr7vgLuraODZPWux
96GDe5XkVvC89fTwO8RBWnaoi+pHM5hdOAfZK4HxmEm1DXVptpBP91py0DwKDs1S
j1UvJmUCKGRZileJrBOCRl1cGkhRftpI4LGG1iMpluhhwAhBo2wYLEUjzZFFCYrn
nGb8QQCo55j6mvl6+IAn4W7aMbLq5VSeSbkwA0G5lHRbp52Qn7Wl/ZqARHHXZreU
fSo2mZojXz0a7ptdM7GlklmOIHud+XUhFDtIojdj9bd9rWyCMlr67/2TENtWtkMg
MmM5fYbdttnsqufeUyjWIBMfrSUo4eyQLJhM26AAPvBDbvMRtK7/360I7NAMeQE=
=IGxE
-----END PGP SIGNATURE-----
Other related posts:
