[nanomsg] Re: accessing control IDs
- From: Martin Sustrik <sustrik@xxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Wed, 07 May 2014 08:12:39 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/05/14 05:13, Drew Crawford wrote:
>> Nanomsg is stateless from the point of view of the app. Adding
>> session state would be inappropriate.
>
> I have seen this stated several times in this thread, but I have
> not seen any design justification for this position. Such a
> position should be defensible.
The reason is that REQ/REP is meant for a very specific use case:
Assembling multiple servers into a CPU sharing topology.
Processing is load-balanced among the cluster but that only works if
there's no state on the nodes.
Same applies to reliability. REQ/REP is reliable because it can resend
any messages that were lost or not processed in time. Here the
assumption is that the message will go to a different node the next
time as the old one may be broken or dead. For this to work there
can't be any state stored on the processing nodes.
> I can construct a rationale for why there should be a
> REQ-REP-*like* protocol that is stateless. That would clearly be
> useful. However, in my view it is an error to give it the name
> REQ/REP, because this is confusingly similar to the ZeroMQ protocol
> with the same name. It would be tolerable if nanomsg REQ/REP was
> merely API-incompatible and wire-incompatible with the protocol
> from ZeroMQ; that is to be expected. However when the difference is
> not just in wireformat or argument order but is actually
> conceptually orthogonal to the way ZeroMQ REQ/REP is used (which is
> stateful) in a way that is hard to see up front it is time to
> invent a new name for a new idea. The connection between the two
> protocols is so flimsy that sharing a name is actively misleading.
I've designed ZeroMQ REQ/REP and I can tell you that it was intended
to be stateless. What's done today with the ROUTER socket is a hack
similar to, say, if you hacked your TCP endpoint to send unreliable
UDP-like packets.
> That aside, you are taking a much stronger position than merely
> one protocol. You are saying “nobody should implement a stateful
> protocol in nanomsg”. Well, why not?
Exactly, that's the question! Why yes or why not?
- From my point of view, if I wanted to speak to a specific peer, I
would use TCP. That's what's it was designed for and what it is good at.
Both ZeroMQ and nanomsg, on the other hand, were designed to speak to
a cluster of peers. If you try to emulate TCP on top of that, you'll
have to fight all the nanomsg features that will get into your way.
So, why do it at all?
> Clearly many applications have stateful networking problems. How
> should they solve these problems?
>
> * Should they each implement state atop nanomsg in their own
> incompatible way? This is duplication of effort, and probably
> leads to buggy code * Should somebody consolidate those stateful
> implementations into a library that sits atop nanomsg? Now
> language bindings have to be written for that library in addition
> to nanomsg. This is duplication of effort, and probably leads to
> buggy code * Should these applications not use nanomsg at all, and
> instead use ZeroMQ? But there are many reasons to prefer nanomsg
> including use of C, BSD socket API, context-free implementation,
> pluggable transports, routing priorities, zero-copy, etc. etc.
> This option basically tells applications “because you have stateful
> networking, you can enjoy none of these benefits” * Should these
> applications fork nanomsg and hack in a stateful alternative? This
> is duplication of effort, and probably leads to buggy code
>
>
> I think what you imagine is that if you make stateful programs
> difficult, people will rethink their stateful problems into
> stateless ones. Sometimes that is true. But other times, people
> will rethink their stateful programs and decide being stateful is
> the right decision for their problem. There should be some vision
> to address this case other than “deal with it”.
>
> It is one thing to declare stateful problems out of scope for a
> protocol. It is a different thing to declare them out of scope for
> a networking library. People have stateful problems; and this
> doesn’t disappear merely because stateless protocols are
> well-behaved or more scalable.
>
> I don’t know exactly what the right solution looks like. Maybe
> it’s creating protocols that are deliberately stateful. Maybe
> it’s introducing some kind of pluggable session layer. But I am
> absolutely certain that throwing up our hands and declaring
> anything stateful as out of scope would move nanomsg out of the
> “zeromq done right” search space and turn it into a very
> specialized tool for very specialized problems.
I would suggest you just create a new protocol for stateless messaging
and try to implement that. You'll see what kind of problems you'll run
into.
On a tangent, here's my networking equivalent to the CAP theorem.
Sustrik's theorem: You can't have *P*artition, *S*tate and
*R*eliability at the same time.
Note that REQ/REP goes for PR, while PUB/SUB or SURVEY goes for PS.
Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTac7XAAoJENTpVjxCNN9YS/AIAJ2f/Exo9hXuNE0db+ppPEz6
jmLdqxf8Td24KspbnDBQ0UFoTvwowfFXzqocy3a+bCuD5bDdtyelArgLV8i+x9D5
YAkDHsFIIf+ggBImULfwlXYbTI51fQD9PE2/md3ex8/pGkhI1fM025st8KRIzL6i
1++a3IdK5LdBcC8Z/NuP1W35TaD2GWA5sNhHh7bXw75YUqcRjYb7c4SoQiH3IGb+
Sn8yc38AjUthoTmVlQMe54J5ENDbZqjlHdH3afF8ItXFvIgzpJs++XCBgivGetUg
HW67wtQ/tQsucJBuz1YrANQ/c33+CKH/VnoCTNLkn6VPSgtAu8/JcLyaw859YtM=
=DFye
-----END PGP SIGNATURE-----
Other related posts:
