[nanomsg] Re: different protocols, parameters

  • From: Garrett D'Amore <garrett@xxxxxxxxxx>
  • To: Paul Colomiets <paul@xxxxxxxxxxxxxx>
  • Date: Tue, 11 Mar 2014 12:28:53 -0700



> On Mar 11, 2014, at 11:46 AM, Paul Colomiets <paul@xxxxxxxxxxxxxx> wrote:
> 
> Hi Garrett,
> 
>> On Tue, Mar 11, 2014 at 7:58 PM, Garrett D'Amore <garrett@xxxxxxxxxx> wrote:
>> Can you shed any more light on the matter?
> 
> From the top of my head:
> 
> 1. If encryption is done using socket options. Current python bindings
> will just work, without any effort of binding maintainers (many other
> similarly)
> 
> 2. Same can be done for nanoconfig and topologist and similar tools

I see.  I guess for folks dealing with wrappers around nanomsg it's easier not 
to add new API calls.  The situation is different in go or with another native 
language implementation.  Indeed it would be different for applications written 
in C.  

> 
> 3. If application support encryption optionally it will not fail with
> linker error on old version of library but rather not provide
> functionality (by returning EINVAL from nn_setsockopt)

It's unclear to me which behavior is most desirable.  I see trade offs either 
way.

> 
>>> Good point! But you still need access to a transport to the peer. That's
>>> not always possible in a web server environment. (I guess maybe you do get
>>> stdin/stdout though?)
>> 
>> Not sure what you mean. Probably you want something like,
>> the ``--exec`` option for nanocat, which will work something like this:
>> 
>> $ nanocat --rep -Xsock --exec sh -c 'echo Hello, $1!' &
>> $ nanocat --req -Axsock --data "Nanomsg"
>> Hello, Nanomsg!
>> 
>> Admittedly I've not played around much with nanocat.  But you're using IPC
>> transports (sock).  Imagine that instead of using a socket, you want to use
>> stdin for recv, and stdout for send, and the "connect" operation was handed
>> to you already formed.  That's the sort of environment that I think a script
>> running in a webserver gets.  Similar to things running out of inetd,
>> actually.  Its a hack, and you definitely don't want to use it on a client
>> side.  But for a simple req style server, where the service is a trivial RPC
>> style backend, hey, it would work fine.  After all, req sockets don't need
>> to do anything special, and they don't reconnect.  The reconnect/retry is
>> done by the client.
> 
> That's what I meant with --exec option. It would execute a
> command-line and forward a message to it, then read it's stdin and
> send that data back as a reply. Implementing such an option is easy
> and straightforward unlike the nanomsg -> CGI mapping.

Ah.  Got it. 
> 
> -- 
> Paul

Other related posts:

  1. Home
  2. nanomsg
  3. Archive
  4. 03-2014