eroMQ has its fair share of quirks and oddities. It manages everything in a global state, requires things be manually grouped into `Contexts`, allocates a thread per context (making it not thread-save) , transports are baked into the library, and so on. It can be a bit clunky to work with at times. As a result, one of the original developers on the ZMQ project, Martin Sustrik, started a new project that evolved into a complete re-write / re-realization of the ZMQ project, called nanomsg.

Nanomsg aims to resolve many of the underlying short comings of the zeromq library, but remain compliant with the ZMTP spec. It provides many of the messaging patterns ( which are refereed to as scalability patterns ) as

n previous installments of Summer Of Sockets, we took a look at the basic messaging socket types in [ZeroMQ](http://zeromq.org), **PUSH**/**PULL**, **PUB**/**SUB** and **REQ**/**REP**. Each of these types provides different patterns of messaging between their connected peers. Up to now, we have been passing simple message around to illustrate the patterns. In larger, more complicated applications, the message will need to carry more information.

In JavaScript, that typically means constructing, passing and parsing JSON objects, as well as accounting for missing fields, and event embedding message types and meta data about usage into object. This quickly becomes messy and overly complicated.

JSON is a fine data format, but ZeroMQ provides a very handy facility

o far we have looked at PUSH/PULL and REQ/REP. One of the more interested socket combinations in ZeroMQ is PUB/SUB. PUB/SUB has multitude of real world applications in distributed systems, Ranging from remote Work Queues, Push notifications for real time web applications, inter-application communications, etc. Like other socket types found in ZeroMQ either each the pub and sub socket types can either bind or connect to an endpoint. It is really a matter of your applications use case. In general, the part of the application that will have the greatest up time would bind to a port and all others would connect.

There are two primary difference with the PUB/SUB sockets over the previously

eroMQ makes it incredibly easy to connect and communicate between individual applications in distinctive patterns. Last time we took a look at the simple PUSH / PULL socket types. The next types we'll take a look at are the Request / Reply ( REQ / REP ) sockets. You can [download](https://bitbucket.org/esatterwhite/summer-of-sockets/src) the source code for the following examples if you would like to follow along.

Request & Reply sockets are probably the most familiar and easiest to reason about for web developers. This most obvious use case with REQ and REQ sockets, is a web server. A client ( REQ ) makes a request to the server ( REP ) and it waits until a response comes back. Unlike the PUSH  socket,

he last few months I've spent working distributed systems for web and tel-com systems. Web applications are notorious for being monolithic, tightly coupled pieces of software under a single code base. This just fine when you application really just needs to work within itself. When your application need to share data with other applications, possibly written in different languages, frameworks, or even off load long running tasks, things can quickly become a challenge. To rectify such problems, most developers reach for a central message queue like RabbitMQ. Now, RabbitMQ is a great piece of technology, as the tag line says, `It Just Works`. However, it posses a couple of interesting problems that has turned me off to it.

Single