0MQ haskell binding. The API closely follows the C-API of 0MQ with
the main difference that sockets are typed.
The documentation of the individual socket types and socket options
is copied from 0MQ's man pages authored by Martin Sustrik.

The option to set on 0MQ sockets (descriptions reproduced here from
zmq_setsockopt(3) (cf. man zmq_setsockopt for further details)).

HighWM

High watermark for the message pipes associated with the
socket. The water mark cannot be exceeded. If the messages
don't fit into the pipe emergency mechanisms of the
particular socket type are used (block, drop etc.)
If HWM is set to zero, there are no limits for the content
of the pipe.
Default: 0

Swap

Swap allows the pipe to exceed high watermark. However,
the data are written to the disk rather than held in the memory.
Until high watermark is exceeded there is no disk activity involved
though. The value of the option defines maximal size of the swap file.
Default: 0

Affinity

Affinity defines which threads in the thread pool will
be used to handle newly created sockets. This way you can dedicate
some of the threads (CPUs) to a specific work. Value of 0 means no
affinity. Work is distributed fairly among the threads in the
thread pool. For non-zero values, the lowest bit corresponds to the
thread 1, second lowest bit to the thread 2 etc. Thus, value of 3
means that from now on newly created sockets will handle I/O activity
exclusively using threads no. 1 and 2.
Default: 0

Identity

Identity of the socket. Identity is important when
restarting applications. If the socket has no identity, each run of
the application is completely separated from other runs. However,
with identity application reconnects to existing infrastructure
left by the previous run. Thus it may receive messages that were
sent in the meantime, it shares pipe limits with the previous run etc.
Default: NULL

Rate

This option applies only to sending side of multicast
transports (pgm & udp). It specifies maximal outgoing data rate that
an individual sender socket can send.
Default: 100

RecoveryIVL

This option applies only to multicast transports
(pgm & udp). It specifies how long can the receiver socket survive
when the sender is inaccessible. Keep in mind that large recovery
intervals at high data rates result in very large recovery buffers,
meaning that you can easily overload your box by setting say 1 minute
recovery interval at 1Gb/s rate (requires 7GB in-memory buffer).
Default: 10

McastLoop

This option applies only to multicast transports
(pgm & udp). Value of 1 means that the mutlicast packets can be
received on the box they were sent from. Setting the value to 0
disables the loopback functionality which can have negative impact on
the performance. If possible, disable the loopback in production
environments.
Default: 1

Socket to subscribe for data. Send function is not implemented
for this socket type. Initially, socket is subscribed for no
messages. Use subscribe to specify which messages to subscribe for.
Compatible peer sockets: Pub.

Socket to send requests and receive replies. Requests are
load-balanced among all the peers. This socket type allows only an
alternated sequence of send's and recv's.
Compatible peer sockets: Rep, Xrep.

Socket to receive requests and send replies. This socket type
allows only an alternated sequence of receive's and send's. Each
send is routed to the peer that issued the last received request.
Compatible peer sockets: Req, XReq.

Special socket type to be used in request/reply middleboxes
such as zmq_queue(7). Requests forwarded using this socket type
should be tagged by a proper prefix identifying the original requester.
Replies received by this socket are tagged with a proper postfix
that can be use to route the reply back to the original requester.
Compatible peer sockets: Rep, Xrep.

Special socket type to be used in request/reply middleboxes
such as zmq_queue(7). Requests received using this socket are already
properly tagged with prefix identifying the original requester. When
sending a reply via XREP socket the message should be tagged with a
prefix from a corresponding request.
Compatible peer sockets: Req, Xreq.

A socket of type ZMQ_PULL is used by a pipeline node to receive
messages from upstream pipeline nodes. Messages are fair-queued from
among all connected upstream nodes. The zmq_send() function is not
implemented for this socket type.

A socket of type ZMQ_PUSH is used by a pipeline node to send messages
to downstream pipeline nodes. Messages are load-balanced to all connected
downstream nodes. The zmq_recv() function is not implemented for this
socket type.

When a ZMQ_PUSH socket enters an exceptional state due to having reached
the high water mark for all downstream nodes, or if there are no
downstream nodes at all, then any zmq_send(3) operations on the socket
shall block until the exceptional state ends or at least one downstream
node becomes available for sending; messages are not discarded.

Get the given socket option by passing in some dummy value of
that option. The actual value will be returned. Please note that
there are certain combatibility constraints w.r.t the socket
type (cf. man zmq_setsockopt).