laag-libzmq 4.2.3.0

data/vendor/github.com/zeromq/libzmq/doc/zmq_msg_size.txt

@@ -0,0 +1,48 @@
+zmq_msg_size(3)
+===============
+
+
+NAME
+----
+zmq_msg_size - retrieve message content size in bytes
+
+
+SYNOPSIS
+--------
+*size_t zmq_msg_size (zmq_msg_t '*msg');*
+
+
+DESCRIPTION
+-----------
+The _zmq_msg_size()_ function shall return the size in bytes of the content of
+the message object referenced by 'msg'.
+
+CAUTION: Never access 'zmq_msg_t' members directly, instead always use the
+_zmq_msg_ family of functions.
+
+
+RETURN VALUE
+------------
+Upon successful completion, _zmq_msg_size()_ shall return the size of the
+message content in bytes.
+
+
+ERRORS
+------
+No errors are defined.
+
+
+SEE ALSO
+--------
+linkzmq:zmq_msg_data[3]
+linkzmq:zmq_msg_init[3]
+linkzmq:zmq_msg_init_size[3]
+linkzmq:zmq_msg_init_data[3]
+linkzmq:zmq_msg_close[3]
+linkzmq:zmq[7]
+
+
+AUTHORS
+-------
+This page was written by the 0MQ community. To make a change please
+read the 0MQ Contribution Policy at <http://www.zeromq.org/docs:contributing>.

data/vendor/github.com/zeromq/libzmq/doc/zmq_null.txt

@@ -0,0 +1,27 @@
+zmq_null(7)
+===========
+
+
+NAME
+----
+zmq_null - no security or confidentiality
+
+
+SYNOPSIS
+--------
+The NULL mechanism is defined by the ZMTP 3.0 specification: 
+<http://rfc.zeromq.org/spec:23>. This is the default security mechanism
+for ZeroMQ sockets.
+
+
+SEE ALSO
+--------
+linkzmq:zmq_plain[7]
+linkzmq:zmq_curve[7]
+linkzmq:zmq[7]
+
+
+AUTHORS
+-------
+This page was written by the 0MQ community. To make a change please
+read the 0MQ Contribution Policy at <http://www.zeromq.org/docs:contributing>.

data/vendor/github.com/zeromq/libzmq/doc/zmq_pgm.txt

@@ -0,0 +1,164 @@
+zmq_pgm(7)
+==========
+
+
+NAME
+----
+zmq_pgm - 0MQ reliable multicast transport using PGM
+
+
+SYNOPSIS
+--------
+PGM (Pragmatic General Multicast) is a protocol for reliable multicast
+transport of data over IP networks.
+
+
+DESCRIPTION
+-----------
+0MQ implements two variants of PGM, the standard protocol where PGM datagrams
+are layered directly on top of IP datagrams as defined by RFC 3208 (the 'pgm'
+transport) and "Encapsulated PGM" or EPGM where PGM datagrams are encapsulated
+inside UDP datagrams (the 'epgm' transport).
+
+The 'pgm' and 'epgm' transports can only be used with the 'ZMQ_PUB' and
+'ZMQ_SUB' socket types.
+
+Further, PGM sockets are rate limited by default. For details, refer to the
+'ZMQ_RATE', and 'ZMQ_RECOVERY_IVL' options documented in
+linkzmq:zmq_setsockopt[3].
+
+CAUTION: The 'pgm' transport implementation requires access to raw IP sockets.
+Additional privileges may be required on some operating systems for this
+operation. Applications not requiring direct interoperability with other PGM
+implementations are encouraged to use the 'epgm' transport instead which does
+not require any special privileges.
+
+
+ADDRESSING
+----------
+A 0MQ endpoint is a string consisting of a 'transport'`://` followed by an
+'address'. The 'transport' specifies the underlying protocol to use. The
+'address' specifies the transport-specific address to connect to.
+
+For the PGM transport, the transport is `pgm`, and for the EPGM protocol the
+transport is `epgm`. The meaning of the 'address' part is defined below.
+
+
+Connecting a socket
+~~~~~~~~~~~~~~~~~~~
+When connecting a socket to a peer address using _zmq_connect()_ with the 'pgm'
+or 'epgm' transport, the 'endpoint' shall be interpreted as an 'interface'
+followed by a semicolon, followed by a 'multicast address', followed by a colon
+and a port number.
+
+An 'interface' may be specified by either of the following:
+
+* The interface name as defined by the operating system.
+* The primary IPv4 address assigned to the interface, in its numeric
+  representation.
+
+NOTE: Interface names are not standardised in any way and should be assumed to
+be arbitrary and platform dependent. On Win32 platforms no short interface
+names exist, thus only the primary IPv4 address may be used to specify an
+'interface'. The 'interface' part can be omitted, in that case the default one
+will be selected.
+
+A 'multicast address' is specified by an IPv4 multicast address in its numeric
+representation.
+
+
+WIRE FORMAT
+-----------
+Consecutive PGM datagrams are interpreted by 0MQ as a single continuous stream
+of data where 0MQ messages are not necessarily aligned with PGM datagram
+boundaries and a single 0MQ message may span several PGM datagrams. This stream
+of data consists of 0MQ messages encapsulated in 'frames' as described in
+linkzmq:zmq_tcp[7].
+
+
+PGM datagram payload
+~~~~~~~~~~~~~~~~~~~~
+The following ABNF grammar represents the payload of a single PGM datagram as
+used by 0MQ:
+
+....
+datagram               = (offset data)
+offset                 = 2OCTET
+data                   = *OCTET
+....
+
+In order for late joining consumers to be able to identify message boundaries,
+each PGM datagram payload starts with a 16-bit unsigned integer in network byte
+order specifying either the offset of the first message 'frame' in the datagram
+or containing the value `0xFFFF` if the datagram contains solely an
+intermediate part of a larger message.
+
+Note that offset specifies where the first message begins rather than the first
+message part. Thus, if there are trailing message parts at the beginning of
+the packet the offset ignores them and points to first initial message part
+in the packet.
+
+The following diagram illustrates the layout of a single PGM datagram payload:
+
+....
++------------------+----------------------+
+| offset (16 bits) |         data         |
++------------------+----------------------+
+....
+
+The following diagram further illustrates how three example 0MQ frames are laid
+out in consecutive PGM datagram payloads:
+
+....
+First datagram payload
++--------------+-------------+---------------------+
+| Frame offset |   Frame 1   |   Frame 2, part 1   |
+|    0x0000    | (Message 1) | (Message 2, part 1) |
++--------------+-------------+---------------------+
+
+Second datagram payload
++--------------+---------------------+
+| Frame offset |   Frame 2, part 2   |
+| 0xFFFF       | (Message 2, part 2) |
++--------------+---------------------+
+
+Third datagram payload
++--------------+----------------------------+-------------+
+| Frame offset |   Frame 2, final 8 bytes   |   Frame 3   |
+| 0x0008       | (Message 2, final 8 bytes) | (Message 3) |
++--------------+----------------------------+-------------+
+....
+
+
+EXAMPLE
+-------
+.Connecting a socket
+----
+//  Connecting to the multicast address 239.192.1.1, port 5555,
+//  using the first Ethernet network interface on Linux
+//  and the Encapsulated PGM protocol
+rc = zmq_connect(socket, "epgm://eth0;239.192.1.1:5555");
+assert (rc == 0);
+//  Connecting to the multicast address 239.192.1.1, port 5555,
+//  using the network interface with the address 192.168.1.1
+//  and the standard PGM protocol
+rc = zmq_connect(socket, "pgm://192.168.1.1;239.192.1.1:5555");
+assert (rc == 0);
+----
+
+
+SEE ALSO
+--------
+linkzmq:zmq_connect[3]
+linkzmq:zmq_setsockopt[3]
+linkzmq:zmq_tcp[7]
+linkzmq:zmq_ipc[7]
+linkzmq:zmq_inproc[7]
+linkzmq:zmq_vmci[7]
+linkzmq:zmq[7]
+
+
+AUTHORS
+-------
+This page was written by the 0MQ community. To make a change please
+read the 0MQ Contribution Policy at <http://www.zeromq.org/docs:contributing>.

data/vendor/github.com/zeromq/libzmq/doc/zmq_plain.txt

@@ -0,0 +1,37 @@
+zmq_plain(7)
+============
+
+
+NAME
+----
+zmq_plain - clear-text authentication
+
+
+SYNOPSIS
+--------
+The PLAIN mechanism defines a simple username/password mechanism that 
+lets a server authenticate a client. PLAIN makes no attempt at security 
+or confidentiality. It is intended for use on internal networks where 
+security requirements are low. The PLAIN mechanism is defined by this 
+document: <http://rfc.zeromq.org/spec:24>.
+
+
+USAGE
+-----
+To use PLAIN, the server shall set the ZMQ_PLAIN_SERVER option, and the 
+client shall set the ZMQ_PLAIN_USERNAME and ZMQ_PLAIN_PASSWORD socket 
+options. Which peer binds, and which connects, is not relevant.
+
+
+SEE ALSO
+--------
+linkzmq:zmq_setsockopt[3]
+linkzmq:zmq_null[7]
+linkzmq:zmq_curve[7]
+linkzmq:zmq[7]
+
+
+AUTHORS
+-------
+This page was written by the 0MQ community. To make a change please
+read the 0MQ Contribution Policy at <http://www.zeromq.org/docs:contributing>.

