[nanomsg] understanding of BUS protocol
- From: Garrett D'Amore <garrett.damore@xxxxxxxxxxxxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Thu, 10 Apr 2014 00:14:22 -0700
I implemented a BUS protocol recently on my SP implementation, and I didn’t
have nanomsg sources handy. I went back to look at nanomsg and I found some
discrepancies.
So, in *my* implementation, I treat XBUS and BUS identically. In both cases,
the following are done:
* there is exactly one server in the bus (the one that runs
listen/accept)
* there may be many clients in the bus. (i.e. the “bus” is really a
star topology bus, like ATM for folks who recall such tech)
* send from a client sends to the server, and the server rebroadcasts
to all connected clients *except* the one that received the message. it also
keeps a copy of the message for recv() for itself.
* send from the server broadcasts to all connected clients.
* recv at the server rebroadcasts (excluding the originator) *even if*
the server upper queue is full (meaning there is no
requirement for the application to recv() at the server to allow messages to
rebroadcast
* the messages on the wire are passed around without any extra header
* the messages passed to user (for both protocols) are also unmodified
— no header is added needed
I *think* that nanomsg behaves mostly the same. HOWEVER, I do notice that it
appears that XBUS is a little different. In particular, it appears that XBUS
adds the received pipe information as part of the header to the inbound
message, and on sends optionally uses that to determine who to resend to. It
looks like the idea is to give the message to the server, and require the
application on the server to do the rebroadcast. This seems kind of silly, and
fragile, although it helps that I have a reference counting system on messages
so that I don’t have to copy data to rebroadcast.
The questions thus are:
a) is my interpretation of the BUS protocol code correct? (I suppose I
could write some tests… :-)
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. :-)
c) If my API semantics are different from nanomsg’s (but the wire
protocol is compatible), is this going to cause grief?
--
Garrett D'Amore
Sent with Airmail
Other related posts:
