[nanomsg] Re: different protocols, parameters

  • From: Paul Colomiets <paul@xxxxxxxxxxxxxx>
  • To: "Garrett D'Amore" <garrett@xxxxxxxxxx>
  • Date: Tue, 11 Mar 2014 19:24:07 +0200

Hi Garrett,

On Tue, Mar 11, 2014 at 6:56 PM, Garrett D'Amore <garrett@xxxxxxxxxx> wrote:
>
> On Tue, Mar 11, 2014 at 6:20 PM, Garrett D'Amore <garrett@xxxxxxxxxx> wrote:
>> c) create new socket options, for passing these parameters. These are the
>> closest fit to existing practice, but it gets muddier if you want to
>> support
>> different options for different underlying connection paths.
>
> I'd vote for this one. It doesn't create another ABI incompatibility with
> each
> new setting and so on. Scripting languages can have arbitrary convenience
> functions on top of raw API.
>
> I'm less concerned about C ABI compatibility *right* now... and more
> importantly, I think any one accessing these services / transports is going
> to need to write new code.  Adding functions to the ABI doesn't break
> existing ABI or applications.
>
> If you don't have a new enough version of the library, you won't be able to
> access those transports, but that's to be expected.  This way you'd get a
> link error in your application at least, rather than waiting to discover it
> later when you tried to actually *run* the app.
>

It's hard to explain in few words. Just believe me it matters :)

>>
>> Btw, it should also be relatively trivial (again in Go, where we have nice
>> API support) to create a nanomsg transport on top of HTTP, where each
>> message is an HTTP exchange. In that case, we'd have just normal http: and
>> https: URIs as our addresses.
>
> So how different patterns would map into HTTP? HTTP is only for
> request-reply.
>
> So is IP.   But TCP, and nanomsg, build on top of these to create reliable
> message oriented communications channels.
>
> So the "transport" provider would create a "channel" by sending packets over
> these http connections.  The most interesting pattern here is a SUB client,
> I think.  I imagine it working like this:
>
> 1. client connects to server and negotiates subscription token
>
> 2. client sends new HTTP request with aforementioned token
>
> 3. client waits for published message from server
>
> 4. if message received, go to step 2 to get next message
>
> 5. if message failed, or disconnected, return to step 1
>
> This isn't so *very* different than the existing nanomsg loop, just a
> slightly different state machine.
>

Looks like long-polling a/k/a COMET. Please don't introduce this
kind of crap into nanomsg. It's used by browsers, because there
is not always a way to use websockets. But that's a different
story.

That said, I'll make long-polling by HTTP when I'll be porting
zerogw to nanomsg, but that's quite a different story, than provide
a HTTP transport for nanomsg.


> 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!

-- 
Paul

Other related posts:

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