[nanomsg] Re: accessing control IDs
- From: Martin Sustrik <sustrik@xxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Wed, 07 May 2014 11:20:37 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Drew,
> I’m not necessarily saying that REQ/REP is wrong on principle, but
> I am saying that there should be much clearer documentation on what
> it is for and what it is not for.
man nn_reqrep
The very first sentence is: "This protocol is used to distribute the
workload among multiple stateless workers."
You are welcome to improve!
>> 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.
>
> I think it is self-evident from my reply to the above, but really
> what i want is a request/reply messaging system that doesn’t shoot
> you if your REP involves saving to a database now and again, and
> lends itself to some authentication scheme other than “configure
> your firewall”. I have actually made a considerable amount of
> progress on the second problem in a private fork, but was hoping
> that a solution on the first problem would be more mergeable and
> keep the topics of my fork to a smaller number.
Yes, sure, as long as it is implemented as a new transport or new
protocol. If you try to violate the boundary between the two layers,
that may be a problem.
> I have come around to your position on implementation, that relying
> on TCP information to derive sessions is not a good approach. So
> perhaps the solution looks like appending 6 bytes to the message
> (although zero-copy is a bit of an issue). However I still believe
> that this is a problem for a networking library to solve and not a
> problem for an application.
Well, the functionality is very specific and easy to misuse. People
would immediately use it to identify peers (rather than treat it as a
hint) and complain once they encounter a situation where it doesn't work.
In the end you would probably be the only person to use it correctly
and there would be lot of others being burn by it.
Btw, I wouldn't expect to see any difference in throughput between 4
byte and 10 byte messages. For small messages the throughput is CPU
bound, not IO bound.
>> 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.
>
> I’m not totally sure what you mean by “state” here.
Business state. Routing tables in network or routing tables in nn
sockets don't qualify.
Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTafrlAAoJENTpVjxCNN9YQikH/1wtR4Dr/1T3mu6p3GY+TJ4o
2cpR4fg/AQpYxCxo7zD3nNrCY1XVRr4uD8QhC+vQ806HdgPpUENU5aFZ3X6WDvzk
qwbRcXNIod7uld0wSH+WO9l58Fa9EdjOq2NefygT2ZAYnzGK19V83a11fX1nox3D
5l4KB7WZ4/jBkRkMoufjPURI9XXeSvO1fBScJ8mTCSGjTyGw3djPEYEq4LBNWFVn
K/B2jeURQvru2H7JOGzB2FTyPY5fXNqHG5xGbo5+iGHek+FHJjO2l2MO72cGG1q2
NkjfRNx8SVUl1pd0MTP60x86tUF3tZFtETTW89MYSmqXodHlAsJxjtN/mDbRgvM=
=gNMk
-----END PGP SIGNATURE-----
Other related posts:
