rbczmq 1.6.2 → 1.6.4

data/ext/zeromq/doc/zmq_socket.txt

@@ -0,0 +1,369 @@
+zmq_socket(3)
+=============
+
+
+NAME
+----
+zmq_socket - create 0MQ socket
+
+
+SYNOPSIS
+--------
+*void *zmq_socket (void '*context', int 'type');*
+
+
+DESCRIPTION
+-----------
+The 'zmq_socket()' function shall create a 0MQ socket within the specified
+'context' and return an opaque handle to the newly created socket. The 'type'
+argument specifies the socket type, which determines the semantics of
+communication over the socket.
+
+The newly created socket is initially unbound, and not associated with any
+endpoints. In order to establish a message flow a socket must first be
+connected to at least one endpoint with linkzmq:zmq_connect[3], or at least one
+endpoint must be created for accepting incoming connections with
+linkzmq:zmq_bind[3].
+
+.Key differences to conventional sockets
+Generally speaking, conventional sockets present a _synchronous_ interface to
+either connection-oriented reliable byte streams (SOCK_STREAM), or
+connection-less unreliable datagrams (SOCK_DGRAM). In comparison, 0MQ sockets
+present an abstraction of an asynchronous _message queue_, with the exact
+queueing semantics depending on the socket type in use. Where conventional
+sockets transfer streams of bytes or discrete datagrams, 0MQ sockets transfer
+discrete _messages_.
+
+0MQ sockets being _asynchronous_ means that the timings of the physical
+connection setup and tear down, reconnect and effective delivery are transparent
+to the user and organized by 0MQ itself. Further, messages may be _queued_ in
+the event that a peer is unavailable to receive them.
+
+Conventional sockets allow only strict one-to-one (two peers), many-to-one
+(many clients, one server), or in some cases one-to-many (multicast)
+relationships. With the exception of 'ZMQ_PAIR', 0MQ sockets may be connected
+*to multiple endpoints* using _zmq_connect()_, while simultaneously accepting
+incoming connections *from multiple endpoints* bound to the socket using
+_zmq_bind()_, thus allowing many-to-many relationships.
+
+.Thread safety
+0MQ 'sockets' are _not_ thread safe. Applications MUST NOT use a socket
+from multiple threads except after migrating a socket from one thread to 
+another with a "full fence" memory barrier.
+
+.Socket types
+The following sections present the socket types defined by 0MQ, grouped by the
+general _messaging pattern_ which is built from related socket types.
+
+
+Request-reply pattern
+~~~~~~~~~~~~~~~~~~~~~
+The request-reply pattern is used for sending requests from a ZMQ_REQ _client_
+to one or more ZMQ_REP _services_, and receiving subsequent replies to each
+request sent.
+
+
+ZMQ_REQ
+^^^^^^^
+A socket of type 'ZMQ_REQ' is used by a _client_ to send requests to and
+receive replies from a _service_. This socket type allows only an alternating
+sequence of _zmq_send(request)_ and subsequent _zmq_recv(reply)_ calls. Each
+request sent is round-robined among all _services_, and each reply received is
+matched with the last issued request.
+
+When a 'ZMQ_REQ' socket enters the 'mute' state due to having reached the
+high water mark for all _services_, or if there are no _services_ at all, then
+any linkzmq:zmq_send[3] operations on the socket shall block until the
+'mute' state ends or at least one _service_ becomes available for sending;
+messages are not discarded.
+
+[horizontal]
+.Summary of ZMQ_REQ characteristics
+Compatible peer sockets:: 'ZMQ_REP', 'ZMQ_ROUTER'
+Direction:: Bidirectional
+Send/receive pattern:: Send, Receive, Send, Receive, ...
+Outgoing routing strategy:: Round-robin
+Incoming routing strategy:: Last peer
+Action in mute state:: Block
+
+
+ZMQ_REP
+^^^^^^^
+A socket of type 'ZMQ_REP' is used by a _service_ to receive requests from and
+send replies to a _client_. This socket type allows only an alternating
+sequence of _zmq_recv(request)_ and subsequent _zmq_send(reply)_ calls. Each
+request received is fair-queued from among all _clients_, and each reply sent
+is routed to the _client_ that issued the last request. If the original
+requester doesn't exist any more the reply is silently discarded.
+
+When a 'ZMQ_REP' socket enters the 'mute' state due to having reached the
+high water mark for a _client_, then any replies sent to the _client_ in
+question shall be dropped until the mute state ends.
+
+[horizontal]
+.Summary of ZMQ_REP characteristics
+Compatible peer sockets:: 'ZMQ_REQ', 'ZMQ_DEALER'
+Direction:: Bidirectional
+Send/receive pattern:: Receive, Send, Receive, Send, ...
+Incoming routing strategy:: Fair-queued
+Outgoing routing strategy:: Last peer
+Action in mute state:: Drop
+
+
+ZMQ_DEALER
+^^^^^^^^^^
+A socket of type 'ZMQ_DEALER' is an advanced pattern used for extending
+request/reply sockets. Each message sent is round-robined among all connected
+peers, and each message received is fair-queued from all connected peers.
+
+When a 'ZMQ_DEALER' socket enters the 'mute' state due to having reached the
+high water mark for all peers, or if there are no peers at all, then any
+linkzmq:zmq_send[3] operations on the socket shall block until the mute
+state ends or at least one peer becomes available for sending; messages are not
+discarded.
+
+When a 'ZMQ_DEALER' socket is connected to a 'ZMQ_REP' socket each message sent
+must consist of an empty message part, the _delimiter_, followed by one or more
+_body parts_.
+
+Deprecated alias: 'ZMQ_XREQ'.
+
+[horizontal]
+.Summary of ZMQ_DEALER characteristics
+Compatible peer sockets:: 'ZMQ_ROUTER', 'ZMQ_REP', 'ZMQ_DEALER'
+Direction:: Bidirectional
+Send/receive pattern:: Unrestricted
+Outgoing routing strategy:: Round-robin
+Incoming routing strategy:: Fair-queued
+Action in mute state:: Block
+
+
+ZMQ_ROUTER
+^^^^^^^^^^
+A socket of type 'ZMQ_ROUTER' is an advanced socket type used for extending
+request/reply sockets. When receiving messages a 'ZMQ_ROUTER' socket shall
+prepend a message part containing the _identity_ of the originating peer to the
+message before passing it to the application. Messages received are fair-queued
+from among all connected peers. When sending messages a 'ZMQ_ROUTER' socket shall
+remove the first part of the message and use it to determine the _identity_ of
+the peer the message shall be routed to. If the peer does not exist anymore
+the message shall be silently discarded by default, unless 'ZMQ_ROUTER_BEHAVIOR'
+socket option is set to '1'.
+
+When a 'ZMQ_ROUTER' socket enters the 'mute' state due to having reached the
+high water mark for all peers, then any messages sent to the socket shall be dropped
+until the mute state ends. Likewise, any messages routed to a peer for which
+the individual high water mark has been reached shall also be dropped.
+
+When a 'ZMQ_REQ' socket is connected to a 'ZMQ_ROUTER' socket, in addition to the
+_identity_ of the originating peer each message received shall contain an empty
+_delimiter_ message part. Hence, the entire structure of each received message
+as seen by the application becomes: one or more _identity_ parts, _delimiter_
+part, one or more _body parts_. When sending replies to a 'ZMQ_REQ' socket the
+application must include the _delimiter_ part.
+
+Deprecated alias: 'ZMQ_XREP'.
+
+[horizontal]
+.Summary of ZMQ_ROUTER characteristics
+Compatible peer sockets:: 'ZMQ_DEALER', 'ZMQ_REQ', 'ZMQ_ROUTER'
+Direction:: Bidirectional
+Send/receive pattern:: Unrestricted
+Outgoing routing strategy:: See text
+Incoming routing strategy:: Fair-queued
+Action in mute state:: Drop
+
+
+Publish-subscribe pattern
+~~~~~~~~~~~~~~~~~~~~~~~~~
+The publish-subscribe pattern is used for one-to-many distribution of data from
+a single _publisher_ to multiple _subscribers_ in a fan out fashion.
+
+
+ZMQ_PUB
+^^^^^^^
+A socket of type 'ZMQ_PUB' is used by a _publisher_ to distribute data.
+Messages sent are distributed in a fan out fashion to all connected peers.
+The linkzmq:zmq_recv[3] function is not implemented for this socket type.
+
+When a 'ZMQ_PUB' socket enters the 'mute' state due to having reached the
+high water mark for a _subscriber_, then any messages that would be sent to the
+_subscriber_ in question shall instead be dropped until the mute state
+ends. The _zmq_send()_ function shall never block for this socket type.
+
+[horizontal]
+.Summary of ZMQ_PUB characteristics
+Compatible peer sockets:: 'ZMQ_SUB', 'ZMQ_XSUB'
+Direction:: Unidirectional
+Send/receive pattern:: Send only
+Incoming routing strategy:: N/A
+Outgoing routing strategy:: Fan out
+Action in mute state:: Drop
+
+
+ZMQ_SUB
+^^^^^^^
+A socket of type 'ZMQ_SUB' is used by a _subscriber_ to subscribe to data
+distributed by a _publisher_. Initially a 'ZMQ_SUB' socket is not subscribed to
+any messages, use the 'ZMQ_SUBSCRIBE' option of linkzmq:zmq_setsockopt[3] to
+specify which messages to subscribe to. The _zmq_send()_ function is not
+implemented for this socket type.
+
+[horizontal]
+.Summary of ZMQ_SUB characteristics
+Compatible peer sockets:: 'ZMQ_PUB', 'ZMQ_XPUB'
+Direction:: Unidirectional
+Send/receive pattern:: Receive only
+Incoming routing strategy:: Fair-queued
+Outgoing routing strategy:: N/A
+Action in mute state:: Drop
+
+
+ZMQ_XPUB
+^^^^^^^^
+Same as ZMQ_PUB except that you can receive subscriptions from the peers
+in form of incoming messages. Subscription message is a byte 1 (for
+subscriptions) or byte 0 (for unsubscriptions) followed by the subscription
+body.
+
+[horizontal]
+.Summary of ZMQ_XPUB characteristics
+Compatible peer sockets:: 'ZMQ_SUB', 'ZMQ_XSUB'
+Direction:: Unidirectional
+Send/receive pattern:: Send messages, receive subscriptions
+Incoming routing strategy:: N/A
+Outgoing routing strategy:: Fan out
+Action in mute state:: Drop
+
+
+ZMQ_XSUB
+^^^^^^^^
+Same as ZMQ_SUB except that you subscribe by sending subscription messages to
+the socket. Subscription message is a byte 1 (for subscriptions) or byte 0
+(for unsubscriptions) followed by the subscription body.
+
+[horizontal]
+.Summary of ZMQ_XSUB characteristics
+Compatible peer sockets:: 'ZMQ_PUB', 'ZMQ_XPUB'
+Direction:: Unidirectional
+Send/receive pattern:: Receive messages, send subscriptions
+Incoming routing strategy:: Fair-queued
+Outgoing routing strategy:: N/A
+Action in mute state:: Drop
+
+
+Pipeline pattern
+~~~~~~~~~~~~~~~~
+The pipeline pattern is used for distributing data to _nodes_ arranged in
+a pipeline. Data always flows down the pipeline, and each stage of the pipeline
+is connected to at least one _node_. When a pipeline stage is connected to
+multiple _nodes_ data is round-robined among all connected _nodes_.
+
+
+ZMQ_PUSH
+^^^^^^^^
+A socket of type 'ZMQ_PUSH' is used by a pipeline _node_ to send messages
+to downstream pipeline _nodes_. Messages are round-robined to all connected
+downstream _nodes_. The _zmq_recv()_ function is not implemented for this
+socket type.
+
+When a 'ZMQ_PUSH' socket enters the 'mute' state due to having reached the
+high water mark for all downstream _nodes_, or if there are no downstream
+_nodes_ at all, then any linkzmq:zmq_send[3] operations on the socket shall
+block until the mute state ends or at least one downstream _node_
+becomes available for sending; messages are not discarded.
+
+[horizontal]
+.Summary of ZMQ_PUSH characteristics
+Compatible peer sockets:: 'ZMQ_PULL'
+Direction:: Unidirectional
+Send/receive pattern:: Send only
+Incoming routing strategy:: N/A
+Outgoing routing strategy:: Round-robin
+Action in mute state:: Block
+
+
+ZMQ_PULL
+^^^^^^^^
+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.
+
+[horizontal]
+.Summary of ZMQ_PULL characteristics
+Compatible peer sockets:: 'ZMQ_PUSH'
+Direction:: Unidirectional
+Send/receive pattern:: Receive only
+Incoming routing strategy:: Fair-queued
+Outgoing routing strategy:: N/A
+Action in mute state:: Block
+
+
+Exclusive pair pattern
+~~~~~~~~~~~~~~~~~~~~~~
+The exclusive pair pattern is used to connect a peer to precisely one other
+peer. This pattern is used for inter-thread communication across the inproc
+transport.
+
+
+ZMQ_PAIR
+^^^^^^^^
+A socket of type 'ZMQ_PAIR' can only be connected to a single peer at any one
+time.  No message routing or filtering is performed on messages sent over a
+'ZMQ_PAIR' socket.
+
+When a 'ZMQ_PAIR' socket enters the 'mute' state due to having reached the
+high water mark for the connected peer, or if no peer is connected, then
+any linkzmq:zmq_send[3] operations on the socket shall block until the peer
+becomes available for sending; messages are not discarded.
+
+NOTE: 'ZMQ_PAIR' sockets are designed for inter-thread communication across
+the linkzmq:zmq_inproc[7] transport and do not implement functionality such
+as auto-reconnection. 'ZMQ_PAIR' sockets are considered experimental and may
+have other missing or broken aspects.
+
+[horizontal]
+.Summary of ZMQ_PAIR characteristics
+Compatible peer sockets:: 'ZMQ_PAIR'
+Direction:: Bidirectional
+Send/receive pattern:: Unrestricted
+Incoming routing strategy:: N/A
+Outgoing routing strategy:: N/A
+Action in mute state:: Block
+
+
+RETURN VALUE
+------------
+The _zmq_socket()_ function shall return an opaque handle to the newly created
+socket if successful. Otherwise, it shall return NULL and set 'errno' to one of
+the values defined below.
+
+
+ERRORS
+------
+*EINVAL*::
+The requested socket 'type' is invalid.
+*EFAULT*::
+The provided 'context' is invalid.
+*EMFILE*::
+The limit on the total number of open 0MQ sockets has been reached.
+*ETERM*::
+The context specified was terminated.
+
+SEE ALSO
+--------
+linkzmq:zmq_init[3]
+linkzmq:zmq_setsockopt[3]
+linkzmq:zmq_bind[3]
+linkzmq:zmq_connect[3]
+linkzmq:zmq_send[3]
+linkzmq:zmq_recv[3]
+linkzmq:zmq_inproc[7]
+linkzmq:zmq[7]
+
+
+AUTHORS
+-------
+This 0MQ manual page was written by Martin Sustrik <sustrik@250bpm.com>,
+Martin Lucina <mato@kotelna.sk>, and Pieter Hintjens <ph@imatix.com>.

data/ext/zeromq/doc/zmq_socket_monitor.txt

@@ -0,0 +1,288 @@
+zmq_ctx_socket_monitor(3)
+=========================
+
+
+NAME
+----
+
+zmq_socket_monitor - register a monitoring callback
+
+
+SYNOPSIS
+--------
+*int zmq_socket_monitor (void '*socket', char * '*addr', int 'events');*
+
+
+DESCRIPTION
+-----------
+The _zmq_socket_monitor()_ function shall spawn a 'PAIR' socket that publishes
+socket state changes (events) over the inproc:// transport to a given endpoint.
+Messages are 'zmq_event_t' structs. It's recommended to connect via a 'PAIR'
+socket in another application thread and handle monitoring events there. It's
+possible to also supply a bitmask ('ZMQ_EVENT_ALL' or any combination of the
+'ZMQ_EVENT_*' constants) of the events you're interested in.
+
+----
+// monitoring thread
+static void *req_socket_monitor (void *ctx)
+{
+    zmq_event_t event;
+    int rc;
+
+    void *s = zmq_socket (ctx, ZMQ_PAIR);
+    assert (s);
+
+    rc = zmq_connect (s, "inproc://monitor.req");
+    assert (rc == 0);
+    while (true) {
+        zmq_msg_t msg;
+        zmq_msg_init (&msg);
+        rc = zmq_recvmsg (s, &msg, 0);
+        if (rc == -1 && zmq_errno() == ETERM) break;
+        assert (rc != -1);
+        memcpy (&event, zmq_msg_data (&msg), sizeof (event));
+        switch (event.event) {
+        case ZMQ_EVENT_CONNECTED:
+            // handle socket connected event
+            break;
+        case ZMQ_EVENT_CLOSED:
+            // handle socket closed event
+            break;
+        }
+    }
+    zmq_close (s);
+    return NULL;
+}
+
+// register a monitor endpoint for all socket events
+rc = zmq_socket_monitor (req, "inproc://monitor.req", ZMQ_EVENT_ALL);
+assert (rc == 0);
+
+// spawn a monitoring thread
+rc = pthread_create (&threads [0], NULL, req_socket_monitor, ctx);
+assert (rc == 0);
+----
+
+Only connection oriented (tcp and ipc) transports are supported in this initial
+implementation.
+
+Supported events are:
+
+
+ZMQ_EVENT_CONNECTED: connection established
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The 'ZMQ_EVENT_CONNECTED' event triggers when a connection has been established
+to a remote peer. This can happen either synchronous or asynchronous.
+
+.Event metadata:
+----
+data.connected.addr // peer address
+data.connected.fd // socket descriptor
+----
+
+ZMQ_EVENT_CONNECT_DELAYED: synchronous connect failed, it's being polled
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The 'ZMQ_EVENT_CONNECT_DELAYED' event triggers when an immediate connection
+attempt is delayed and it's completion's being polled for.
+
+.Event metadata:
+----
+data.connect_delayed.addr // peer address
+data.connect_delayed.err // errno value
+----
+
+ZMQ_EVENT_CONNECT_RETRIED: asynchronous connect / reconnection attempt
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The 'ZMQ_EVENT_CONNECT_RETRIED' event triggers when a connection attempt
+is being handled by reconnect timer. The reconnect interval's recomputed
+for each attempt.
+
+.Event metadata:
+----
+data.connect_retried.addr // peer address
+data.connect_retried.interval // computed reconnect interval
+----
+
+ZMQ_EVENT_LISTENING: socket bound to an address, ready to accept connections
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The 'ZMQ_EVENT_LISTENING' event triggers when a socket's successfully bound
+to a an interface.
+
+.Event metadata:
+----
+data.listening.addr //  listen address
+data.listening.fd // socket descriptor
+----
+
+ZMQ_EVENT_BIND_FAILED: socket could not bind to an address
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The 'ZMQ_EVENT_BIND_FAILED' event triggers when a socket could not bind to
+a given interface.
+
+.Event metadata:
+----
+data.bind_failed.addr // listen address
+data.bind_failed.err // errno value
+----
+
+ZMQ_EVENT_ACCEPTED: connection accepted to bound interface
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The 'ZMQ_EVENT_ACCEPTED' event triggers when a connection from a remote peer
+has been established with a socket's listen address.
+
+.Event metadata:
+----
+data.accepted.addr // listen address
+data.accepted.fd // socket descriptor
+----
+
+ZMQ_EVENT_ACCEPT_FAILED: could not accept client connection
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The 'ZMQ_EVENT_ACCEPT_FAILED' event triggers when a connection attempt to
+a socket's bound address fails.
+
+.Event metadata:
+----
+data.accept_failed.addr // listen address
+data.accept_failed.err // errno value
+----
+
+ZMQ_EVENT_CLOSED: connection closed
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The 'ZMQ_EVENT_CLOSED' event triggers when a connection's underlying descriptor
+has been closed. 
+
+.Event metadata:
+----
+data.closed.addr // address
+data.closed.fd // socket descriptor
+----
+
+ZMQ_EVENT_CLOSE_FAILED: connection couldn't be closed
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The 'ZMQ_EVENT_CLOSE_FAILED' event triggers when a descriptor could not be
+released back to the OS.
+
+.Event metadata:
+----
+data.close_failed.addr // address
+data.close_failed.err // errno value
+----
+
+ZMQ_EVENT_DISCONNECTED: broken session
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The 'ZMQ_EVENT_DISCONNECTED' event triggers when the stream engine (tcp and ipc
+specific) detects a corrupted / broken session.
+
+.Event metadata:
+----
+data.disconnected.addr // address
+data.disconnected.fd // socket descriptor
+----
+
+RETURN VALUE
+------------
+The _zmq_socket_monitor()_ function returns a value of 0 or greater if
+successful. Otherwise it returns `-1` and sets 'errno' to one of the values
+defined below.
+
+
+ERRORS
+------
+*ETERM*::
+The 0MQ 'context' associated with the specified 'socket' was terminated.
+
+*EPROTONOSUPPORT*::
+The requested 'transport' protocol is not supported. Monitor sockets are
+required to use the inproc:// transport.
+
+*EINVAL*::
+The endpoint supplied is invalid.
+
+EXAMPLE
+-------
+.Observing a 'REP' socket's connection state 
+----
+// REP socket monitor thread
+static void *rep_socket_monitor (void *ctx)
+{
+    zmq_event_t event;
+    int rc;
+
+    void *s = zmq_socket (ctx, ZMQ_PAIR);
+    assert (s);
+
+    rc = zmq_connect (s, "inproc://monitor.rep");
+    assert (rc == 0);
+    while (true) {
+        zmq_msg_t msg;
+        zmq_msg_init (&msg);
+        rc = zmq_recvmsg (s, &msg, 0);
+        if (rc == -1 && zmq_errno() == ETERM) break;
+        assert (rc != -1);
+        memcpy (&event, zmq_msg_data (&msg), sizeof (event));
+        switch (event.event) {
+        case ZMQ_EVENT_LISTENING:
+            printf ("listening socket descriptor %d\n", event.data.listening.fd);
+            printf ("listening socket address %s\n", event.data.listening.addr);
+            break;
+        case ZMQ_EVENT_ACCEPTED:
+            printf ("accepted socket descriptor %d\n", event.data.accepted.fd);
+            printf ("accepted socket address %s\n", event.data.accepted.addr);
+            break;
+        case ZMQ_EVENT_CLOSE_FAILED:
+            printf ("socket close failure error code %d\n", event.data.close_failed.err);
+            printf ("socket address %s\n", event.data.close_failed.addr);
+            break;
+        case ZMQ_EVENT_CLOSED:
+            printf ("closed socket descriptor %d\n", event.data.closed.fd);
+            printf ("closed socket address %s\n", event.data.closed.addr);
+            break;
+        case ZMQ_EVENT_DISCONNECTED:
+            printf ("disconnected socket descriptor %d\n", event.data.disconnected.fd);
+            printf ("disconnected socket address %s\n", event.data.disconnected.addr);
+            break;
+        }
+        zmq_msg_close (&msg);
+    }
+    zmq_close (s);
+    return NULL;
+}
+
+
+//  Create the infrastructure
+void *ctx = zmq_init (1);
+assert (ctx);
+
+// REP socket
+rep = zmq_socket (ctx, ZMQ_REP);
+assert (rep);
+
+// REP socket monitor, all events
+rc = zmq_socket_monitor (rep, "inproc://monitor.rep", ZMQ_EVENT_ALL);
+assert (rc == 0);
+rc = pthread_create (&threads [0], NULL, rep_socket_monitor, ctx);
+assert (rc == 0);
+
+rc = zmq_bind (rep, addr);
+assert (rc == 0);
+
+// Allow some time for event detection
+zmq_sleep (1);
+
+// Close the REP socket
+rc = zmq_close (rep);
+assert (rc == 0);
+
+zmq_term (ctx);
+----
+
+
+SEE ALSO
+--------
+linkzmq:zmq[7]
+
+
+AUTHORS
+-------
+This 0MQ manual page was written by Lourens Naudé <lourens@methodmissing.com>