anchor.diff:        for nanomsg vs. ZeroMQ.
   
   
  -Background
  -----------
  -
  -I became involved in the nanomsg community back in 2014, when
  -I wrote https://github.com/go-mangos/mangos[mangos] as a pure Golang
  -implementation of the wire protocols behind nanomsg.  I did that work
  -because I was dissatisfied with ZeroMQ's licensing and C++ baggage, and
  -I needed something that would work with Golang on Solaris, which at the time
  -lacked support for cgo (so I could not just use an FFI binding.)  This gave
  -me a lot of detail about the internals of nanomsg and the SP protocols.
  +== Background
  +
  +I became involved in the
  +http://www.nanomsg.org[nanomsg] community back in 2014, when
  +I wrote https://github.com/go-mangos/mangos[mangos] as a pure
  +http://www.golang.org[Go] implementation of the wire protocols behind
  +_nanomsg_.  I did that work because I was dissatisfied with the
  +http://zeromq.org[_ZeroMQ_] licensing model
  +and the {cpp} baggage that came with it. I also needed something that would
  +work with _Go_ on http://www.illumos.org[illumos], which at the time
  +lacked support for `cgo` (so I could not just use an FFI binding.)
  +
  +
   At the time, it was the only alternate implementation those protocols.
  -
  -It would not be wrong to say that one of the goals of mangos was to teach
  -me about golang.  It was my first non-trivial golang project.
  -
  -While working with mangos, I wound up implementing a number of additional
  +Writing _mangos_ gave me a lot of detail about the internals of _nanomsg_ and
  +the SP protocols.
  +
  +It would not be wrong to say that one of the goals of _mangos_ was to teach
  +me about _Go_.  It was my first non-trivial _Go_ project.
  +
  +While working with _mangos_, I wound up implementing a number of additional
   features, such as a TLS transport, the ability to bind to wild card ports,
   and the ability to determine more information about the sender of a message.
   This was incredibly useful in a number of projects.
   
  -I initially looked at nanomsg itself, as I wanted to add a TLS transport
  +I initially looked at _nanomsg_ itself, as I wanted to add a TLS transport
   to it, and I needed to make some bug fixes (for protocol bugs for example),
   and so forth.
   
  -
  -State Machine Madness
  ----------------------
  -
  -What I ran into was a challenging mess of state machines.
  -nanomsg has dozens of state machines, many of which feed into others,
  -such that tracking flow through the state machines is incredibly painful.
  +== Lessons Learned
  +
  +Perhaps it might be better to state that there were a number of opportunities
  +to learn from the lessons of _nanomsg_, as well as lessons we learned while
  +building _nng_ itself.
  +
  +=== State Machine Madness
  +
  +What I ran into in _nanomsg_, when attempting to improve it, was a
  +challenging mess of state machines. _nanomsg_ has dozens of state machines,
  +many of which feed into others, such that tracking flow through the state
  +machines is incredibly painful.
   
   Worse, these state machines are designed to be run from a single worker
   thread.  This means that a given socket is entirely single theaded; you
  
positive.code: perhaps on multiple cores, but nanomsg itself runs all socket code on
  a single worker thread.)
  
  There is another problem too -- the inproc code that moves messages
  between one socket and another was incredibly racy.  This is because the
  two sockets have different locks, and so dealing with the different
  contexts was tricky (and consequently buggy).  (I've since, I think, fixed
  the worst of the bugs here, but not after many hours of pulling out hair.)
  
  The state machines also make fairly linear flow really difficult to follow.
  For example, there is a state machine to read the header information.  This
  
negative.code: = Rational: Or why am I bothering to rewrite nanomsg?
  Garrett D'Amore <garrett@damore.org>
  v0.2, February 22, 2018
  
  
  NOTE: You might want to review
  