thijn/SqMod
1
0
Fork 0
mirror of https://github.com/VCMP-SqMod/SqMod.git synced 2026-02-13 01:37:14 +01:00
Code Releases Activity

Update WIP discord and some vendors.

Browse Source 
CPR has features disabled and PCRE is fully disabled until updated to new code.
This commit is contained in:
Sandu Liviu Catalin
2023-08-05 21:31:33 +03:00
parent e0761bf3b9
commit 9298065cef
1562 changed files with 55070 additions and 76299 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
vendor/ZMQ/doc/Makefile.am vendored
View File

@@ -10,7 +10,7 @@ MAN3 = zmq_bind.3 zmq_unbind.3 zmq_connect.3 zmq_connect_peer.3 zmq_disconnect.3
zmq_send.3 zmq_recv.3 zmq_send_const.3 \
zmq_msg_get.3 zmq_msg_set.3 zmq_msg_more.3 zmq_msg_gets.3 \
zmq_getsockopt.3 zmq_setsockopt.3 \
zmq_socket.3 zmq_socket_monitor.3 zmq_poll.3 \
zmq_socket.3 zmq_socket_monitor.3 zmq_poll.3 zmq_ppoll.3 \
zmq_socket_monitor_versioned.3 \
zmq_errno.3 zmq_strerror.3 zmq_version.3 \
zmq_sendmsg.3 zmq_recvmsg.3 \

8
vendor/ZMQ/doc/zmq.txt vendored
View File

@@ -273,8 +273,8 @@ Main web site: <http://www.zeromq.org/>
Report bugs to the 0MQ development mailing list: <zeromq-dev@lists.zeromq.org>
COPYING
LICENSE
-------
Free use of this software is granted under the terms of the GNU Lesser General
Public License (LGPL). For details see the files `COPYING` and `COPYING.LESSER`
included with the 0MQ distribution.
Free use of this software is granted under the terms of the Mozilla Public
License Version 2.0 (MPL-2.0). For details see the file `LICENSE` included with
the 0MQ distribution.

3
vendor/ZMQ/doc/zmq_ctx_set.txt vendored
View File

@@ -66,7 +66,8 @@ The 'ZMQ_THREAD_PRIORITY' argument sets scheduling priority for
internal context's thread pool. This option is not available on windows.
Supported values for this option depend on chosen scheduling policy.
On Linux, when the scheduler policy is SCHED_OTHER, SCHED_IDLE or SCHED_BATCH, the OS scheduler
will not use the thread priority but rather the thread "nice value"; in such cases
will not use the thread priority but rather the thread "nice value"; in such cases,
if 'ZMQ_THREAD_PRIORITY' is set to a strictly positive value,
the system call "nice" will be used to set the nice value to -20 (max priority) instead of
adjusting the thread priority (which must be zero for those scheduling policies).
Details can be found in sched.h file, or at http://man7.org/linux/man-pages/man2/sched_setscheduler.2.html.

2
vendor/ZMQ/doc/zmq_disconnect.txt vendored
View File

@@ -19,7 +19,7 @@ by the 'socket' argument from the endpoint specified by the 'endpoint'
argument. Note the actual disconnect system call might occur at a later time.
Upon disconnection the will also stop receiving messages originating from
this endpoint. Moreover, the socket will no longuer be able
this endpoint. Moreover, the socket will no longer be able
to queue outgoing messages to this endpoint. The outgoing message queue
associated with the endpoint will be discarded. However, if the socket's linger
period is non-zero, libzmq will still attempt to transmit these discarded messages,

175
vendor/ZMQ/doc/zmq_getsockopt.txt vendored
View File

@@ -619,22 +619,22 @@ Default value:: 100
Applicable socket types:: all, only for connection-oriented transports
ZMQ_RECONNECT_IVL_MAX: Retrieve maximum reconnection interval
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The 'ZMQ_RECONNECT_IVL_MAX' option shall retrieve the maximum reconnection
interval for the specified 'socket'. This is the maximum period 0MQ shall wait
between attempts to reconnect. On each reconnect attempt, the previous interval
shall be doubled untill ZMQ_RECONNECT_IVL_MAX is reached. This allows for
exponential backoff strategy. Default value means no exponential backoff is
performed and reconnect interval calculations are only based on
ZMQ_RECONNECT_IVL.
ZMQ_RECONNECT_IVL_MAX: Retrieve max reconnection interval
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The 'ZMQ_RECONNECT_IVL_MAX' option shall retrieve the max reconnection interval
for the specified 'socket'. 0MQ shall wait at most the configured interval between
reconnection attempts. The interval grows exponentionally (i.e.: it is doubled)
with each attempt until it reaches ZMQ_RECONNECT_IVL_MAX. Default value means
that the reconnect interval is based exclusively on ZMQ_RECONNECT_IVL and no
exponential backoff is performed.
NOTE: Values less than ZMQ_RECONNECT_IVL will be ignored.
NOTE: Value has to be greater or equal than ZMQ_RECONNECT_IVL, or else it will
be ignored.
[horizontal]
Option value type:: int
Option value unit:: milliseconds
Default value:: 0 (only use ZMQ_RECONNECT_IVL)
Default value:: 0 (ZMQ_RECONNECT_IVL will be used)
Applicable socket types:: all, only for connection-oriented transport
@@ -983,6 +983,159 @@ Default value:: 8192
Applicable socket types:: All, when using TCP, IPC, PGM or NORM transport.
ZMQ_TOPICS_COUNT: Number of topic subscriptions received
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Gets the number of topic (prefix) subscriptions either
* received on a (X)PUB socket from all the connected (X)SUB sockets or
* acknowledged on an (X)SUB socket from all the connected (X)PUB sockets
NOTE: in DRAFT state, not yet available in stable releases.
[horizontal]
Option value type:: int
Option value unit:: N/A
Default value:: 0
Applicable socket types:: ZMQ_PUB, ZMQ_XPUB, ZMQ_SUB, ZMQ_XSUB
ZMQ_NORM_MODE: Retrieve NORM Sender Mode
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Gets the NORM sender mode to control the operation of the NORM transport. NORM
supports fixed rate operation (0='ZMQ_NORM_FIXED'), congestion control mode
(1='ZMQ_NORM_CC'), loss-tolerant congestion control (2='ZMQ_NORM_CCL'), explicit
congestion notification (ECN)-enabled congestion control (3='ZMQ_NORM_CCE'), and
ECN-only congestion control (4='ZMQ_NORM_CCE_ECNONLY'). The default value is
TCP-friendly congestion control mode. Fixed rate mode (using datarate set by
'ZMQ_RATE') offers better performance, but care must be taken to prevent data
loss.
NOTE: in DRAFT state, not yet available in stable releases.
[horizontal]
Option value type:: int
Option value unit:: 0, 1, 2, 3, 4
Default value:: 1 ('ZMQ_NORM_CC')
Applicable socket types:: All, when using NORM transport.
ZMQ_NORM_UNICAST_NACK: Retrieve NORM Unicast NACK mode
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Retrieves status of NORM unicast NACK mode setting for multicast receivers. If
set, NORM receiver will send Negative ACKnowledgements (NACKs) back to the
sender using unicast instead of multicast. NORM transport endpoints specifying
a unicast address will use unicast NACKs by default (without setting
'ZMQ_NORM_UNICAST_NACK').
NOTE: in DRAFT state, not yet available in stable releases.
[horizontal]
Option value type:: int
Option value unit:: boolean
Default value:: 0 (false)
Applicable socket types:: All, when using NORM transport.
ZMQ_NORM_BUFFER_SIZE: Retrieve NORM buffer size
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Gets NORM buffer size for NORM transport sender, receiver, and stream.
NOTE: in DRAFT state, not yet available in stable releases.
[horizontal]
Option value type:: int
Option value unit:: kilobytes
Default value:: 2048
Applicable socket types:: All, when using NORM transport.
ZMQ_NORM_SEGMENT_SIZE: Retrieve NORM segment size
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Gets NORM sender segment size, which is the maximum message payload size of
individual NORM messages (ZMQ messages may be split over multiple NORM
messages). Ideally, this value should fit within the system/network maximum
transmission unit (MTU) after accounting for additional NORM message headers
(up to 48 bytes).
NOTE: in DRAFT state, not yet available in stable releases.
[horizontal]
Option value type:: int
Option value unit:: bytes
Default value:: 1400
Applicable socket types:: All, when using NORM transport.
ZMQ_NORM_BLOCK_SIZE: Retrieve NORM block size
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Gets NORM sender block size, which is the number of segments in a NORM FEC
coding block. NORM repair operations take place at block boundaries. Maximum
value is 255, but parity packets ('ZMQ_NORM_NUM_PARITY') are limited to a value
of (255 - 'ZMQ_NORM_BLOCK_SIZE'). Minimum value is ('ZMQ_NORM_NUM_PARITY' + 1).
Effective value may be different based on the settings of 'ZMQ_NORM_NUM_PARITY'
and 'ZMQ_NORM_NUM_AUTOPARITY' if invalid settings are provided.
NOTE: in DRAFT state, not yet available in stable releases.
[horizontal]
Option value type:: int
Option value unit:: >0, <=255
Default value:: 16
Applicable socket types:: All, when using NORM transport.
ZMQ_NORM_NUM_PARITY: Retrieve NORM parity segment setting
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Gets the maximum number of NORM parity symbol segments that the sender is
willing to calculate per FEC coding block for the purpose of reparing lost data.
Maximum value is 255, but is further limited to a value of
(255 - 'ZMQ_NORM_BLOCK_SIZE'). Minimum value is 'ZMQ_NORM_NUM_AUTOPARITY'.
Effective value may be different based on the setting of
'ZMQ_NORM_NUM_AUTOPARITY' if invalid settings are provided.
NOTE: in DRAFT state, not yet available in stable releases.
[horizontal]
Option value type:: int
Option value unit:: >0, <255
Default value:: 4
Applicable socket types:: All, when using NORM transport.
ZMQ_NORM_NUM_AUTOPARITY: Retrieve proactive NORM parity segment setting
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Gets the number of NORM parity symbol segments that the sender will proactively
send at the end of each FEC coding block. By default, no proactive parity
segments will be sent; instead, parity segments will only be sent in response to
repair requests (NACKs). Maximum value is 255, but is further limited to a
maximum value of 'ZMQ_NORM_NUM_PARITY'.
NOTE: in DRAFT state, not yet available in stable releases.
[horizontal]
Option value type:: int
Option value unit:: >=0, <255
Default value:: 0
Applicable socket types:: All, when using NORM transport.
ZMQ_NORM_PUSH: Retrieve NORM push mode
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Gets status of NORM stream push mode, which alters the behavior of the sender
when enqueueing new data. By default, NORM will stop accepting new messages
while waiting for old data to be transmitted and/or repaired. Enabling push mode
discards the oldest data (which may be pending repair or may never have been
transmitted) in favor of accepting new data. This may be useful in cases where
it is more important to quickly deliver new data instead of reliably delivering
older data.
NOTE: in DRAFT state, not yet available in stable releases.
[horizontal]
Option value type:: int
Option value unit:: boolean
Default value:: 0 (false)
Applicable socket types:: All, when using NORM transport.
RETURN VALUE
------------

2
vendor/ZMQ/doc/zmq_pgm.txt vendored
View File

@@ -134,7 +134,7 @@ CONFIGURATION
-------------
The PGM is protocol is capable of multicasting data at high rates (500Mbps+)
with large messages (1MB+), however it requires setting the relevent ZMQ socket
with large messages (1MB+), however it requires setting the relevant ZMQ socket
options that are documented in linkzmq:zmq_setsockopt[3]:
* The 'ZMQ_RATE' should be set sufficiently high, e.g. 1Gbps

4
vendor/ZMQ/doc/zmq_poll.txt vendored
View File

@@ -71,7 +71,7 @@ _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.
is urgent data to read. Refer to the POLLPRI flag for more information.
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.
@@ -86,7 +86,7 @@ The *zmq_pollitem_t* array must only be used by the thread which
will/is calling _zmq_poll_.
If a socket is contained in multiple *zmq_pollitem_t* arrays, each owned by a
different thread, the socket itself needs to be thead-safe (Server, Client, ...).
different thread, the socket itself needs to be thread-safe (Server, Client, ...).
Otherwise, behaviour is undefined.

30
vendor/ZMQ/doc/zmq_poller.txt vendored
View File

@@ -12,7 +12,7 @@ SYNOPSIS
*void *zmq_poller_new (void);*
*int zmq_poller_destroy (void '*poller_p');*
*int zmq_poller_destroy (void '****poller_p');*
*int zmq_poller_size (void '*poller');*
@@ -91,7 +91,7 @@ associated with the socket registration, and requires that the _socket_
remains valid.
_zmq_poller_add_fd_, _zmq_poller_modify_fd_ and _zmq_poller_remove_fd_ are
analogous to the previous functions but manage regular file descriptiors
analogous to the previous functions but manage regular file descriptors
registered with a poller. On Windows, these functions can only be used with
WinSock sockets.
@@ -185,7 +185,7 @@ For 0MQ sockets this flag has no effect on the _zmq_poller_add_ and
_zmq_poller_modify_ functions, and is never set in the
'events' member of the zmq_poller_event_t structure.
For standard sockets this means there
is urgent data to read. Refer to the POLLPRI flag for more informations.
is urgent data to read. Refer to the POLLPRI flag for more information.
For a file descriptor, refer to your OS documentation: as an example, GPIO
interrupts are signaled through a POLLPRI event.
This flag has no effect on Windows.
@@ -218,21 +218,25 @@ All other functions return 0 in case of a successful execution.
ERRORS
------
On _zmq_poller_new_:
*ENOMEM*::
A new poller could not be allocated successfully.
On _zmq_poller_destroy_:
*EFAULT*::
_poller_p_ did not point to a valid poller. Note that passing an invalid pointer (e.g.
pointer to deallocated memory) may cause undefined behaviour (e.g. an access violation).
On _zmq_poller_size_:
*EFAULT*::
_poller_ did not point to a valid poller. Note that passing an
invalid pointer (e.g. pointer to deallocated memory) may cause undefined
behaviour (e.g. an access violation).
On _zmq_poller_add_, _zmq_poller_modify_ and _zmq_poller_remove_:
*EFAULT*::
_poller_ did not point to a valid poller. Note that passing an
invalid pointer (e.g. pointer to deallocated memory) may cause undefined
@@ -243,10 +247,12 @@ invalid pointer (e.g. pointer to deallocated memory) may cause undefined
behaviour (e.g. an access violation).
On _zmq_poller_add_:
*EMFILE*::
TODO
On _zmq_poller_add_ or _zmq_poller_add_fd_:
*ENOMEM*::
Necessary resources could not be allocated.
*EINVAL*::
@@ -254,14 +260,17 @@ _socket_ resp. _fd_ was already registered with the poller.
On _zmq_poller_modify_, _zmq_poller_modify_fd_, _zmq_poller_remove_ or
_zmq_poller_remove_fd_:
*EINVAL*::
_socket_ resp. _fd_ was not registered with the poller.
On _zmq_poller_add_fd_, _zmq_poller_modify_fd_ and _zmq_poller_remove_fd_:
*EBADF**:
*EBADF*::
The _fd_ specified was the retired fd.
On _zmq_poller_wait_ and _zmq_poller_wait_all_:
*ENOMEM*::
Necessary resources could not be allocated.
*ETERM*::
@@ -278,6 +287,7 @@ available.
No registered event was signalled before the timeout was reached.
On _zmq_poller_fd_:
*EINVAL*::
The poller has no associated file descriptor.
*EFAULT*::
@@ -289,16 +299,24 @@ EXAMPLE
----
void *poller = zmq_poller_new ();
zmq_poller_event_t events [2];
/* First item refers to 0MQ socket 'socket' */
zmq_poller_add (poller, socket, NULL, ZMQ_POLLIN);
/* Second item refers to standard socket 'fd' */
zmq_poller_add_fd (poller, fd, NULL, ZMQ_POLLIN);
zmq_poller_event_t events [2];
/* Poll for events indefinitely */
int rc = zmq_poller_wait_all (poller, events, 2, -1);
assert (rc >= 0);
/* Returned events will be stored in 'events' */
zmq_poller_destroy (poller);
for (int i = 0; i < 2; ++i) {
if (events[i].socket == socket && events[i].events & ZMQ_POLLIN) {
// ...
} else if (events[i].fd == fd && events[i].events & ZMQ_POLLIN)) {
// ...
}
}
zmq_poller_destroy (&poller);
----

140
vendor/ZMQ/doc/zmq_ppoll.txt vendored Normal file
View File

@@ -0,0 +1,140 @@
zmq_poll(3)
===========
NAME
----
zmq_ppoll - input/output multiplexing with signal mask
SYNOPSIS
--------
*int zmq_ppoll (zmq_pollitem_t '*items', int 'nitems', long 'timeout', const sigset_t '*sigmask');*
DESCRIPTION
-----------
The relationship between _zmq_poll()_ and _zmq_ppoll()_ is analogous to the
relationship between poll(2) and ppoll(2) and between select(2) and
pselect(2): _zmq_ppoll()_ allows an application to safely wait until either a
file descriptor becomes ready or until a signal is caught.
When using _zmq_ppoll()_ with 'sigmask' set to NULL, its behavior is identical
to that of _zmq_poll()_. See linkzmq:zmq_poll[3] for more on this.
To make full use of _zmq_ppoll()_, a non-NULL pointer to a signal mask must be
constructed and passed to 'sigmask'. See sigprocmask(2) for more details. When
this is done, inside the actual _ppoll()_ (or _pselect()_, see note below)
system call, an atomic operation consisting of three steps is performed:
1. The current signal mask is replaced by the one pointed to by 'sigmask'.
2. The actual _poll()_ call is done.
3. The original signal mask is restored.
Because these operations are done atomically, there is no opportunity for race
conditions in between the calls changing the signal mask and the poll/select
system call. This means that only during this (atomic) call, we can unblock
certain signals, so that they can be handled *at that time only*, not outside
of the call. This means that effectively, we extend our poller into a function
that not only watches sockets for changes, but also watches the "POSIX signal
socket" for incoming signals. At other times, these signals will be blocked,
and we will not have to deal with interruptions in system calls at these other
times.
NOTE: The _zmq_ppoll()_ function may be implemented or emulated using operating
system interfaces other than _ppoll()_, and as such may be subject to the
limits of those interfaces in ways not defined in this documentation.
NOTE: There is no _ppoll_ or _pselect_ on Windows, so _zmq_ppoll()_ is not
supported in Windows builds. It is still callable, but its 'sigmask' has void
pointer type (because 'sigset_t' is also not available on Windows) and
_zmq_ppoll()_ will return with an error (see error section below).
THREAD SAFETY
-------------
The *zmq_pollitem_t* array must only be used by the thread which
will/is calling _zmq_ppoll_.
If a socket is contained in multiple *zmq_pollitem_t* arrays, each owned by a
different thread, the socket itself needs to be thead-safe (Server, Client, ...).
Otherwise, behaviour is undefined.
RETURN VALUE
------------
Upon successful completion, the _zmq_ppoll()_ 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_ppoll()_ 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.
*EINTR*::
The operation was interrupted by delivery of a signal before any events were
available.
*ENOTSUP*::
_zmq_ppoll()_ was not activated in this build.
EXAMPLE
-------
.Polling indefinitely for input events on both a 0MQ socket and a standard socket.
See the _example section_ of linkzmq:zmq_poll[3]. One only needs to replace
the _zmq_poll_ call with _zmq_ppoll_ and add a _NULL_ argument for the 'sigmask'
parameter.
.Handle SIGTERM during _zmq_ppoll_ (and block it otherwise).
----
// simple global signal handler for SIGTERM
static bool sigterm_received = false;
void handle_sigterm (int signum) {
sigterm_received = true;
}
// set up signal mask and install handler for SIGTERM
sigset_t sigmask, sigmask_without_sigterm;
sigemptyset(&sigmask);
sigaddset(&sigmask, SIGTERM);
sigprocmask(SIG_BLOCK, &sigmask, &sigmask_without_sigterm);
struct sigaction sa;
memset(&sa, '\0', sizeof(sa));
sa.sa_handler = handle_sigterm;
// poll
zmq_pollitem_t items [1];
// Just one item, which refers to 0MQ socket 'socket' */
items[0].socket = socket;
items[0].events = ZMQ_POLLIN;
// Poll for events indefinitely, but also exit on SIGTERM
int rc = zmq_poll (items, 2, -1, &sigmask_without_sigterm);
if (rc < 0 && errno == EINTR && sigterm_received) {
// do your SIGTERM business
} else {
// do your non-SIGTERM error handling
}
----
SEE ALSO
--------
linkzmq:zmq_poll[3]
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>.

100
vendor/ZMQ/doc/zmq_proxy_steerable.txt vendored
View File

@@ -3,7 +3,7 @@ zmq_proxy_steerable(3)
NAME
----
zmq_proxy_steerable - built-in 0MQ proxy with control flow
zmq_proxy_steerable - DEPRECATED
SYNOPSIS
@@ -14,101 +14,9 @@ SYNOPSIS
DESCRIPTION
-----------
The _zmq_proxy_steerable()_ function starts the built-in 0MQ proxy in the
current application thread, as _zmq_proxy()_ do. Please, refer to this function
for the general description and usage. We describe here only the additional
control flow provided by the socket passed as the fourth argument "control".
If the control socket is not NULL, the proxy supports control flow. If
'PAUSE' is received on this socket, the proxy suspends its activities. If
'RESUME' is received, it goes on. If 'TERMINATE' is received, it terminates
smoothly. If 'STATISTICS' is received, the proxy will reply on the control socket
sending a multipart message with 8 frames, each with an unsigned integer 64-bit
wide that provide in the following order:
- number of messages received by the frontend socket
- number of bytes received by the frontend socket
- number of messages sent out the frontend socket
- number of bytes sent out the frontend socket
- number of messages received by the backend socket
- number of bytes received by the backend socket
- number of messages sent out the backend socket
- number of bytes sent out the backend socket
At start, the proxy runs normally as if zmq_proxy was used.
If the control socket is NULL, the function behave exactly as if linkzmq:zmq_proxy[3]
had been called.
Refer to linkzmq:zmq_socket[3] for a description of the available socket types.
Refer to linkzmq:zmq_proxy[3] for a description of the zmq_proxy.
EXAMPLE USAGE
-------------
cf zmq_proxy
RETURN VALUE
------------
The _zmq_proxy_steerable()_ function returns 0 if TERMINATE is sent to its
control socket. Otherwise, it returns `-1` and 'errno' set to *ETERM* or
*EINTR* (the 0MQ 'context' associated with either of the specified sockets was
terminated) or *EFAULT* (the provided 'frontend' or 'backend' was invalid).
EXAMPLE
-------
.Creating a shared queue proxy
----
// Create frontend, backend and control sockets
void *frontend = zmq_socket (context, ZMQ_ROUTER);
assert (frontend);
void *backend = zmq_socket (context, ZMQ_DEALER);
assert (backend);
void *control = zmq_socket (context, ZMQ_SUB);
assert (control);
// Bind sockets to TCP ports
assert (zmq_bind (frontend, "tcp://*:5555") == 0);
assert (zmq_bind (backend, "tcp://*:5556") == 0);
assert (zmq_connect (control, "tcp://*:5557") == 0);
// Subscribe to the control socket since we have chosen SUB here
assert (zmq_setsockopt (control, ZMQ_SUBSCRIBE, "", 0));
// Start the queue proxy, which runs until ETERM or "TERMINATE"
// received on the control socket
zmq_proxy_steerable (frontend, backend, NULL, control);
----
.Set up a controller in another node, process or whatever
----
void *control = zmq_socket (context, ZMQ_PUB);
assert (control);
assert (zmq_bind (control, "tcp://*:5557") == 0);
// pause the proxy
assert (zmq_send (control, "PAUSE", 5, 0) == 0);
// resume the proxy
assert (zmq_send (control, "RESUME", 6, 0) == 0);
// terminate the proxy
assert (zmq_send (control, "TERMINATE", 9, 0) == 0);
// check statistics
assert (zmq_send (control, "STATISTICS", 10, 0) == 0);
zmq_msg_t stats_msg;
while (1) {
assert (zmq_msg_init (&stats_msg) == 0);
assert (zmq_recvmsg (control, &stats_msg, 0) == sizeof (uint64_t));
assert (rc == sizeof (uint64_t));
printf ("Stat: %lu\n", *(unsigned long int *)zmq_msg_data (&stats_msg));
if (!zmq_msg_get (&stats_msg, ZMQ_MORE))
break;
assert (zmq_msg_close (&stats_msg) == 0);
}
assert (zmq_msg_close (&stats_msg) == 0);
---
The _zmq_proxy_steerable()_ function is an empty stub that only returns an
*EOPNOTSUPP* error, as the author did not provide a relicense agreement for
the Mozilla Public License v2 relicense of libzmq.
SEE ALSO

185
vendor/ZMQ/doc/zmq_setsockopt.txt vendored
View File

@@ -257,7 +257,7 @@ Default value:: NULL
Applicable socket types:: ZMQ_ROUTER, ZMQ_SERVER and ZMQ_PEER
ZMQ_HICCUP_MSG: set a hiccup message that the socket will generate when connected peer temporarly disconnect
ZMQ_HICCUP_MSG: set a hiccup message that the socket will generate when connected peer temporarily disconnect
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When set, the socket will generate a hiccup message when connect peer has been disconnected.
You may set this on DEALER, CLIENT and PEER sockets.
@@ -527,9 +527,9 @@ ZMQ_METADATA: Add application metadata properties to a socket
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The _ZMQ_METADATA_ option shall add application metadata to the specified _socket_,
the metadata is exchanged with peers during connection setup. A metadata property is
specfied as a string, delimited by a colon, starting with the metadata _property_
specified as a string, delimited by a colon, starting with the metadata _property_
followed by the metadata value, for example "X-key:value".
_Property_ names are restrited to maximum 255 characters and must be prefixed by "X-".
_Property_ names are restricted to maximum 255 characters and must be prefixed by "X-".
Multiple application metadata properties can be added to a socket by executing zmq_setsockopt()
multiple times. As the argument is a null-terminated string, binary data must be encoded
before it is added e.g. using Z85 (linkzmq:zmq_z85_encode[3]).
@@ -750,21 +750,22 @@ Default value:: 100
Applicable socket types:: all, only for connection-oriented transports
ZMQ_RECONNECT_IVL_MAX: Set maximum reconnection interval
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The 'ZMQ_RECONNECT_IVL_MAX' option shall set the maximum reconnection interval
for the specified 'socket'. This is the maximum period 0MQ shall wait between
attempts to reconnect. On each reconnect attempt, the previous interval shall be
doubled untill ZMQ_RECONNECT_IVL_MAX is reached. This allows for exponential
backoff strategy. Default value means no exponential backoff is performed and
reconnect interval calculations are only based on ZMQ_RECONNECT_IVL.
ZMQ_RECONNECT_IVL_MAX: Set max reconnection interval
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The 'ZMQ_RECONNECT_IVL_MAX' option shall set the max reconnection interval for
the specified 'socket'. 0MQ shall wait at most the configured interval between
reconnection attempts. The interval grows exponentionally (i.e.: it is doubled)
with each attempt until it reaches ZMQ_RECONNECT_IVL_MAX. Default value means
that the reconnect interval is based exclusively on ZMQ_RECONNECT_IVL and no
exponential backoff is performed.
NOTE: Values less than ZMQ_RECONNECT_IVL will be ignored.
NOTE: Value has to be greater or equal than ZMQ_RECONNECT_IVL, or else it will
be ignored.
[horizontal]
Option value type:: int
Option value unit:: milliseconds
Default value:: 0 (only use ZMQ_RECONNECT_IVL)
Default value:: 0 (ZMQ_RECONNECT_IVL will be used)
Applicable socket types:: all, only for connection-oriented transports
@@ -784,7 +785,7 @@ connection attempts to non-0MQ sockets. Note that when specifying this option
you may also want to set `ZMQ_HANDSHAKE_IVL` -- the default handshake interval
is 30000 (30 seconds), which is typically too large.
The 'ZMQ_RECONNECT_STOP_AFTER_DISCONNECT' option will stop reconnection when
The 'ZMQ_RECONNECT_STOP_AFTER_DISCONNECT' option will stop reconnection when
zmq_disconnect() has been called. This can be useful when the user's request failed
(server not ready), as the socket does not need to continue to reconnect after
user disconnect actively.
@@ -1238,7 +1239,7 @@ Applicable socket types:: ZMQ_XPUB, ZMQ_PUB
ZMQ_XPUB_WELCOME_MSG: set welcome message that will be received by subscriber when connecting
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sets a welcome message the will be recieved by subscriber when connecting.
Sets a welcome message the will be received by subscriber when connecting.
Subscriber must subscribe to the Welcome message before connecting.
Welcome message will also be sent on reconnecting.
For welcome message to work well user must poll on incoming subscription messages on the XPUB socket and handle them.
@@ -1252,6 +1253,21 @@ Default value:: NULL
Applicable socket types:: ZMQ_XPUB
ZMQ_XSUB_VERBOSE_UNSUBSCRIBE: pass duplicate unsubscribe messages on XSUB socket
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sets the 'XSUB' socket behaviour on duplicated unsubscriptions. If enabled, the socket
passes all unsubscribe messages to the caller. If disabled, only the last unsubscription
from each filter will be passed. The default is 0 (disabled).
NOTE: in DRAFT state, not yet available in stable releases.
[horizontal]
Option value type:: int
Option value unit:: 0, 1
Default value:: 0
Applicable socket types:: ZMQ_XSUB
ZMQ_ONLY_FIRST_SUBSCRIBE: Process only first subscribe/unsubscribe in a multipart message
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If set, only the first part of the multipart message is processed as
@@ -1514,6 +1530,145 @@ Default value:: 8192
Applicable socket types:: All, when using TCP, IPC, PGM or NORM transport.
ZMQ_NORM_MODE: NORM Sender Mode
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sets the NORM sender mode to control the operation of the NORM transport. NORM
supports fixed rate operation (0='ZMQ_NORM_FIXED'), congestion control mode
(1='ZMQ_NORM_CC'), loss-tolerant congestion control (2='ZMQ_NORM_CCL'), explicit
congestion notification (ECN)-enabled congestion control (3='ZMQ_NORM_CCE'), and
ECN-only congestion control (4='ZMQ_NORM_CCE_ECNONLY'). The default value is
TCP-friendly congestion control mode. Fixed rate mode (using datarate set by
'ZMQ_RATE') offers better performance, but care must be taken to prevent data
loss. ECN modes will set one of the ECN Capable Transport bits in the given
'ZMQ_TOS' if it is not set already.
NOTE: in DRAFT state, not yet available in stable releases.
[horizontal]
Option value type:: int
Option value unit:: 0, 1, 2, 3, 4
Default value:: 1 ('ZMQ_NORM_CC')
Applicable socket types:: All, when using NORM transport.
ZMQ_NORM_UNICAST_NACK: Set NORM Unicast NACK mode
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If set, NORM receiver will send Negative ACKnowledgements (NACKs) back to the
sender using unicast instead of multicast. NORM transport endpoints specifying
a unicast address will enable this by default, but it is disabled by default for
multicast addresses.
NOTE: in DRAFT state, not yet available in stable releases.
[horizontal]
Option value type:: int
Option value unit:: boolean
Default value:: 0 (false)
Applicable socket types:: All, when using NORM transport.
ZMQ_NORM_BUFFER_SIZE: Set NORM buffer size
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sets NORM buffer size for NORM transport sender, receiver, and stream.
NOTE: in DRAFT state, not yet available in stable releases.
[horizontal]
Option value type:: int
Option value unit:: kilobytes
Default value:: 2048
Applicable socket types:: All, when using NORM transport.
ZMQ_NORM_SEGMENT_SIZE: Set NORM segment size
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sets NORM sender segment size, which is the maximum message payload size of
individual NORM messages (ZMQ messages may be split over multiple NORM
messages). Ideally, this value should fit within the system/network maximum
transmission unit (MTU) after accounting for additional NORM message headers
(up to 48 bytes).
NOTE: in DRAFT state, not yet available in stable releases.
[horizontal]
Option value type:: int
Option value unit:: bytes
Default value:: 1400
Applicable socket types:: All, when using NORM transport.
ZMQ_NORM_BLOCK_SIZE: Set NORM block size
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sets NORM sender block size, which is the number of segments in a NORM FEC
coding block. NORM repair operations take place at block boundaries. Maximum
value is 255, but parity packets ('ZMQ_NORM_NUM_PARITY') are limited to a value
of (255 - 'ZMQ_NORM_BLOCK_SIZE'). Minimum value is ('ZMQ_NORM_NUM_PARITY' + 1).
Effective value may be different based on the settings of 'ZMQ_NORM_NUM_PARITY'
and 'ZMQ_NORM_NUM_AUTOPARITY' if invalid settings are provided.
NOTE: in DRAFT state, not yet available in stable releases.
[horizontal]
Option value type:: int
Option value unit:: >0, <=255
Default value:: 16
Applicable socket types:: All, when using NORM transport.
ZMQ_NORM_NUM_PARITY: Set number of NORM parity segments
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sets the maximum number of NORM parity symbol segments that the sender is
willing to calculate per FEC coding block for the purpose of reparing lost data.
Maximum value is 255, but is further limited to a value of
(255 - 'ZMQ_NORM_BLOCK_SIZE'). Minimum value is 'ZMQ_NORM_NUM_AUTOPARITY'.
Effective value may be different based on the setting of
'ZMQ_NORM_NUM_AUTOPARITY' if invalid settings are provided.
NOTE: in DRAFT state, not yet available in stable releases.
[horizontal]
Option value type:: int
Option value unit:: >0, <255
Default value:: 4
Applicable socket types:: All, when using NORM transport.
ZMQ_NORM_NUM_AUTOPARITY: Set number of proactive NORM parity segments
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sets the number of NORM parity symbol segments that the sender will proactively
send at the end of each FEC coding block. By default, no proactive parity
segments will be sent; instead, parity segments will only be sent in response to
repair requests (NACKs). Maximum value is 255, but is further limited to a
maximum value of 'ZMQ_NORM_NUM_PARITY'.
NOTE: in DRAFT state, not yet available in stable releases.
[horizontal]
Option value type:: int
Option value unit:: >=0, <255
Default value:: 0
Applicable socket types:: All, when using NORM transport.
ZMQ_NORM_PUSH: Enable NORM push mode
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enables NORM stream push mode, which alters the behavior of the sender when
enqueueing new data. By default, NORM will stop accepting new messages while
waiting for old data to be transmitted and/or repaired. Enabling push mode
discards the oldest data (which may be pending repair or may never have been
transmitted) in favor of accepting new data. This may be useful in cases where
it is more important to quickly deliver new data instead of reliably delivering
older data.
NOTE: in DRAFT state, not yet available in stable releases.
[horizontal]
Option value type:: int
Option value unit:: boolean
Default value:: 0 (false)
Applicable socket types:: All, when using NORM transport.
RETURN VALUE
------------
The _zmq_setsockopt()_ function shall return zero if successful. Otherwise it

15
vendor/ZMQ/doc/zmq_socket_monitor_versioned.txt vendored
View File

@@ -188,8 +188,8 @@ The event value is the status code returned by the ZAP handler (i.e. 300,
Supported events (v2)
----------------
ZMQ_EVENT_PIPE_STATS
~~~~~~~~~~~~~~~~~~~~
ZMQ_EVENT_PIPES_STATS
~~~~~~~~~~~~~~~~~~~~~
This event provides two values, the number of messages in each of the two
queues associated with the returned endpoint (respectively egress and ingress).
This event only triggers after calling the function
@@ -244,7 +244,7 @@ EXAMPLE
// in case of error.
static uint64_t
get_monitor_event (void *monitor, uint64_t *value, char **local_address, char **remote_address)
get_monitor_event (void *monitor, uint64_t **value, char **local_address, char **remote_address)
{
// First frame in message contains event number
zmq_msg_t msg;
@@ -267,6 +267,11 @@ get_monitor_event (void *monitor, uint64_t *value, char **local_address, char **
memcpy (&value_count, zmq_msg_data (&msg), sizeof (value_count));
zmq_msg_close (&msg);
if (value) {
*value = (uint64_t *) malloc (value_count * sizeof (uint64_t));
assert (*value);
}
for (uint64_t i = 0; i < value_count; ++i) {
// Subsequent frames in message contain event values
zmq_msg_init (&msg);
@@ -274,8 +279,8 @@ get_monitor_event (void *monitor, uint64_t *value, char **local_address, char **
return -1; // Interrupted, presumably
assert (zmq_msg_more (&msg));
if (value_ && value_ + i)
memcpy (value_ + i, zmq_msg_data (&msg), sizeof (*value_));
if (value && *value)
memcpy (&(*value)[i], zmq_msg_data (&msg), sizeof (uint64_t));
zmq_msg_close (&msg);
}

4
vendor/ZMQ/doc/zmq_tcp.txt vendored
View File

@@ -67,7 +67,7 @@ A 'peer address' may be specified by either of the following:
* The IPv4 or IPv6 address of the peer, in its numeric representation.
Note: A description of the ZeroMQ Message Transport Protocol (ZMTP) which is
used by the TCP transport can be found at <http://rfc.zeromq.org/spec:15>
used by the TCP transport can be found at <http://rfc.zeromq.org/spec:23>
HWM
@@ -76,7 +76,7 @@ HWM
For the TCP transport, the high water mark (HWM) mechanism works in conjunction
with the TCP socket buffers handled at OS level.
Depending on the OS and several other factors the size of such TCP buffers will
be different. Moreover TCP buffers provided by the OS will accomodate a varying
be different. Moreover TCP buffers provided by the OS will accommodate a varying
number of messages depending on the size of messages (unlike ZMQ HWM settings
the TCP socket buffers are measured in bytes and not messages).

4
vendor/ZMQ/doc/zmq_udp.txt vendored
View File

@@ -28,7 +28,7 @@ For the UDP transport, the transport is `udp`.
The meaning of the 'address' part is defined below.
Binding a socket
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
----------------
With 'udp' we can only bind the 'ZMQ_DISH' socket type.
When binding a socket using _zmq_bind()_ with the 'udp'
transport the 'endpoint' shall be interpreted as an 'interface' followed by a
@@ -45,7 +45,7 @@ The UDP port number may be specified a numeric value, usually above
1024 on POSIX systems.
Connecting a socket
~~~~~~~~~~~~~~~~~~~
-------------------
With 'udp' we can only connect the 'ZMQ_RADIO' socket type.
When connecting a socket to a peer address using _zmq_connect()_ with the 'udp'
transport, the 'endpoint' shall be interpreted as a 'peer address' followed by

2
vendor/ZMQ/doc/zmq_unbind.txt vendored
View File

@@ -18,7 +18,7 @@ The _zmq_unbind()_ function shall unbind a socket specified
by the 'socket' argument from the endpoint specified by the 'endpoint'
argument.
Addionally the incoming message queue associated with the endpoint will be
Additionally the incoming message queue associated with the endpoint will be
discarded. This means that after unbinding an endpoint it is possible to
received messages originating from that same endpoint if they were already
present in the incoming message queue before unbinding.