anchor.diff:  the I/O provider knows it is safe to do so (for example the completion
   is occuring in a context where no locks are held.)
   
  -There is still a lot of performance tuning work to do, and there is a
  -real need to expose the AIO structures to user code, which is something
  -that I will be doing in the coming days.  This should enable a much 
  -faster and lighter weight I/O model, especially for event driven programs.
  -
  -
  -New Transports (ZeroTier)
  --------------------------
  -
  -The other, most critical, motivation behind nng was to enable an easier
  -creation of new transports.  In particular, one client (Capitar IT Group BV)
  -contracted the creation of a ZeroTier transport for nanomsg.
  +The `nni_aio` structures are accessible to user applications as well, which can
  +lead to much more efficient and easier to write asynchronous applications,
  +and can aid integration into event-driven systems and runtimes, without
  +requiring extra system calls required by the legacy _nanomsg_ approach.
  +
  +There is still performance tuning work to do, especially optimization for
  +specific pollers like `epoll()` and `kqueue()` to address the C10K problem,
  +but that work is already in progress.
  +
  +== Portability & Embeddability
  +
  +A significant goal of _nng_ is to be portable to many kinds of different
  +kinds of systems, and embedded in systems that do not support POSIX or Win32
  +APIs.  To that end we have a clear platform portability layer.  We do require
  +that platforms supply entry points for certain networking, synchronization,
  +threading, and timekeeping functions, but these are fairly straight-forward
  +to implement on any reasonable 32-bit or 64-bit system, including most
  +embedded operating systems.
  +
  +Additionally, this portability layer may be used to build other kinds of
  +experiments -- for example it should be relatively straight-forward to provide
  +a "platform" based on one of the various coroutine libraries such as Martin's
  +http://libdill.org[libdill] or https://swtch.com/libtask/[libtask].
  +
  +TIP: If you want to write a coroutine-based platform, let me know!
  +
  +== New Transports
  +
  +The other, most critical, motivation behind _nng_ was to enable an easier
  +creation of new transports.  In particular, one client (
  +http://www.capitar.com[Capitar IT Group BV])
  +contracted the creation of a http://www.zerotier.com[ZeroTier] transport for
  +_nanomsg_.
   
   After beating my head against the state machines some more, I finally asked
  -myself if it would not be easier just to rewrite nanomsg using the model
  -I had created for mangos.
  +myself if it would not be easier just to rewrite _nanomsg_ using the model
  +I had created for _mangos_.
   
   In retrospect, I'm not sure that the answer was a clear and definite yes
  -in favor of nng, but for the other things I want to do, it has enabled a
  +in favor of _nng_, but for the other things I want to do, it has enabled a
   lot of new work.  The ZeroTier transport was created with a relatively
   modest amount of effort, in spite of being based upon a connectionless
   transport.  I do not believe I could have done this easily in the existing
  -nanomsg.
  -
  -In the coming weeks I expect to create transports for TLS, websocket,
  -and websocket over TLS.  I expect the websocket transport to support
  -multiple sockets with different path components bound to the same TCP port.
  -This might be possible with nanomsg, but it wouldn't be easy.  With nng,
  -it looks fairly straight-forward.
  -
  -
  -Towards nanomsg 2.0
  --------------------
  -
  -It is my intention that nng ultimately replace nanomsg.  I do think of it
  +_nanomsg_.
  +
  +I've since added a rich TLS transport, and have implemented a WebSocket
  +transport that is far more capable than that in _nanomsg_, as it can
  +support TLS and sharing the TCP port across multiple _nng_ sockets (using
  +the path to discriminate) or even other HTTP services.
  +
  +There are already plans afoot for other kinds of transports using QUIC
  +or KCP or SSH, as well as a pure UDP transport.  The new _nng_ transport
  +layer makes implementation of these all fairly straight-forward.
  +
  +== HTTP and Other services
  +
  +As part of implementing a real WebSocket transport, it was necessary to
  +implement at least some HTTP capabilities.  Rather than just settle for a toy
  +implementation, _nng_ has a very capable HTTP server and client framework. 
  +The server can be used to build real web services, so it becomes possible
  +for example to serve static content, REST API, and _nng_ based services
  +all from the same TCP port using the same program.
  +
  +We've also made the WebSocket services fairly generic, which may support
  +a plethora of other kinds of transports and services.
  +
  +There is also a portability layer -- so some common services (threading,
  +timing, etc.) are provided in the _nng_ library to help make writing
  +portable _nng_ applications easier.
  +
  +It will not surprise me if developers start finding uses for _nng_ that
  +have nothing to do with Scalability Protocols.
  +
  +== Towards _nanomsg_ 2.0
  +
  +It is my intention that _nng_ ultimately replace _nanomsg_.  I do think of it
   as "nanomsg 2.0".  In fact "nng" stands for "nanomsg next generation" in
   my mind.  Some day before too long I'm hoping that the various website
  -references to nanomsg my simply be updated to point at nng.  It is not
  +references to nanomsg my simply be updated to point at _nng_.  It is not
   clear to me whether at that time I will simply rename the existing
  -code to nanomsg, nanomsg2, or leave it as nng.  (One possible issue is
  -that Martin Sustrik retains the trademark for "nanomsg".)
  +code to _nanomsg_, nanomsg2, or leave it as _nng_.
  
positive.code: from one process to another you may have to execute up to 6 extra system
  calls, beyond the 2 required to actually send and receive the message.
  
  There are cases where this file descriptor logic is easier for existing
  applications to integrate into event loops (e.g. they already have a thread
  blocked in poll().)
  
  But for many cases this is not necessary.  A simple callback mechanism
  would be far better, with the FDs available only as an option for code
  that needs them.  This is the approach that we have taken with nng.
  
  As another consequence of our approach, we do not require file descriptors
  for sockets at all, so it is possible to create applications containing
  many thousands of inproc sockets with no files open at all.  (Obviously
  if you're going to perform real I/O to other processes or other systems,
  you're going to need to have the underlying transport file descriptors
  open.)
  
  
  POSIX APIs
  ----------
  
  Another of Martin's goals, which seems worthwhile at first, was the
  attempt to provide a familiar BSD POSIX API.  As a C programmer, this
  really attracted me.
  
  The problem is that the POSIX APIs are actually really horrible.  In
  particular the semantics around cmsg are about as arcane and painful as
  one can imagine.  Largely, this has meant that extensions to the cmsg
  API simply have not occurred in nanomsg.
  
  The cmsg API specified by POSIX is as bad as it is because POSIX had
  requirements not to break APIs that already existed, and they needed to
  shim something that would work with existing implementations, including
  getting across a system call boundary.  nanomsg  has never had such
  constraints.
  
  Attempting to retain low numbered "socket descriptors" had its own
  problems -- a huge source of use-after-close bugs, which made the
  use of nn_close() incredibly dangerous for multithreaded sockets.
  (If one thread closes and opens a new socket, other threads still using
  the old socket might wind up accessing the "new" socket without realizing
  it.)
  
  The other thing is that BSD socket APIs are super familiar to UNIX C
  programmers -- but experience with nanomsg has taught us already that these
  are actually in the minority of nanomsg's users.  Most of our users are
  coming to us from C++ (object oriented), Java, and Python backgrounds.
  For them the BSD sockets API is frankly somewhat bizarre and alien.
  
  With nng, we realized that constraining ourselves to the mistakes of the
  POSIX API was hurting rather than helping. So nng provides a much friendlier
  interface for getting properties associated with messages.
  
  In nng we also generally try hard to avoid reusing
  an identifier until no other option exists.  This generally means most
  applications won't see socket reuse until billions of other sockets
  have been opened.
  
  
  Compatibility
  -------------
  
  Of course, there are a number of existing nanomsg consumers "in the wild"
  already.  It is important to continue to support them.  So I decided from
  the get go to implement a "compatibility" layer, that provides the same
  API, and as much as possible the same ABI, as legacy nanomsg.  However,
  new features and capabilities would not necessarily be exposed to the
  the legacy API.
  
  Today nng offers this.  You can relink an existing nanomsg binary against
  nng instead of nanomsg, and it usually Just Works.  Source compatibility
  is almost as easy, although the application code needs to be modified
  to use different header files.  (Note: I am considering changing this
  in the future.)
  
  
  Asynchronous IO
  ---------------
  
  As a consequence of our experience with threads being so unscalable,
  we decided to create a new underlying abstraction modeled largely on
  Windows IO completion ports.  (As bad as so many of the Windows APIs
  are, the IO completion port stuff is actually pretty nice.)  Under the
  hood in nng all I/O is asynchronous, and we have `struct nni_aio` objects
  for each pending I/O.  These have an associated completion routine.
  
  The completion routines are _usually_ run on a separate worker thread
  
negative.code: 
  I did find another approach which is discussed further.
  
  === File Descriptor Driven
  
  Most of the underlying I/O in _nanomsg_ is built around file descriptors,
  and it's internal usock structure, which is also state machine driven.
  This means that implementing new transports which might need something
  other than a file descriptor, is really non-trivial.  This stymied my
  first attempt to add http://www.openssl.org[OpenSSL] support to get TLS
  added -- _OpenSSL_ has it's own `struct BIO` for this stuff, and I could
  not see an easy way to convert _nanomsg_'s `usock` stuff to accomodate the
  `struct BIO`.
  
  In retrospect, _OpenSSL_ wasn't the ideal choice for an SSL/TLS library,
  and we have since chosen another (https://tls.mbed.org[mbed TLS]).
  Still, we needed an abstraction model that was better than just file
  descriptors for I/O.
  
  === Poll
  
  In order to support use in event driven programming, asynchronous
  situations, etc. _nanomsg_ offers non-blocking I/O.  In order to make
  this work for end-users, a notification mechanism is required, and
  nanomsg, in the spirit of following POSIX, offers a notification method
  based on `poll(2)` or `select(2)`.
  
  In order for this to work, it offers up a selectable file descriptor
  for send and another one for receive.  When events occur, these are
  written to, and the user application "clears" these by reading from
  them.  (This is done on behalf of the application by _nanomsg_'s API calls.)
  
  This means that in addition to the context switch code, there are not
  fewer than 2 extra system calls executed per message sent or received, and
  