data/vendor/github.com/zeromq/libzmq/doc/zmq_poll.txt

@@ -0,0 +1,135 @@
+zmq_poll(3)
+===========
+
+
+NAME
+----
+zmq_poll - input/output multiplexing
+
+
+SYNOPSIS
+--------
+
+*int zmq_poll (zmq_pollitem_t '*items', int 'nitems', long 'timeout');*
+
+
+DESCRIPTION
+-----------
+The _zmq_poll()_ function provides a mechanism for applications to multiplex
+input/output events in a level-triggered fashion over a set of sockets. Each
+member of the array pointed to by the 'items' argument is a *zmq_pollitem_t*
+structure. The 'nitems' argument specifies the number of items in the 'items'
+array. The *zmq_pollitem_t* structure is defined as follows:
+
+["literal", subs="quotes"]
+typedef struct
+{
+    void '*socket';
+    int 'fd';
+    short 'events';
+    short 'revents';
+} zmq_pollitem_t;
+
+For each *zmq_pollitem_t* item, _zmq_poll()_ shall examine either the 0MQ
+socket referenced by 'socket' *or* the standard socket specified by the file
+descriptor 'fd', for the event(s) specified in 'events'. If both 'socket' and
+'fd' are set in a single *zmq_pollitem_t*, the 0MQ socket referenced by
+'socket' shall take precedence and the value of 'fd' shall be ignored.
+
+For each *zmq_pollitem_t* item, _zmq_poll()_ shall first clear the 'revents'
+member, and then indicate any requested events that have occurred by setting the
+bit corresponding to the event condition in the 'revents' member.
+
+If none of the requested events have occurred on any *zmq_pollitem_t* item,
+_zmq_poll()_ shall wait 'timeout' milliseconds for an event to occur on
+any of the requested items. If the value of 'timeout' is `0`, _zmq_poll()_
+shall return immediately. If the value of 'timeout' is `-1`, _zmq_poll()_ shall
+block indefinitely until a requested event has occurred on at least one
+*zmq_pollitem_t*.
+
+The 'events' and 'revents' members of *zmq_pollitem_t* are bit masks constructed
+by OR'ing a combination of the following event flags:
+
+*ZMQ_POLLIN*::
+For 0MQ sockets, at least one message may be received from the 'socket' without
+blocking. For standard sockets this is equivalent to the 'POLLIN' flag of the
+_poll()_ system call and generally means that at least one byte of data may be
+read from 'fd' without blocking.
+
+*ZMQ_POLLOUT*::
+For 0MQ sockets, at least one message may be sent to the 'socket' without
+blocking. For standard sockets this is equivalent to the 'POLLOUT' flag of the
+_poll()_ system call and generally means that at least one byte of data may be
+written to 'fd' without blocking.
+
+*ZMQ_POLLERR*::
+For standard sockets, this flag is passed through _zmq_poll()_ to the
+underlying _poll()_ system call and generally means that some sort of error
+condition is present on the socket specified by 'fd'. For 0MQ sockets this flag
+has no effect if set in 'events', and shall never be returned in 'revents' by
+_zmq_poll()_.
+
+*ZMQ_POLLPRI*::
+For 0MQ sockets this flags is of no use. For standard sockets this means there
+is urgent data to read. Refer to the POLLPRI flag for more informations.
+For file descriptor, refer to your use case: as an example, GPIO interrupts
+are signaled through a POLLPRI event.
+This flag has no effect on Windows.
+
+NOTE: The _zmq_poll()_ function may be implemented or emulated using operating
+system interfaces other than _poll()_, and as such may be subject to the limits
+of those interfaces in ways not defined in this documentation.
+
+RETURN VALUE
+------------
+Upon successful completion, the _zmq_poll()_ function shall return the number
+of *zmq_pollitem_t* structures with events signaled in 'revents' or `0` if no
+events have been signaled. Upon failure, _zmq_poll()_ shall return `-1` and set
+'errno' to one of the values defined below.
+
+
+ERRORS
+------
+*ETERM*::
+At least one of the members of the 'items' array refers to a 'socket' whose
+associated 0MQ 'context' was terminated.
+*EFAULT*::
+The provided 'items' was not valid (NULL).
+*EINTR*::
+The operation was interrupted by delivery of a signal before any events were
+available.
+
+
+EXAMPLE
+-------
+.Polling indefinitely for input events on both a 0MQ socket and a standard socket.
+----
+zmq_pollitem_t items [2];
+/* First item refers to 0MQ socket 'socket' */
+items[0].socket = socket;
+items[0].events = ZMQ_POLLIN;
+/* Second item refers to standard socket 'fd' */
+items[1].socket = NULL;
+items[1].fd = fd;
+items[1].events = ZMQ_POLLIN;
+/* Poll for events indefinitely */
+int rc = zmq_poll (items, 2, -1);
+assert (rc >= 0);
+/* Returned events will be stored in items[].revents */
+----
+
+
+SEE ALSO
+--------
+linkzmq:zmq_socket[3]
+linkzmq:zmq_send[3]
+linkzmq:zmq_recv[3]
+linkzmq:zmq[7]
+
+Your operating system documentation for the _poll()_ system call.
+
+
+AUTHORS
+-------
+This page was written by the 0MQ community. To make a change please
+read the 0MQ Contribution Policy at <http://www.zeromq.org/docs:contributing>.

data/vendor/github.com/zeromq/libzmq/doc/zmq_proxy.txt

@@ -0,0 +1,99 @@
+zmq_proxy(3)
+============
+
+NAME
+----
+zmq_proxy - start built-in 0MQ proxy
+
+
+SYNOPSIS
+--------
+*int zmq_proxy (const void '*frontend', const void '*backend', const void '*capture');*
+
+
+DESCRIPTION
+-----------
+The _zmq_proxy()_ function starts the built-in 0MQ proxy in the current
+application thread.
+
+The proxy connects a frontend socket to a backend socket. Conceptually, data
+flows from frontend to backend. Depending on the socket types, replies may flow
+in the opposite direction. The direction is conceptual only; the proxy is fully
+symmetric and there is no technical difference between frontend and backend.
+
+Before calling _zmq_proxy()_ you must set any socket options, and connect or
+bind both frontend and backend sockets. The two conventional proxy models are:
+
+_zmq_proxy()_ runs in the current thread and returns only if/when the current
+context is closed.
+
+If the capture socket is not NULL, the proxy shall send all messages, received
+on both frontend and backend, to the capture socket. The capture socket should
+be a 'ZMQ_PUB', 'ZMQ_DEALER', 'ZMQ_PUSH', or 'ZMQ_PAIR' socket.
+
+Refer to linkzmq:zmq_socket[3] for a description of the available socket types.
+
+EXAMPLE USAGE
+-------------
+
+Shared Queue
+~~~~~~~~~~~~
+
+When the frontend is a ZMQ_ROUTER socket, and the backend is a ZMQ_DEALER
+socket, the proxy shall act as a shared queue that collects requests from a
+set of clients, and distributes these fairly among a set of services.
+Requests shall be fair-queued from frontend connections and distributed evenly
+across backend connections. Replies shall automatically return to the client
+that made the original request.
+
+Forwarder
+~~~~~~~~~
+
+When the frontend is a ZMQ_XSUB socket, and the backend is a ZMQ_XPUB socket,
+the proxy shall act as a message forwarder that collects messages from a set
+of publishers and forwards these to a set of subscribers. This may be used to
+bridge networks transports, e.g. read on tcp:// and forward on pgm://.
+
+Streamer
+~~~~~~~~
+
+When the frontend is a ZMQ_PULL socket, and the backend is a ZMQ_PUSH socket,
+the proxy shall collect tasks from a set of clients and forwards these to a set
+of workers using the pipeline pattern.
+
+RETURN VALUE
+------------
+The _zmq_proxy()_ function always returns `-1` and 'errno' set to *ETERM* or
+*EINTR* (the 0MQ 'context' associated with either of the specified sockets was
+terminated).
+
+
+EXAMPLE
+-------
+.Creating a shared queue proxy
+----
+//  Create frontend and backend sockets
+void *frontend = zmq_socket (context, ZMQ_ROUTER);
+assert (backend);
+void *backend = zmq_socket (context, ZMQ_DEALER);
+assert (frontend);
+//  Bind both sockets to TCP ports
+assert (zmq_bind (frontend, "tcp://*:5555") == 0);
+assert (zmq_bind (backend, "tcp://*:5556") == 0);
+//  Start the queue proxy, which runs until ETERM
+zmq_proxy (frontend, backend, NULL);
+----
+
+
+SEE ALSO
+--------
+linkzmq:zmq_bind[3]
+linkzmq:zmq_connect[3]
+linkzmq:zmq_socket[3]
+linkzmq:zmq[7]
+
+
+AUTHORS
+-------
+This page was written by the 0MQ community. To make a change please
+read the 0MQ Contribution Policy at <http://www.zeromq.org/docs:contributing>.