[nanomsg] Re: inquiry - nanomsg API

  • From: Martin Sustrik <sustrik@xxxxxxxxxx>
  • To: nanomsg@xxxxxxxxxxxxx
  • Date: Mon, 01 Jun 2015 11:24:43 -0700

Garrett,

One thing to consider would be using libuv. It's C, well maintained, portable between unix/windows and does most of the stuff that nanomsg aio classes do now.

Martin

On 2015-06-01 09:51, Michael Powell wrote:

On Sun, May 31, 2015 at 6:38 PM, Garrett D'Amore <garrett@xxxxxxxxxx> wrote:
All,

I’ve been contemplating for a while now, the idea of basically building a new C11 version of nanomsg from the ground up. As I’ve spent more time in the original libnanomsg code, I’ve become convinced this is absolutely necessary for my own sanity.

I’m curious to better understand what things in libnanomsg people depend upon — because some of the design goals that Martin originally laid out would be difficult to achieve without the complexities in the code that are responsible for some of my headaches. :-)

So, if you rely on any of the following, and would find the absence thereof grievous, I’d like to know. (I.e. would the absence of these things make it impossible for you to consider adopting a new implementation?) I’m especially interested in hearing from folks responsible for maintaining ports of nanomsg to different runtime environments (plugins via FFI calls and such.)

So:

1. File descriptor based interface? Is it important that you are able to mix and match other kinds of file descriptors with nanomsg sockets?

- why problematic: file descriptors create challenges for transports that might not be file descriptor based at all, such as inproc, or OpenSSL (which uses a different handle structure), etc. Supporting plugin transports is not going to be easy to do with this requirement.

2. Non-blocking I/O? Do you use NN_DONTWAIT in your application(s)? Would a “blocking” API using threads work instead for your application? Also, do you nn_poll()?

- why problematic: mixing non-blocking I/O with regular blocking operations is pretty miserable, and the source of many bugs in libnanomsg and in calling code. In my experience a blocking call, with a timeout if needed, is better, although I concede that some runtimes — those without threads, are going to be hampered by this. Also, to get these semantics, the library does some fairly horrible things — a separate file is opened a single byte message is sent as an alert to allow folks wanting access to poll & co to be seen.

My professional opinion is that non-blocking is essential. Sometimes
in the form of a thread, definitely at the socket level (with or
without timeout), sometimes also with a callback. Speaking in terms of
C++0x/1y of course, neither here nor there for operational purposes.

Service-bus-isms, i.e. persisting messages until they can be sent, is
a wholely separate concern from the transport layer IMO; the API
shouldn't necessarily care whether that's to a file (or file system),
database, etc.

3. Threads in general? Do you have a platform where threads (using C11 style threading or some portable library using pthreads or Windows threads) won’t be possible?

- why problematic - the only way to truly work around the absence of threads is a crazy level of indirection and non-blocking I/O — frankly you wind up with the umpteen zillion state machines that we already have, and which are responsible for most of the current headaches in libnanomsg.

I've heard a couple of good talks on taming complexity; sometimes it's
necessary, only if it's necessary. But not simply for the sake of
having it.

Basically, what I’m contemplating is a design that uses C11 style threads and locking, along with an approach that is internally far closer to what I’ve done in mangos (the Go implementation). I think that I’ll be able to achieve that fairly in straight order. But I’m going to have to ditch some of the design goals that Martin has set forth for libnanomsg. Ultimately I think that will lead me to a more extensible, and more performant, and more robust, implementation of the protocols. My experience with mangos gives me some confidence in this regard.

I haven't been following the Google / Go / mangos developments all
that closely, so not sure how much of what is hype, to tell you the
truth. But from the sounds of it, mangos may be gaining some traction
in these area(s)?

Generally, whenever I've approached messaging of any sort, I've
followed basic design principles of separation of concerns, separating
the application (i.e. messaging, framing, etc) and transport (i.e.
socket, blocking, etc). Mixing the two is usually a recipe for
needless complexity.

Thanks.

That's my two cents. HTH

- Garrett




Other related posts: