[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: