[nanomsg] Re: accessing control IDs
- From: Garrett D'Amore <garrett@xxxxxxxxxx>
- To: Drew Crawford <drew@xxxxxxxxxxxxxxxxxx>, nanomsg@xxxxxxxxxxxxx
- Date: Wed, 7 May 2014 02:06:35 -0700
On May 7, 2014 at 1:51:37 AM, Drew Crawford (drew@xxxxxxxxxxxxxxxxxx) wrote:
It’s easy to say “you want TCP” but the reality is I want a request/reply
system on TCP. Which is, in a very literal sense, what nanomsg is. It takes
messages of arbitrary length and moves them along a TCP stream in a reasonable
way; certainly more reasonable than whatever I would come up with left to my
own devices.
The thing is that nanomsg exposes request/reply without sessions; and TCP
exposes sessions without request/reply. I shouldn’t be forced to choose; this
should be stackable. There should be a way to get request/reply messaging and
sessions at the same time in the same API.
You’re missing a key point, which is that nanomsg can reschedule requests on
TCP sessions. In other words, you can’t trust that a given TCP connection used
for a request is going to be the same one that the reply arrives on.
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.
Perhaps. But what I’m really hearing still is that you just want the tiny
subset of the req/rep pattern that is really like a send/recv. You already
have a reliable TCP stream. Why not use the message oriented APIs for TCP
(i.e. sendmsg, recvmsg — or if you’re on System V, the TLI calls — and dispense
with nanomsg altogether? To be honest, once you have a reliable stream — i.e.
TCP — underneath, you gain nothing from nanomsg.
You *could* build a stateful library to provide more resilience (reconnects,
etc.) and state tracking on top of nanomsg, but really I think all it looks
like is prepending your message with a few extra bytes (your unique IDs), and
your application can figure out what those things mean. Asking nanomsg to
“track” these things (as in somehow save them, restore, and manage them) feels
totally 100% wrong to me. These “session ids” (for want of a better term) are
totally centric to your application. Its not even clear to me what a session
ID would *mean* in the context of something like nanomsg.
Your “authentication” challenges are a different matter entirely. Stateless
authentication of req/rep is something that *can* reasonably be done by the
transport, and indeed its trivial to do with TLS. The TLS transport isn’t
written for nanomsg itself yet (I’ve started it!), but my own mangos
implementation does offer a TLS transport. Unfortunately I’ve not yet added
the necessary API hooks for applications to retrieve the transport specific
data (the peer cert in this case) but I plan to do so. But note again, we’re
*not* talking about stateful sessions, even if TCP and/or TLS may use stateful
sessions under the covers — we don’t count on nanomsg to provide this and we
don’t expose state tracking to applications.
- Garrett
Other related posts:
