2010-02-10 16:18:46 +01:00
|
|
|
zmq_setsockopt(3)
|
|
|
|
=================
|
|
|
|
|
|
|
|
|
|
|
|
NAME
|
|
|
|
----
|
|
|
|
|
2010-03-09 18:47:31 +01:00
|
|
|
zmq_setsockopt - set 0MQ socket options
|
2010-02-10 16:18:46 +01:00
|
|
|
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
--------
|
2010-03-09 18:47:31 +01:00
|
|
|
*int zmq_setsockopt (void '*socket', int 'option_name', const void '*option_value', size_t 'option_len');*
|
2010-02-10 16:18:46 +01:00
|
|
|
|
2012-03-15 15:06:44 +03:00
|
|
|
Caution: All options, with the exception of ZMQ_SUBSCRIBE, ZMQ_UNSUBSCRIBE,
|
2013-11-25 13:31:21 +10:30
|
|
|
ZMQ_LINGER, ZMQ_ROUTER_HANDOVER, ZMQ_ROUTER_MANDATORY, ZMQ_PROBE_ROUTER,
|
2016-06-03 13:57:30 +01:00
|
|
|
ZMQ_XPUB_VERBOSE, ZMQ_XPUB_VERBOSER, ZMQ_REQ_CORRELATE,
|
2015-07-21 23:35:50 +01:00
|
|
|
ZMQ_REQ_RELAXED, ZMQ_SNDHWM and ZMQ_RCVHWM, only take effect for
|
|
|
|
subsequent socket bind/connects.
|
2013-09-17 13:33:24 +02:00
|
|
|
|
|
|
|
Specifically, security options take effect for subsequent bind/connect calls,
|
|
|
|
and can be changed at any time to affect subsequent binds and/or connects.
|
2010-02-10 16:18:46 +01:00
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
-----------
|
2010-03-09 18:47:31 +01:00
|
|
|
The _zmq_setsockopt()_ function shall set the option specified by the
|
|
|
|
'option_name' argument to the value pointed to by the 'option_value' argument
|
|
|
|
for the 0MQ socket pointed to by the 'socket' argument. The 'option_len'
|
2016-11-16 19:50:50 +01:00
|
|
|
argument is the size of the option value in bytes. For options taking a value of
|
|
|
|
type "character string", the provided byte data should either contain no zero
|
|
|
|
bytes, or end in a single zero byte (terminating ASCII NUL character).
|
2010-03-09 18:47:31 +01:00
|
|
|
|
2010-05-31 12:53:40 +02:00
|
|
|
The following socket options can be set with the _zmq_setsockopt()_ function:
|
2010-03-09 18:47:31 +01:00
|
|
|
|
|
|
|
|
|
|
|
ZMQ_AFFINITY: Set I/O thread affinity
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
2010-05-31 12:53:40 +02:00
|
|
|
The 'ZMQ_AFFINITY' option shall set the I/O thread affinity for newly created
|
|
|
|
connections on the specified 'socket'.
|
2010-03-09 18:47:31 +01:00
|
|
|
|
2010-05-28 00:49:13 +02:00
|
|
|
Affinity determines which threads from the 0MQ I/O thread pool associated with
|
|
|
|
the socket's _context_ shall handle newly created connections. A value of zero
|
|
|
|
specifies no affinity, meaning that work shall be distributed fairly among all
|
|
|
|
0MQ I/O threads in the thread pool. For non-zero values, the lowest bit
|
|
|
|
corresponds to thread 1, second lowest bit to thread 2 and so on. For example,
|
|
|
|
a value of 3 specifies that subsequent connections on 'socket' shall be handled
|
|
|
|
exclusively by I/O threads 1 and 2.
|
2010-03-09 18:47:31 +01:00
|
|
|
|
|
|
|
See also linkzmq:zmq_init[3] for details on allocating the number of I/O
|
|
|
|
threads for a specific _context_.
|
|
|
|
|
2010-06-03 14:15:05 +02:00
|
|
|
[horizontal]
|
2010-08-11 17:00:12 +02:00
|
|
|
Option value type:: uint64_t
|
2010-03-09 18:47:31 +01:00
|
|
|
Option value unit:: N/A (bitmap)
|
|
|
|
Default value:: 0
|
|
|
|
Applicable socket types:: N/A
|
|
|
|
|
|
|
|
|
2014-01-01 16:28:30 +01:00
|
|
|
ZMQ_BACKLOG: Set maximum length of the queue of outstanding connections
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The 'ZMQ_BACKLOG' option shall set the maximum length of the queue of
|
|
|
|
outstanding peer connections for the specified 'socket'; this only applies to
|
|
|
|
connection-oriented transports. For details refer to your operating system
|
|
|
|
documentation for the 'listen' function.
|
2010-03-09 18:47:31 +01:00
|
|
|
|
2014-01-01 16:28:30 +01:00
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: connections
|
|
|
|
Default value:: 100
|
|
|
|
Applicable socket types:: all, only for connection-oriented transports.
|
|
|
|
|
|
|
|
|
Add socket option BINDTODEVICE
Linux now supports Virtual Routing and Forwarding (VRF) as per:
https://www.kernel.org/doc/Documentation/networking/vrf.txt
In order for an application to bind or connect to a socket with an
address in a VRF, they need to first bind the socket to the VRF device:
setsockopt(sd, SOL_SOCKET, SO_BINDTODEVICE, dev, strlen(dev)+1);
Note "dev" is the VRF device, eg. VRF "blue", rather than an interface
enslaved to the VRF.
Add a new socket option, ZMQ_BINDTODEVICE, to bind a socket to a device.
In general, if a socket is bound to a device, eg. an interface, only
packets received from that particular device are processed by the socket.
If device is a VRF device, then subsequent binds/connects to that socket
use addresses in the VRF routing table.
2017-07-28 14:35:09 +01:00
|
|
|
ZMQ_BINDTODEVICE: Set name of device to bind the socket to
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The 'ZMQ_BINDTODEVICE' option binds this socket to a particular device, eg.
|
|
|
|
an interface or VRF. If a socket is bound to an interface, only packets
|
|
|
|
received from that particular interface are processed by the socket. If device
|
|
|
|
is a VRF device, then subsequent binds/connects to that socket use addresses
|
|
|
|
in the VRF routing table.
|
|
|
|
|
|
|
|
NOTE: requires setting CAP_NET_RAW on the compiled program.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: character string
|
|
|
|
Option value unit:: N/A
|
|
|
|
Default value:: not set
|
|
|
|
Applicable socket types:: all, when using TCP or UDP transports.
|
|
|
|
|
|
|
|
|
2021-05-15 06:05:56 +08:00
|
|
|
ZMQ_BUSY_POLL: This removes delays caused by the interrupt and the resultant context switch.
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Busy polling helps reduce latency in the network receive path by allowing socket layer code
|
|
|
|
to poll the receive queue of a network device, and disabling network interrupts. This removes
|
|
|
|
delays caused by the interrupt and the resultant context switch. However, it also increases
|
|
|
|
CPU utilization. Busy polling also prevents the CPU from sleeping, which can incur additional
|
|
|
|
power consumption.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: 0,1
|
|
|
|
Default value:: 0
|
|
|
|
Applicable socket types:: all
|
|
|
|
|
|
|
|
|
2020-02-23 12:17:22 -05:00
|
|
|
ZMQ_CONNECT_RID: Assign the next outbound connection id
|
2014-01-19 17:28:13 -08:00
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
2020-02-23 12:17:22 -05:00
|
|
|
This option name is now deprecated. Use ZMQ_CONNECT_ROUTING_ID instead.
|
|
|
|
ZMQ_CONNECT_RID remains as an alias for now.
|
2014-01-19 17:28:13 -08:00
|
|
|
|
2017-09-07 11:18:50 +02:00
|
|
|
|
2020-02-23 12:17:22 -05:00
|
|
|
ZMQ_CONNECT_ROUTING_ID: Assign the next outbound routing id
|
2017-09-07 11:18:50 +02:00
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
2020-02-23 12:17:22 -05:00
|
|
|
The 'ZMQ_CONNECT_ROUTING_ID' option sets the peer id of the peer connected
|
|
|
|
via the next zmq_connect() call, such that that connection is immediately ready for
|
2017-09-07 11:18:50 +02:00
|
|
|
data transfer with the given routing id. This option applies only to the first
|
2020-02-23 12:17:22 -05:00
|
|
|
subsequent call to zmq_connect(), zmq_connect() calls thereafter use the default
|
|
|
|
connection behaviour.
|
2017-09-07 11:18:50 +02:00
|
|
|
|
2020-02-23 12:17:22 -05:00
|
|
|
Typical use is to set this socket option ahead of each zmq_connect() call.
|
|
|
|
Each connection MUST be assigned a unique routing id. Assigning a
|
|
|
|
routing id that is already in use is not allowed.
|
2014-01-19 17:28:13 -08:00
|
|
|
|
2020-02-23 12:17:22 -05:00
|
|
|
Useful when connecting ROUTER to ROUTER, or STREAM to STREAM, as it
|
|
|
|
allows for immediate sending to peers. Outbound routing id framing requirements
|
2014-01-19 17:28:13 -08:00
|
|
|
for ROUTER and STREAM sockets apply.
|
|
|
|
|
2020-02-23 12:17:22 -05:00
|
|
|
The routing id must be from 1 to 255 bytes long and MAY NOT start with
|
|
|
|
a zero byte (such routing ids are reserved for internal use by the 0MQ
|
2017-09-07 11:18:50 +02:00
|
|
|
infrastructure).
|
2014-01-19 17:28:13 -08:00
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: binary data
|
|
|
|
Option value unit:: N/A
|
|
|
|
Default value:: NULL
|
|
|
|
Applicable socket types:: ZMQ_ROUTER, ZMQ_STREAM
|
|
|
|
|
|
|
|
|
2014-01-01 16:28:30 +01:00
|
|
|
ZMQ_CONFLATE: Keep only last message
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
If set, a socket shall keep only one message in its inbound/outbound
|
|
|
|
queue, this message being the last message received/the last message
|
2014-01-22 08:40:35 +08:00
|
|
|
to be sent. Ignores 'ZMQ_RCVHWM' and 'ZMQ_SNDHWM' options. Does not
|
2014-01-01 16:28:30 +01:00
|
|
|
support multi-part messages, in particular, only one part of it is kept
|
|
|
|
in the socket internal queue.
|
2010-03-09 18:47:31 +01:00
|
|
|
|
2018-06-26 10:49:36 +01:00
|
|
|
NOTE: If recv is not called on the inbound socket, the queue and memory will
|
|
|
|
grow with each message received. Use linkzmq:zmq_getsockopt[3] with ZMQ_EVENTS
|
|
|
|
to trigger the conflation of the messages.
|
|
|
|
|
2010-06-03 14:15:05 +02:00
|
|
|
[horizontal]
|
2014-01-01 16:28:30 +01:00
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: boolean
|
|
|
|
Default value:: 0 (false)
|
|
|
|
Applicable socket types:: ZMQ_PULL, ZMQ_PUSH, ZMQ_SUB, ZMQ_PUB, ZMQ_DEALER
|
2010-03-09 18:47:31 +01:00
|
|
|
|
|
|
|
|
2015-08-04 22:14:50 +08:00
|
|
|
ZMQ_CONNECT_TIMEOUT: Set connect() timeout
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Sets how long to wait before timing-out a connect() system call.
|
|
|
|
The connect() system call normally takes a long time before it returns a
|
|
|
|
time out error. Setting this option allows the library to time out the call
|
|
|
|
at an earlier interval.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: milliseconds
|
|
|
|
Default value:: 0 (disabled)
|
|
|
|
Applicable socket types:: all, when using TCP transports.
|
|
|
|
|
|
|
|
|
2014-01-01 16:28:30 +01:00
|
|
|
ZMQ_CURVE_PUBLICKEY: Set CURVE public key
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Sets the socket's long term public key. You must set this on CURVE client
|
|
|
|
sockets, see linkzmq:zmq_curve[7]. You can provide the key as 32 binary
|
2014-08-09 10:24:26 +02:00
|
|
|
bytes, or as a 40-character string encoded in the Z85 encoding format and
|
|
|
|
terminated in a null byte. The public key must always be used with the
|
|
|
|
matching secret key. To generate a public/secret key pair, use
|
2016-12-26 14:23:32 +01:00
|
|
|
linkzmq:zmq_curve_keypair[3]. To derive the public key from a secret key,
|
|
|
|
use linkzmq:zmq_curve_public[3].
|
2014-08-09 10:24:26 +02:00
|
|
|
|
|
|
|
NOTE: an option value size of 40 is supported for backwards compatibility,
|
|
|
|
though is deprecated.
|
2010-03-09 18:47:31 +01:00
|
|
|
|
2010-06-03 14:15:05 +02:00
|
|
|
[horizontal]
|
2014-01-01 16:28:30 +01:00
|
|
|
Option value type:: binary data or Z85 text string
|
2014-08-09 10:24:26 +02:00
|
|
|
Option value size:: 32 or 41
|
2014-01-01 16:28:30 +01:00
|
|
|
Default value:: NULL
|
|
|
|
Applicable socket types:: all, when using TCP transport
|
|
|
|
|
|
|
|
|
|
|
|
ZMQ_CURVE_SECRETKEY: Set CURVE secret key
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Sets the socket's long term secret key. You must set this on both CURVE
|
|
|
|
client and server sockets, see linkzmq:zmq_curve[7]. You can provide the
|
|
|
|
key as 32 binary bytes, or as a 40-character string encoded in the Z85
|
2014-08-09 10:24:26 +02:00
|
|
|
encoding format and terminated in a null byte. To generate a public/secret
|
2016-12-26 14:23:32 +01:00
|
|
|
key pair, use linkzmq:zmq_curve_keypair[3]. To derive the public key from
|
|
|
|
a secret key, use linkzmq:zmq_curve_public[3].
|
2014-08-09 10:24:26 +02:00
|
|
|
|
|
|
|
NOTE: an option value size of 40 is supported for backwards compatibility,
|
|
|
|
though is deprecated.
|
2014-01-01 16:28:30 +01:00
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: binary data or Z85 text string
|
2014-08-09 10:24:26 +02:00
|
|
|
Option value size:: 32 or 41
|
2014-01-01 16:28:30 +01:00
|
|
|
Default value:: NULL
|
|
|
|
Applicable socket types:: all, when using TCP transport
|
|
|
|
|
|
|
|
|
|
|
|
ZMQ_CURVE_SERVER: Set CURVE server role
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Defines whether the socket will act as server for CURVE security, see
|
|
|
|
linkzmq:zmq_curve[7]. A value of '1' means the socket will act as
|
|
|
|
CURVE server. A value of '0' means the socket will not act as CURVE
|
|
|
|
server, and its security role then depends on other option settings.
|
|
|
|
Setting this to '0' shall reset the socket security to NULL. When you
|
|
|
|
set this you must also set the server's secret key using the
|
|
|
|
ZMQ_CURVE_SECRETKEY option. A server socket does not need to know
|
|
|
|
its own public key.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: 0, 1
|
|
|
|
Default value:: 0
|
|
|
|
Applicable socket types:: all, when using TCP transport
|
|
|
|
|
|
|
|
|
|
|
|
ZMQ_CURVE_SERVERKEY: Set CURVE server key
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Sets the socket's long term server key. You must set this on CURVE client
|
|
|
|
sockets, see linkzmq:zmq_curve[7]. You can provide the key as 32 binary
|
2014-08-09 10:24:26 +02:00
|
|
|
bytes, or as a 40-character string encoded in the Z85 encoding format and
|
|
|
|
terminated in a null byte. This key must have been generated together with
|
|
|
|
the server's secret key. To generate a public/secret key pair, use
|
|
|
|
linkzmq:zmq_curve_keypair[3].
|
|
|
|
|
|
|
|
NOTE: an option value size of 40 is supported for backwards compatibility,
|
|
|
|
though is deprecated.
|
2014-01-01 16:28:30 +01:00
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: binary data or Z85 text string
|
2014-08-09 10:24:26 +02:00
|
|
|
Option value size:: 32 or 41
|
2014-01-01 16:28:30 +01:00
|
|
|
Default value:: NULL
|
|
|
|
Applicable socket types:: all, when using TCP transport
|
2010-03-09 18:47:31 +01:00
|
|
|
|
2020-04-17 13:20:57 +03:00
|
|
|
ZMQ_DISCONNECT_MSG: set a disconnect message that the socket will generate when accepted peer disconnect
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
When set, the socket will generate a disconnect message when accepted peer has been disconnected.
|
|
|
|
You may set this on ROUTER, SERVER and PEER sockets.
|
|
|
|
The combination with ZMQ_HEARTBEAT_IVL is powerful and simplify protocols, when heartbeat recognize a connection drop it
|
|
|
|
will generate a disconnect message that can match the protocol of the application.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: binary data
|
|
|
|
Option value unit:: N/A
|
|
|
|
Default value:: NULL
|
|
|
|
Applicable socket types:: ZMQ_ROUTER, ZMQ_SERVER and ZMQ_PEER
|
2010-03-09 18:47:31 +01:00
|
|
|
|
2021-06-06 14:28:29 +03:00
|
|
|
|
|
|
|
ZMQ_HICCUP_MSG: set a hiccup message that the socket will generate when connected peer temporarly 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.
|
|
|
|
The combination with ZMQ_HEARTBEAT_IVL is powerful and simplify protocols, when heartbeat recognize a connection drop it
|
|
|
|
will generate a hiccup message that can match the protocol of the application.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: binary data
|
|
|
|
Option value unit:: N/A
|
|
|
|
Default value:: NULL
|
|
|
|
Applicable socket types:: ZMQ_DEALER, ZMQ_CLIENT and ZMQ_PEER
|
|
|
|
|
|
|
|
|
2014-06-19 23:57:48 -04:00
|
|
|
ZMQ_GSSAPI_PLAINTEXT: Disable GSSAPI encryption
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
2017-01-03 12:45:21 +01:00
|
|
|
Defines whether communications on the socket will be encrypted, see
|
2014-06-19 23:57:48 -04:00
|
|
|
linkzmq:zmq_gssapi[7]. A value of '1' means that communications will be
|
|
|
|
plaintext. A value of '0' means communications will be encrypted.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: 0, 1
|
|
|
|
Default value:: 0 (false)
|
|
|
|
Applicable socket types:: all, when using TCP transport
|
|
|
|
|
|
|
|
|
|
|
|
ZMQ_GSSAPI_PRINCIPAL: Set name of GSSAPI principal
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
2014-11-07 22:30:15 -08:00
|
|
|
Sets the name of the principal for whom GSSAPI credentials should be acquired.
|
2014-06-19 23:57:48 -04:00
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: character string
|
|
|
|
Option value unit:: N/A
|
|
|
|
Default value:: not set
|
|
|
|
Applicable socket types:: all, when using TCP transport
|
|
|
|
|
|
|
|
|
|
|
|
ZMQ_GSSAPI_SERVER: Set GSSAPI server role
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Defines whether the socket will act as server for GSSAPI security, see
|
|
|
|
linkzmq:zmq_gssapi[7]. A value of '1' means the socket will act as GSSAPI
|
|
|
|
server. A value of '0' means the socket will act as GSSAPI client.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: 0, 1
|
|
|
|
Default value:: 0 (false)
|
|
|
|
Applicable socket types:: all, when using TCP transport
|
|
|
|
|
|
|
|
|
|
|
|
ZMQ_GSSAPI_SERVICE_PRINCIPAL: Set name of GSSAPI service principal
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
2014-11-07 22:30:15 -08:00
|
|
|
Sets the name of the principal of the GSSAPI server to which a GSSAPI client
|
2014-06-19 23:57:48 -04:00
|
|
|
intends to connect.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: character string
|
|
|
|
Option value unit:: N/A
|
|
|
|
Default value:: not set
|
|
|
|
Applicable socket types:: all, when using TCP transport
|
|
|
|
|
2017-04-24 16:11:02 -07:00
|
|
|
ZMQ_GSSAPI_SERVICE_PRINCIPAL_NAMETYPE: Set name type of service principal
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Sets the name type of the GSSAPI service principal. A value of
|
|
|
|
'ZMQ_GSSAPI_NT_HOSTBASED' (0) means the name specified with
|
|
|
|
'ZMQ_GSSAPI_SERVICE_PRINCIPAL' is interpreted as a host based name. A value
|
|
|
|
of 'ZMQ_GSSAPI_NT_USER_NAME' (1) means it is interpreted as a local user name.
|
|
|
|
A value of 'ZMQ_GSSAPI_NT_KRB5_PRINCIPAL' (2) means it is interpreted as an
|
|
|
|
unparsed principal name string (valid only with the krb5 GSSAPI mechanism).
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: 0, 1, 2
|
|
|
|
Default value:: 0 (ZMQ_GSSAPI_NT_HOSTBASED)
|
|
|
|
Applicable socket types:: all, when using TCP or IPC transport
|
|
|
|
|
|
|
|
ZMQ_GSSAPI_PRINCIPAL_NAMETYPE: Set name type of principal
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Sets the name type of the GSSAPI principal. A value of
|
|
|
|
'ZMQ_GSSAPI_NT_HOSTBASED' (0) means the name specified with
|
|
|
|
'ZMQ_GSSAPI_PRINCIPAL' is interpreted as a host based name. A value of
|
|
|
|
'ZMQ_GSSAPI_NT_USER_NAME' (1) means it is interpreted as a local user name.
|
|
|
|
A value of 'ZMQ_GSSAPI_NT_KRB5_PRINCIPAL' (2) means it is interpreted as an
|
|
|
|
unparsed principal name string (valid only with the krb5 GSSAPI mechanism).
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: 0, 1, 2
|
|
|
|
Default value:: 0 (ZMQ_GSSAPI_NT_HOSTBASED)
|
|
|
|
Applicable socket types:: all, when using TCP or IPC transport
|
2014-06-19 23:57:48 -04:00
|
|
|
|
2014-05-09 13:54:24 +00:00
|
|
|
ZMQ_HANDSHAKE_IVL: Set maximum handshake interval
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The 'ZMQ_HANDSHAKE_IVL' option shall set the maximum handshake interval for
|
|
|
|
the specified 'socket'. Handshaking is the exchange of socket configuration
|
2017-09-07 11:09:18 +02:00
|
|
|
information (socket type, routing id, security) that occurs when a connection
|
2014-05-09 13:54:24 +00:00
|
|
|
is first opened, only for connection-oriented transports. If handshaking does
|
|
|
|
not complete within the configured time, the connection shall be closed.
|
|
|
|
The value 0 means no handshake time limit.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: milliseconds
|
|
|
|
Default value:: 30000
|
|
|
|
Applicable socket types:: all but ZMQ_STREAM, only for connection-oriented transports
|
|
|
|
|
2020-04-17 09:50:59 +03:00
|
|
|
ZMQ_HELLO_MSG: set an hello message that will be sent when a new peer connect
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
When set, the socket will automatically send an hello message when a new connection is made or accepted.
|
|
|
|
You may set this on DEALER, ROUTER, CLIENT, SERVER and PEER sockets.
|
|
|
|
The combination with ZMQ_HEARTBEAT_IVL is powerful and simplify protocols,
|
|
|
|
as now heartbeat and sending the hello message can be left out of protocols and be handled by zeromq.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: binary data
|
|
|
|
Option value unit:: N/A
|
|
|
|
Default value:: NULL
|
|
|
|
Applicable socket types:: ZMQ_ROUTER, ZMQ_DEALER, ZMQ_CLIENT, ZMQ_SERVER and ZMQ_PEER
|
2015-07-19 12:20:45 +01:00
|
|
|
|
2015-06-24 15:02:53 -04:00
|
|
|
ZMQ_HEARTBEAT_IVL: Set interval between sending ZMTP heartbeats
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The 'ZMQ_HEARTBEAT_IVL' option shall set the interval between sending ZMTP heartbeats
|
|
|
|
for the specified 'socket'. If this option is set and is greater than 0, then a 'PING'
|
|
|
|
ZMTP command will be sent every 'ZMQ_HEARTBEAT_IVL' milliseconds.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: milliseconds
|
|
|
|
Default value:: 0
|
|
|
|
Applicable socket types:: all, when using connection-oriented transports
|
|
|
|
|
2015-07-19 12:20:45 +01:00
|
|
|
|
2015-06-24 15:02:53 -04:00
|
|
|
ZMQ_HEARTBEAT_TIMEOUT: Set timeout for ZMTP heartbeats
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The 'ZMQ_HEARTBEAT_TIMEOUT' option shall set how long to wait before timing-out a
|
|
|
|
connection after sending a 'PING' ZMTP command and not receiving any traffic. This
|
|
|
|
option is only valid if 'ZMQ_HEARTBEAT_IVL' is also set, and is greater than 0. The
|
|
|
|
connection will time out if there is no traffic received after sending the 'PING'
|
|
|
|
command, but the received traffic does not have to be a 'PONG' command - any received
|
|
|
|
traffic will cancel the timeout.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: milliseconds
|
2018-04-28 11:47:18 +01:00
|
|
|
Default value:: 0 normally, ZMQ_HEARTBEAT_IVL if it is set
|
2015-06-24 15:02:53 -04:00
|
|
|
Applicable socket types:: all, when using connection-oriented transports
|
|
|
|
|
2015-07-19 12:20:45 +01:00
|
|
|
|
2015-06-24 15:02:53 -04:00
|
|
|
ZMQ_HEARTBEAT_TTL: Set the TTL value for ZMTP heartbeats
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The 'ZMQ_HEARTBEAT_TTL' option shall set the timeout on the remote peer for ZMTP
|
|
|
|
heartbeats. If this option is greater than 0, the remote side shall time out the
|
|
|
|
connection if it does not receive any more traffic within the TTL period. This option
|
2015-06-26 14:08:08 -04:00
|
|
|
does not have any effect if 'ZMQ_HEARTBEAT_IVL' is not set or is 0. Internally, this
|
|
|
|
value is rounded down to the nearest decisecond, any value less than 100 will have
|
|
|
|
no effect.
|
2015-06-24 15:02:53 -04:00
|
|
|
|
|
|
|
[horizontal]
|
2015-06-26 14:08:08 -04:00
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: milliseconds
|
2015-06-24 15:02:53 -04:00
|
|
|
Default value:: 0
|
2018-05-25 10:50:47 +02:00
|
|
|
Maximum value:: 6553599 (which is 2^16-1 deciseconds)
|
2015-06-24 15:02:53 -04:00
|
|
|
Applicable socket types:: all, when using connection-oriented transports
|
2014-05-09 13:54:24 +00:00
|
|
|
|
2015-07-19 12:20:45 +01:00
|
|
|
|
2011-11-02 14:33:58 +01:00
|
|
|
ZMQ_IDENTITY: Set socket identity
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
2020-02-23 12:17:22 -05:00
|
|
|
This option name is now deprecated. Use ZMQ_ROUTING_ID instead.
|
|
|
|
ZMQ_IDENTITY remains as an alias for now.
|
2011-11-02 14:33:58 +01:00
|
|
|
|
|
|
|
|
2014-01-01 16:28:30 +01:00
|
|
|
ZMQ_IMMEDIATE: Queue messages only to completed connections
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
By default queues will fill on outgoing connections even if the connection has
|
|
|
|
not completed. This can lead to "lost" messages on sockets with round-robin
|
|
|
|
routing (REQ, PUSH, DEALER). If this option is set to `1`, messages shall be
|
|
|
|
queued only to completed connections. This will cause the socket to block if
|
|
|
|
there are no other connections, but will prevent queues from filling on pipes
|
|
|
|
awaiting connection.
|
2010-03-09 18:47:31 +01:00
|
|
|
|
2010-06-03 14:15:05 +02:00
|
|
|
[horizontal]
|
2011-03-24 15:18:20 +01:00
|
|
|
Option value type:: int
|
2014-01-01 16:28:30 +01:00
|
|
|
Option value unit:: boolean
|
|
|
|
Default value:: 0 (false)
|
|
|
|
Applicable socket types:: all, only for connection-oriented transports.
|
2010-03-09 18:47:31 +01:00
|
|
|
|
|
|
|
|
2015-07-31 22:37:36 -07:00
|
|
|
ZMQ_INVERT_MATCHING: Invert message filtering
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Reverses the filtering behavior of PUB-SUB sockets, when set to 1.
|
|
|
|
|
|
|
|
On 'PUB' and 'XPUB' sockets, this causes messages to be sent to all
|
|
|
|
connected sockets 'except' those subscribed to a prefix that matches
|
|
|
|
the message. On 'SUB' sockets, this causes only incoming messages that
|
|
|
|
do 'not' match any of the socket's subscriptions to be received by the user.
|
|
|
|
|
|
|
|
Whenever 'ZMQ_INVERT_MATCHING' is set to 1 on a 'PUB' socket, all 'SUB'
|
|
|
|
sockets connecting to it must also have the option set to 1. Failure to
|
|
|
|
do so will have the 'SUB' sockets reject everything the 'PUB' socket sends
|
|
|
|
them. 'XSUB' sockets do not need to do this because they do not filter
|
|
|
|
incoming messages.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: 0,1
|
|
|
|
Default value:: 0
|
|
|
|
Applicable socket types:: ZMQ_PUB, ZMQ_XPUB, ZMQ_SUB
|
|
|
|
|
|
|
|
|
2014-01-01 16:28:30 +01:00
|
|
|
ZMQ_IPV6: Enable IPv6 on socket
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Set the IPv6 option for the socket. A value of `1` means IPv6 is
|
|
|
|
enabled on the socket, while `0` means the socket will use only IPv4.
|
|
|
|
When IPv6 is enabled the socket will connect to, or accept connections
|
|
|
|
from, both IPv4 and IPv6 hosts.
|
2010-03-09 18:47:31 +01:00
|
|
|
|
2010-06-03 14:15:05 +02:00
|
|
|
[horizontal]
|
2011-03-24 14:48:50 +01:00
|
|
|
Option value type:: int
|
2014-01-01 16:28:30 +01:00
|
|
|
Option value unit:: boolean
|
|
|
|
Default value:: 0 (false)
|
|
|
|
Applicable socket types:: all, when using TCP transports.
|
2009-12-10 09:47:24 +01:00
|
|
|
|
2010-02-10 16:18:46 +01:00
|
|
|
|
2010-10-16 10:53:29 +02:00
|
|
|
ZMQ_LINGER: Set linger period for socket shutdown
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
2010-12-01 10:57:37 +01:00
|
|
|
The 'ZMQ_LINGER' option shall set the linger period for the specified 'socket'.
|
|
|
|
The linger period determines how long pending messages which have yet to be
|
2013-12-04 15:02:49 -06:00
|
|
|
sent to a peer shall linger in memory after a socket is disconnected with
|
|
|
|
linkzmq:zmq_disconnect[3] or closed with linkzmq:zmq_close[3], and further
|
2016-02-01 23:00:06 +01:00
|
|
|
affects the termination of the socket's context with linkzmq:zmq_ctx_term[3].
|
|
|
|
The following outlines the different behaviours:
|
2010-12-01 10:57:37 +01:00
|
|
|
|
2014-11-06 15:30:04 +01:00
|
|
|
* A value of '-1' specifies an infinite linger period. Pending
|
2013-12-04 15:02:49 -06:00
|
|
|
messages shall not be discarded after a call to _zmq_disconnect()_ or
|
2016-02-01 23:00:06 +01:00
|
|
|
_zmq_close()_; attempting to terminate the socket's context with _zmq_ctx_term()_
|
2013-12-04 15:02:49 -06:00
|
|
|
shall block until all pending messages have been sent to a peer.
|
2010-12-01 10:57:37 +01:00
|
|
|
|
|
|
|
* The value of '0' specifies no linger period. Pending messages shall be
|
2013-12-04 15:02:49 -06:00
|
|
|
discarded immediately after a call to _zmq_disconnect()_ or _zmq_close()_.
|
2010-12-01 10:57:37 +01:00
|
|
|
|
|
|
|
* Positive values specify an upper bound for the linger period in milliseconds.
|
2013-12-04 15:02:49 -06:00
|
|
|
Pending messages shall not be discarded after a call to _zmq_disconnect()_ or
|
2016-02-01 23:00:06 +01:00
|
|
|
_zmq_close()_; attempting to terminate the socket's context with _zmq_ctx_term()_
|
2013-12-04 15:02:49 -06:00
|
|
|
shall block until either all pending messages have been sent to a peer, or the
|
|
|
|
linger period expires, after which any pending messages shall be discarded.
|
2010-10-16 10:53:29 +02:00
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: milliseconds
|
2017-11-23 14:15:09 -02:00
|
|
|
Default value:: -1 (infinite)
|
2010-10-16 10:53:29 +02:00
|
|
|
Applicable socket types:: all
|
|
|
|
|
|
|
|
|
2014-01-01 16:28:30 +01:00
|
|
|
ZMQ_MAXMSGSIZE: Maximum acceptable inbound message size
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Limits the size of the inbound message. If a peer sends a message larger than
|
|
|
|
ZMQ_MAXMSGSIZE it is disconnected. Value of -1 means 'no limit'.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int64_t
|
|
|
|
Option value unit:: bytes
|
|
|
|
Default value:: -1
|
|
|
|
Applicable socket types:: all
|
2010-12-01 10:57:37 +01:00
|
|
|
|
2014-01-01 16:28:30 +01:00
|
|
|
|
2018-03-15 17:24:32 +01:00
|
|
|
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_
|
|
|
|
followed by the metadata value, for example "X-key:value".
|
|
|
|
_Property_ names are restrited 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]).
|
|
|
|
|
|
|
|
NOTE: in DRAFT state, not yet available in stable releases.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: character string
|
|
|
|
Option value unit:: N/A
|
|
|
|
Default value:: not set
|
|
|
|
Applicable socket types:: all
|
|
|
|
|
|
|
|
|
2014-01-01 16:28:30 +01:00
|
|
|
ZMQ_MULTICAST_HOPS: Maximum network hops for multicast packets
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Sets the time-to-live field in every multicast packet sent from this socket.
|
|
|
|
The default is 1 which means that the multicast packets don't leave the local
|
|
|
|
network.
|
2010-10-17 09:54:12 +02:00
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
2014-01-01 16:28:30 +01:00
|
|
|
Option value unit:: network hops
|
|
|
|
Default value:: 1
|
|
|
|
Applicable socket types:: all, when using multicast transports
|
2010-10-17 09:54:12 +02:00
|
|
|
|
|
|
|
|
2015-11-23 19:35:02 +00:00
|
|
|
ZMQ_MULTICAST_MAXTPDU: Maximum transport data unit size for multicast packets
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Sets the maximum transport data unit size used for outbound multicast
|
|
|
|
packets.
|
|
|
|
|
|
|
|
This must be set at or below the minimum Maximum Transmission Unit (MTU) for
|
|
|
|
all network paths over which multicast reception is required.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: bytes
|
|
|
|
Default value:: 1500
|
|
|
|
Applicable socket types:: all, when using multicast transports
|
|
|
|
|
|
|
|
|
2014-01-01 16:28:30 +01:00
|
|
|
ZMQ_PLAIN_PASSWORD: Set PLAIN security password
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Sets the password for outgoing connections over TCP or IPC. If you set this
|
|
|
|
to a non-null value, the security mechanism used for connections shall be
|
|
|
|
PLAIN, see linkzmq:zmq_plain[7]. If you set this to a null value, the security
|
|
|
|
mechanism used for connections shall be NULL, see linkzmq:zmq_null[3].
|
2011-01-26 07:01:06 +01:00
|
|
|
|
2014-01-01 16:28:30 +01:00
|
|
|
[horizontal]
|
|
|
|
Option value type:: character string
|
|
|
|
Option value unit:: N/A
|
|
|
|
Default value:: not set
|
|
|
|
Applicable socket types:: all, when using TCP transport
|
|
|
|
|
|
|
|
|
|
|
|
ZMQ_PLAIN_SERVER: Set PLAIN server role
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Defines whether the socket will act as server for PLAIN security, see
|
|
|
|
linkzmq:zmq_plain[7]. A value of '1' means the socket will act as
|
|
|
|
PLAIN server. A value of '0' means the socket will not act as PLAIN
|
|
|
|
server, and its security role then depends on other option settings.
|
|
|
|
Setting this to '0' shall reset the socket security to NULL.
|
2011-01-26 07:01:06 +01:00
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
2014-01-01 16:28:30 +01:00
|
|
|
Option value unit:: 0, 1
|
|
|
|
Default value:: 0
|
|
|
|
Applicable socket types:: all, when using TCP transport
|
2011-01-26 07:01:06 +01:00
|
|
|
|
|
|
|
|
2014-01-01 16:28:30 +01:00
|
|
|
ZMQ_PLAIN_USERNAME: Set PLAIN security username
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Sets the username for outgoing connections over TCP or IPC. If you set this
|
|
|
|
to a non-null value, the security mechanism used for connections shall be
|
|
|
|
PLAIN, see linkzmq:zmq_plain[7]. If you set this to a null value, the security
|
|
|
|
mechanism used for connections shall be NULL, see linkzmq:zmq_null[3].
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: character string
|
|
|
|
Option value unit:: N/A
|
|
|
|
Default value:: not set
|
|
|
|
Applicable socket types:: all, when using TCP transport
|
|
|
|
|
|
|
|
|
2016-02-09 09:36:14 +00:00
|
|
|
ZMQ_USE_FD: Set the pre-allocated socket file descriptor
|
2016-05-01 20:32:22 +01:00
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
2016-02-01 12:00:45 +00:00
|
|
|
When set to a positive integer value before zmq_bind is called on the socket,
|
|
|
|
the socket shall use the corresponding file descriptor for connections over
|
|
|
|
TCP or IPC instead of allocating a new file descriptor.
|
|
|
|
Useful for writing systemd socket activated services. If set to -1 (default),
|
|
|
|
a new file descriptor will be allocated instead (default behaviour).
|
|
|
|
|
|
|
|
NOTE: if set after calling zmq_bind, this option shall have no effect.
|
|
|
|
NOTE: the file descriptor passed through MUST have been ran through the "bind"
|
|
|
|
and "listen" system calls beforehand. Also, socket option that would
|
|
|
|
normally be passed through zmq_setsockopt like TCP buffers length,
|
|
|
|
IP_TOS or SO_REUSEADDR MUST be set beforehand by the caller, as they
|
|
|
|
must be set before the socket is bound.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: file descriptor
|
|
|
|
Default value:: -1
|
|
|
|
Applicable socket types:: all bound sockets, when using IPC or TCP transport
|
|
|
|
|
|
|
|
|
2021-01-06 16:22:41 -06:00
|
|
|
ZMQ_PRIORITY: Set the Priority on socket
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Sets the protocol-defined priority for all packets to be sent on this
|
|
|
|
socket, where supported by the OS. In Linux, values greater than 6
|
|
|
|
require admin capability (CAP_NET_ADMIN)
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: >0
|
|
|
|
Default value:: 0
|
|
|
|
Applicable socket types:: all, only for connection-oriented transports
|
|
|
|
|
|
|
|
|
2014-01-01 16:28:30 +01:00
|
|
|
ZMQ_PROBE_ROUTER: bootstrap connections to ROUTER sockets
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
When set to 1, the socket will automatically send an empty message when a
|
|
|
|
new connection is made or accepted. You may set this on REQ, DEALER, or
|
|
|
|
ROUTER sockets connected to a ROUTER socket. The application must filter
|
|
|
|
such empty messages. The ZMQ_PROBE_ROUTER option in effect provides the
|
|
|
|
ROUTER application with an event signaling the arrival of a new peer.
|
|
|
|
|
|
|
|
NOTE: do not set this option on a socket that talks to any other socket
|
|
|
|
types: the results are undefined.
|
2010-10-17 10:23:58 +02:00
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
2014-01-01 16:28:30 +01:00
|
|
|
Option value unit:: 0, 1
|
|
|
|
Default value:: 0
|
|
|
|
Applicable socket types:: ZMQ_ROUTER, ZMQ_DEALER, ZMQ_REQ
|
2010-10-17 10:23:58 +02:00
|
|
|
|
2011-06-12 15:24:08 +02:00
|
|
|
|
2014-01-01 16:28:30 +01:00
|
|
|
ZMQ_RATE: Set multicast data rate
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The 'ZMQ_RATE' option shall set the maximum send or receive data rate for
|
|
|
|
multicast transports such as linkzmq:zmq_pgm[7] using the specified 'socket'.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: kilobits per second
|
|
|
|
Default value:: 100
|
|
|
|
Applicable socket types:: all, when using multicast transports
|
2011-03-02 09:00:36 +01:00
|
|
|
|
2014-01-01 16:28:30 +01:00
|
|
|
|
|
|
|
ZMQ_RCVBUF: Set kernel receive buffer size
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The 'ZMQ_RCVBUF' option shall set the underlying kernel receive buffer size for
|
2015-07-08 11:58:42 +03:00
|
|
|
the 'socket' to the specified size in bytes. A value of -1 means leave the
|
2014-01-01 16:28:30 +01:00
|
|
|
OS default unchanged. For details refer to your operating system documentation
|
|
|
|
for the 'SO_RCVBUF' socket option.
|
2011-03-02 09:00:36 +01:00
|
|
|
|
|
|
|
[horizontal]
|
2014-01-01 16:28:30 +01:00
|
|
|
Option value type:: int
|
2011-03-02 09:00:36 +01:00
|
|
|
Option value unit:: bytes
|
2015-07-08 11:58:42 +03:00
|
|
|
Default value:: -1
|
2011-03-02 09:00:36 +01:00
|
|
|
Applicable socket types:: all
|
|
|
|
|
2011-06-12 15:24:08 +02:00
|
|
|
|
2014-01-01 16:28:30 +01:00
|
|
|
ZMQ_RCVHWM: Set high water mark for inbound messages
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The 'ZMQ_RCVHWM' option shall set the high water mark for inbound messages on
|
|
|
|
the specified 'socket'. The high water mark is a hard limit on the maximum
|
|
|
|
number of outstanding messages 0MQ shall queue in memory for any single peer
|
|
|
|
that the specified 'socket' is communicating with. A value of zero means no
|
|
|
|
limit.
|
2011-05-15 18:25:43 +02:00
|
|
|
|
2014-01-01 16:28:30 +01:00
|
|
|
If this limit has been reached the socket shall enter an exceptional state and
|
|
|
|
depending on the socket type, 0MQ shall take appropriate action such as
|
|
|
|
blocking or dropping sent messages. Refer to the individual socket descriptions
|
|
|
|
in linkzmq:zmq_socket[3] for details on the exact action taken for each socket
|
|
|
|
type.
|
2011-05-15 18:25:43 +02:00
|
|
|
|
2018-09-13 23:14:06 +02:00
|
|
|
NOTE: 0MQ does not guarantee that the socket will be able to queue as many as ZMQ_RCVHWM
|
|
|
|
messages, and the actual limit may be lower or higher, depending on socket transport.
|
|
|
|
A notable example is for sockets using TCP transport; see linkzmq:zmq_tcp[7].
|
|
|
|
|
2011-05-15 18:25:43 +02:00
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
2014-01-01 16:28:30 +01:00
|
|
|
Option value unit:: messages
|
|
|
|
Default value:: 1000
|
|
|
|
Applicable socket types:: all
|
2010-10-17 10:23:58 +02:00
|
|
|
|
2011-06-12 15:24:08 +02:00
|
|
|
|
2011-06-17 12:22:02 +02:00
|
|
|
ZMQ_RCVTIMEO: Maximum time before a recv operation returns with EAGAIN
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Sets the timeout for receive operation on the socket. If the value is `0`,
|
|
|
|
_zmq_recv(3)_ will return immediately, with a EAGAIN error if there is no
|
|
|
|
message to receive. If the value is `-1`, it will block until a message is
|
|
|
|
available. For all other values, it will wait for a message for that amount
|
|
|
|
of time before returning with an EAGAIN error.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: milliseconds
|
|
|
|
Default value:: -1 (infinite)
|
|
|
|
Applicable socket types:: all
|
|
|
|
|
|
|
|
|
2014-01-01 16:28:30 +01:00
|
|
|
ZMQ_RECONNECT_IVL: Set reconnection interval
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The 'ZMQ_RECONNECT_IVL' option shall set the initial reconnection interval for
|
|
|
|
the specified 'socket'. The reconnection interval is the period 0MQ
|
|
|
|
shall wait between attempts to reconnect disconnected peers when using
|
|
|
|
connection-oriented transports. The value -1 means no reconnection.
|
2011-06-17 12:22:02 +02:00
|
|
|
|
2014-01-01 16:28:30 +01:00
|
|
|
NOTE: The reconnection interval may be randomized by 0MQ to prevent
|
|
|
|
reconnection storms in topologies with a large number of peers per socket.
|
2011-06-17 12:22:02 +02:00
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: milliseconds
|
2014-01-01 16:28:30 +01:00
|
|
|
Default value:: 100
|
|
|
|
Applicable socket types:: all, only for connection-oriented transports
|
2011-06-17 12:22:02 +02:00
|
|
|
|
|
|
|
|
2014-01-01 16:28:30 +01:00
|
|
|
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.
|
2011-08-08 12:10:31 +02:00
|
|
|
|
2014-01-01 16:28:30 +01:00
|
|
|
NOTE: Values less than ZMQ_RECONNECT_IVL will be ignored.
|
2013-01-31 20:47:45 +01:00
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
2014-01-01 16:28:30 +01:00
|
|
|
Option value unit:: milliseconds
|
|
|
|
Default value:: 0 (only use ZMQ_RECONNECT_IVL)
|
|
|
|
Applicable socket types:: all, only for connection-oriented transports
|
2013-01-31 20:47:45 +01:00
|
|
|
|
|
|
|
|
2020-02-23 12:17:22 -05:00
|
|
|
ZMQ_RECONNECT_STOP: Set condition where reconnection will stop
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The 'ZMQ_RECONNECT_STOP' option shall set the conditions under which automatic
|
|
|
|
reconnection will stop. This can be useful when a process binds to a
|
|
|
|
wild-card port, where the OS supplies an ephemeral port.
|
|
|
|
|
|
|
|
The 'ZMQ_RECONNECT_STOP_CONN_REFUSED' option will stop reconnection when 0MQ
|
|
|
|
receives the ECONNREFUSED return code from the connect. This indicates that
|
|
|
|
there is no code bound to the specified endpoint.
|
|
|
|
|
2020-06-26 18:41:44 -04:00
|
|
|
The 'ZMQ_RECONNECT_STOP_HANDSHAKE_FAILED' option will stop reconnection if
|
|
|
|
the 0MQ handshake fails. This can be used to detect and/or prevent errant
|
|
|
|
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.
|
|
|
|
|
2020-09-28 16:59:57 +08:00
|
|
|
The 'ZMQ_RECONNECT_STOP_AFTER_DISCONNECT' option will stop reconnection when
|
2021-01-16 15:41:58 +00:00
|
|
|
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.
|
2020-09-28 16:59:57 +08:00
|
|
|
|
2020-06-26 18:41:44 -04:00
|
|
|
NOTE: in DRAFT state, not yet available in stable releases.
|
|
|
|
|
2020-02-23 12:17:22 -05:00
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
2020-06-26 18:41:44 -04:00
|
|
|
Option value unit:: 0, ZMQ_RECONNECT_STOP_CONN_REFUSED, ZMQ_RECONNECT_STOP_HANDSHAKE_FAILED, ZMQ_RECONNECT_STOP_CONN_REFUSED | ZMQ_RECONNECT_STOP_HANDSHAKE_FAILED
|
2020-02-23 12:17:22 -05:00
|
|
|
Default value:: 0
|
2020-06-26 18:41:44 -04:00
|
|
|
Applicable socket types:: all, only for connection-oriented transports (ZMQ_HANDSHAKE_IVL is
|
|
|
|
not applicable for ZMQ_STREAM sockets)
|
2020-02-23 12:17:22 -05:00
|
|
|
|
|
|
|
|
2014-01-01 16:28:30 +01:00
|
|
|
ZMQ_RECOVERY_IVL: Set multicast recovery interval
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The 'ZMQ_RECOVERY_IVL' option shall set the recovery interval for multicast
|
|
|
|
transports using the specified 'socket'. The recovery interval determines the
|
|
|
|
maximum time in milliseconds that a receiver can be absent from a multicast
|
|
|
|
group before unrecoverable data loss will occur.
|
2013-01-31 20:47:45 +01:00
|
|
|
|
2014-01-01 16:28:30 +01:00
|
|
|
CAUTION: Exercise care when setting large recovery intervals as the data
|
|
|
|
needed for recovery will be held in memory. For example, a 1 minute recovery
|
|
|
|
interval at a data rate of 1Gbps requires a 7GB in-memory buffer.
|
2011-08-08 12:10:31 +02:00
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
2014-01-01 16:28:30 +01:00
|
|
|
Option value unit:: milliseconds
|
|
|
|
Default value:: 10000
|
|
|
|
Applicable socket types:: all, when using multicast transports
|
2011-08-08 12:10:31 +02:00
|
|
|
|
|
|
|
|
2014-01-01 16:28:30 +01:00
|
|
|
ZMQ_REQ_CORRELATE: match replies with requests
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
2014-11-07 22:24:07 -08:00
|
|
|
The default behaviour of REQ sockets is to rely on the ordering of messages to
|
2014-01-01 16:28:30 +01:00
|
|
|
match requests and responses and that is usually sufficient. When this option
|
|
|
|
is set to 1, the REQ socket will prefix outgoing messages with an extra frame
|
|
|
|
containing a request id. That means the full message is (request id, 0,
|
|
|
|
user frames...). The REQ socket will discard all incoming messages that don't
|
|
|
|
begin with these two frames.
|
2013-11-25 13:31:21 +10:30
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
2014-01-01 16:28:30 +01:00
|
|
|
Option value unit:: 0, 1
|
2013-11-25 13:31:21 +10:30
|
|
|
Default value:: 0
|
2014-01-01 16:28:30 +01:00
|
|
|
Applicable socket types:: ZMQ_REQ
|
2013-11-25 13:31:21 +10:30
|
|
|
|
|
|
|
|
2014-01-01 16:28:30 +01:00
|
|
|
ZMQ_REQ_RELAXED: relax strict alternation between request and reply
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
By default, a REQ socket does not allow initiating a new request with
|
|
|
|
_zmq_send(3)_ until the reply to the previous one has been received.
|
2016-03-20 16:30:44 +01:00
|
|
|
When set to 1, sending another message is allowed and previous replies will
|
|
|
|
be discarded if any. The request-reply state machine is reset and a new
|
|
|
|
request is sent to the next available peer.
|
2012-06-12 15:34:48 +01:00
|
|
|
|
2014-01-01 16:28:30 +01:00
|
|
|
If set to 1, also enable ZMQ_REQ_CORRELATE to ensure correct matching of
|
|
|
|
requests and replies. Otherwise a late reply to an aborted request can be
|
|
|
|
reported as the reply to the superseding request.
|
2012-06-12 15:34:48 +01:00
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
2014-01-01 16:28:30 +01:00
|
|
|
Option value unit:: 0, 1
|
|
|
|
Default value:: 0
|
|
|
|
Applicable socket types:: ZMQ_REQ
|
2012-06-12 15:34:48 +01:00
|
|
|
|
2013-11-06 23:21:28 -05:00
|
|
|
|
2017-09-07 11:09:18 +02:00
|
|
|
ZMQ_ROUTER_HANDOVER: handle duplicate client routing ids on ROUTER sockets
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
If two clients use the same routing id when connecting to a ROUTER, the
|
2014-01-01 15:28:01 +01:00
|
|
|
results shall depend on the ZMQ_ROUTER_HANDOVER option setting. If that
|
|
|
|
is not set (or set to the default of zero), the ROUTER socket shall reject
|
2017-09-07 11:09:18 +02:00
|
|
|
clients trying to connect with an already-used routing id. If that option
|
2014-01-01 15:28:01 +01:00
|
|
|
is set to 1, the ROUTER socket shall hand-over the connection to the new
|
|
|
|
client and disconnect the existing one.
|
2013-11-06 23:21:28 -05:00
|
|
|
|
2013-12-23 13:14:32 +01:00
|
|
|
[horizontal]
|
2013-11-06 23:21:28 -05:00
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: 0, 1
|
|
|
|
Default value:: 0
|
|
|
|
Applicable socket types:: ZMQ_ROUTER
|
|
|
|
|
2012-06-12 15:34:48 +01:00
|
|
|
|
2012-10-08 16:36:35 +09:00
|
|
|
ZMQ_ROUTER_MANDATORY: accept only routable messages on ROUTER sockets
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
2014-11-07 22:24:07 -08:00
|
|
|
Sets the ROUTER socket behaviour when an unroutable message is encountered. A
|
2013-09-09 20:40:34 +02:00
|
|
|
value of `0` is the default and discards the message silently when it cannot be
|
2014-08-07 13:16:12 +02:00
|
|
|
routed or the peers SNDHWM is reached. A value of `1` returns an
|
|
|
|
'EHOSTUNREACH' error code if the message cannot be routed or 'EAGAIN' error
|
|
|
|
code if the SNDHWM is reached and ZMQ_DONTWAIT was used. Without ZMQ_DONTWAIT
|
|
|
|
it will block until the SNDTIMEO is reached or a spot in the send queue opens
|
|
|
|
up.
|
2012-08-26 17:48:52 +01:00
|
|
|
|
2017-07-14 18:34:21 +02:00
|
|
|
When ZMQ_ROUTER_MANDATORY is set to `1`, 'ZMQ_POLLOUT' events will be generated
|
|
|
|
if one or more messages can be sent to at least one of the peers. If
|
|
|
|
ZMQ_ROUTER_MANDATORY is set to `0`, the socket will generate a 'ZMQ_POLLOUT'
|
2018-05-13 18:11:43 +02:00
|
|
|
event on every call to 'zmq_poll' resp. 'zmq_poller_wait_all'.
|
2017-07-14 18:34:21 +02:00
|
|
|
|
2012-03-15 15:06:44 +03:00
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
2012-06-17 02:33:43 +04:00
|
|
|
Option value unit:: 0, 1
|
|
|
|
Default value:: 0
|
2012-03-15 15:06:44 +03:00
|
|
|
Applicable socket types:: ZMQ_ROUTER
|
|
|
|
|
|
|
|
|
2012-11-06 13:18:58 +01:00
|
|
|
ZMQ_ROUTER_RAW: switch ROUTER socket to raw mode
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
2013-06-05 15:25:52 +02:00
|
|
|
Sets the raw mode on the ROUTER, when set to 1. When the ROUTER socket is in
|
2012-11-06 13:18:58 +01:00
|
|
|
raw mode, and when using the tcp:// transport, it will read and write TCP data
|
|
|
|
without 0MQ framing. This lets 0MQ applications talk to non-0MQ applications.
|
2013-12-23 23:06:18 +08:00
|
|
|
When using raw mode, you cannot set explicit identities, and the ZMQ_SNDMORE
|
2012-11-06 13:18:58 +01:00
|
|
|
flag is ignored when sending data messages. In raw mode you can close a specific
|
2017-09-07 11:09:18 +02:00
|
|
|
connection by sending it a zero-length message (following the routing id frame).
|
2012-11-06 13:18:58 +01:00
|
|
|
|
2013-06-27 20:47:34 +02:00
|
|
|
NOTE: This option is deprecated, please use ZMQ_STREAM sockets instead.
|
|
|
|
|
2012-11-06 13:18:58 +01:00
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: 0, 1
|
|
|
|
Default value:: 0
|
|
|
|
Applicable socket types:: ZMQ_ROUTER
|
|
|
|
|
|
|
|
|
2017-09-07 11:09:18 +02:00
|
|
|
ZMQ_ROUTING_ID: Set socket routing id
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The 'ZMQ_ROUTING_ID' option shall set the routing id of the specified 'socket'
|
2020-02-23 12:17:22 -05:00
|
|
|
when connecting to a ROUTER socket.
|
2017-09-07 11:09:18 +02:00
|
|
|
|
|
|
|
A routing id must be at least one byte and at most 255 bytes long. Identities
|
|
|
|
starting with a zero byte are reserved for use by the 0MQ infrastructure.
|
|
|
|
|
|
|
|
If two clients use the same routing id when connecting to a ROUTER, the
|
|
|
|
results shall depend on the ZMQ_ROUTER_HANDOVER option setting. If that
|
|
|
|
is not set (or set to the default of zero), the ROUTER socket shall reject
|
|
|
|
clients trying to connect with an already-used routing id. If that option
|
|
|
|
is set to 1, the ROUTER socket shall hand-over the connection to the new
|
|
|
|
client and disconnect the existing one.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: binary data
|
|
|
|
Option value unit:: N/A
|
|
|
|
Default value:: NULL
|
|
|
|
Applicable socket types:: ZMQ_REQ, ZMQ_REP, ZMQ_ROUTER, ZMQ_DEALER.
|
|
|
|
|
|
|
|
|
2014-01-01 16:28:30 +01:00
|
|
|
ZMQ_SNDBUF: Set kernel transmit buffer size
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The 'ZMQ_SNDBUF' option shall set the underlying kernel transmit buffer size
|
2015-07-08 11:40:23 +03:00
|
|
|
for the 'socket' to the specified size in bytes. A value of -1 means leave
|
2014-01-01 16:28:30 +01:00
|
|
|
the OS default unchanged. For details please refer to your operating system
|
|
|
|
documentation for the 'SO_SNDBUF' socket option.
|
2013-07-21 13:16:47 +02:00
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
2014-01-01 16:28:30 +01:00
|
|
|
Option value unit:: bytes
|
2015-07-08 11:40:23 +03:00
|
|
|
Default value:: -1
|
2014-01-01 16:28:30 +01:00
|
|
|
Applicable socket types:: all
|
2012-04-06 20:04:35 +04:00
|
|
|
|
|
|
|
|
2014-01-01 16:28:30 +01:00
|
|
|
ZMQ_SNDHWM: Set high water mark for outbound messages
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The 'ZMQ_SNDHWM' option shall set the high water mark for outbound messages on
|
|
|
|
the specified 'socket'. The high water mark is a hard limit on the maximum
|
|
|
|
number of outstanding messages 0MQ shall queue in memory for any single peer
|
|
|
|
that the specified 'socket' is communicating with. A value of zero means no
|
|
|
|
limit.
|
2012-04-06 20:04:35 +04:00
|
|
|
|
2014-01-01 16:28:30 +01:00
|
|
|
If this limit has been reached the socket shall enter an exceptional state and
|
|
|
|
depending on the socket type, 0MQ shall take appropriate action such as
|
|
|
|
blocking or dropping sent messages. Refer to the individual socket descriptions
|
|
|
|
in linkzmq:zmq_socket[3] for details on the exact action taken for each socket
|
|
|
|
type.
|
2013-05-15 17:54:03 +02:00
|
|
|
|
2014-01-01 16:28:30 +01:00
|
|
|
NOTE: 0MQ does not guarantee that the socket will accept as many as ZMQ_SNDHWM
|
2017-08-20 11:51:09 +02:00
|
|
|
messages, and the actual limit may be as much as 90% lower depending on the
|
2018-09-13 23:14:06 +02:00
|
|
|
flow of messages on the socket. The socket may even be able to accept more messages
|
|
|
|
than the ZMQ_SNDHWM threshold; a notable example is for sockets using TCP transport;
|
|
|
|
see linkzmq:zmq_tcp[7].
|
2012-04-06 20:04:35 +04:00
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
2014-01-01 16:28:30 +01:00
|
|
|
Option value unit:: messages
|
|
|
|
Default value:: 1000
|
|
|
|
Applicable socket types:: all
|
2012-04-06 20:04:35 +04:00
|
|
|
|
2013-05-15 17:54:03 +02:00
|
|
|
|
2014-01-01 16:28:30 +01:00
|
|
|
ZMQ_SNDTIMEO: Maximum time before a send operation returns with EAGAIN
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Sets the timeout for send operation on the socket. If the value is `0`,
|
|
|
|
_zmq_send(3)_ will return immediately, with a EAGAIN error if the message
|
|
|
|
cannot be sent. If the value is `-1`, it will block until the message is sent.
|
|
|
|
For all other values, it will try to send the message for that amount of time
|
|
|
|
before returning with an EAGAIN error.
|
2012-04-06 20:04:35 +04:00
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
2014-01-01 16:28:30 +01:00
|
|
|
Option value unit:: milliseconds
|
|
|
|
Default value:: -1 (infinite)
|
|
|
|
Applicable socket types:: all
|
2012-04-06 20:04:35 +04:00
|
|
|
|
|
|
|
|
2016-12-26 14:49:45 +01:00
|
|
|
ZMQ_SOCKS_PROXY: Set SOCKS5 proxy address
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Sets the SOCKS5 proxy address that shall be used by the socket for the TCP
|
2019-06-10 15:01:23 +02:00
|
|
|
connection(s). Supported authentication methods are: no authentication
|
|
|
|
or basic authentication when setup with ZMQ_SOCKS_USERNAME. If the endpoints
|
|
|
|
are domain names instead of addresses they shall not be resolved and they
|
|
|
|
shall be forwarded unchanged to the SOCKS proxy service in the client
|
|
|
|
connection request message (address type 0x03 domain name).
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: character string
|
|
|
|
Option value unit:: N/A
|
|
|
|
Default value:: not set
|
|
|
|
Applicable socket types:: all, when using TCP transport
|
|
|
|
|
|
|
|
|
|
|
|
ZMQ_SOCKS_USERNAME: Set SOCKS username and select basic authentication
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Sets the username for authenticated connection to the SOCKS5 proxy.
|
|
|
|
If you set this to a non-null and non-empty value, the authentication
|
|
|
|
method used for the SOCKS5 connection shall be basic authentication.
|
|
|
|
In this case, use ZMQ_SOCKS_PASSWORD option in order to set the password.
|
|
|
|
If you set this to a null value or empty value, the authentication method
|
|
|
|
shall be no authentication, the default.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: character string
|
|
|
|
Option value unit:: N/A
|
|
|
|
Default value:: not set
|
|
|
|
Applicable socket types:: all, when using TCP transport
|
|
|
|
|
|
|
|
|
|
|
|
ZMQ_SOCKS_PASSWORD: Set SOCKS basic authentication password
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Sets the password for authenticating to the SOCKS5 proxy server.
|
|
|
|
This is used only when the SOCKS5 authentication method has been
|
|
|
|
set to basic authentication through the ZMQ_SOCKS_USERNAME option.
|
|
|
|
Setting this to a null value (the default) is equivalent to an
|
|
|
|
empty password string.
|
2016-12-26 14:49:45 +01:00
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: character string
|
|
|
|
Option value unit:: N/A
|
|
|
|
Default value:: not set
|
|
|
|
Applicable socket types:: all, when using TCP transport
|
|
|
|
|
|
|
|
|
2015-07-24 05:12:11 +08:00
|
|
|
ZMQ_STREAM_NOTIFY: send connect and disconnect notifications
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Enables connect and disconnect notifications on a STREAM socket, when set
|
|
|
|
to 1. When notifications are enabled, the socket delivers a zero-length
|
|
|
|
message when a peer connects or disconnects.
|
2015-01-23 15:25:40 +01:00
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: 0, 1
|
2015-07-24 05:20:31 +08:00
|
|
|
Default value:: 1
|
2015-01-23 15:25:40 +01:00
|
|
|
Applicable socket types:: ZMQ_STREAM
|
|
|
|
|
|
|
|
|
2014-01-01 16:28:30 +01:00
|
|
|
ZMQ_SUBSCRIBE: Establish message filter
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The 'ZMQ_SUBSCRIBE' option shall establish a new message filter on a 'ZMQ_SUB'
|
|
|
|
socket. Newly created 'ZMQ_SUB' sockets shall filter out all incoming messages,
|
|
|
|
therefore you should call this option to establish an initial message filter.
|
2013-05-15 17:54:03 +02:00
|
|
|
|
2014-01-01 16:28:30 +01:00
|
|
|
An empty 'option_value' of length zero shall subscribe to all incoming
|
|
|
|
messages. A non-empty 'option_value' shall subscribe to all messages beginning
|
|
|
|
with the specified prefix. Multiple filters may be attached to a single
|
|
|
|
'ZMQ_SUB' socket, in which case a message shall be accepted if it matches at
|
|
|
|
least one filter.
|
2012-04-06 20:04:35 +04:00
|
|
|
|
|
|
|
[horizontal]
|
2014-01-01 16:28:30 +01:00
|
|
|
Option value type:: binary data
|
|
|
|
Option value unit:: N/A
|
|
|
|
Default value:: N/A
|
|
|
|
Applicable socket types:: ZMQ_SUB
|
2012-04-06 20:04:35 +04:00
|
|
|
|
|
|
|
|
2014-01-01 16:28:30 +01:00
|
|
|
ZMQ_TCP_KEEPALIVE: Override SO_KEEPALIVE socket option
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Override 'SO_KEEPALIVE' socket option (where supported by OS).
|
|
|
|
The default value of `-1` means to skip any overrides and leave it to OS default.
|
2013-12-04 14:17:39 -08:00
|
|
|
|
|
|
|
[horizontal]
|
2014-01-01 16:28:30 +01:00
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: -1,0,1
|
|
|
|
Default value:: -1 (leave to OS default)
|
|
|
|
Applicable socket types:: all, when using TCP transports.
|
2013-12-04 14:17:39 -08:00
|
|
|
|
|
|
|
|
2014-01-01 16:28:30 +01:00
|
|
|
ZMQ_TCP_KEEPALIVE_CNT: Override TCP_KEEPCNT socket option
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Override 'TCP_KEEPCNT' socket option (where supported by OS). The default
|
|
|
|
value of `-1` means to skip any overrides and leave it to OS default.
|
2013-12-04 14:17:39 -08:00
|
|
|
|
|
|
|
[horizontal]
|
2014-01-01 16:28:30 +01:00
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: -1,>0
|
|
|
|
Default value:: -1 (leave to OS default)
|
|
|
|
Applicable socket types:: all, when using TCP transports.
|
2013-12-04 14:17:39 -08:00
|
|
|
|
|
|
|
|
2015-08-01 06:29:06 +08:00
|
|
|
ZMQ_TCP_KEEPALIVE_IDLE: Override TCP_KEEPIDLE (or TCP_KEEPALIVE on some OS)
|
2013-12-06 09:58:10 -08:00
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
2015-08-01 06:29:06 +08:00
|
|
|
Override 'TCP_KEEPIDLE' (or 'TCP_KEEPALIVE' on some OS) socket option (where
|
2014-01-01 16:28:30 +01:00
|
|
|
supported by OS). The default value of `-1` means to skip any overrides and
|
|
|
|
leave it to OS default.
|
2013-12-04 14:17:39 -08:00
|
|
|
|
|
|
|
[horizontal]
|
2014-01-01 16:28:30 +01:00
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: -1,>0
|
|
|
|
Default value:: -1 (leave to OS default)
|
|
|
|
Applicable socket types:: all, when using TCP transports.
|
2013-12-04 14:17:39 -08:00
|
|
|
|
|
|
|
|
2014-01-01 16:28:30 +01:00
|
|
|
ZMQ_TCP_KEEPALIVE_INTVL: Override TCP_KEEPINTVL socket option
|
2013-12-06 14:28:44 -08:00
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
2014-01-01 16:28:30 +01:00
|
|
|
Override 'TCP_KEEPINTVL' socket option(where supported by OS). The default
|
|
|
|
value of `-1` means to skip any overrides and leave it to OS default.
|
2013-12-06 14:28:44 -08:00
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
2014-01-01 16:28:30 +01:00
|
|
|
Option value unit:: -1,>0
|
|
|
|
Default value:: -1 (leave to OS default)
|
|
|
|
Applicable socket types:: all, when using TCP transports.
|
2013-12-06 14:28:44 -08:00
|
|
|
|
2013-05-15 17:54:03 +02:00
|
|
|
|
2016-02-09 09:33:29 +01:00
|
|
|
ZMQ_TCP_MAXRT: Set TCP Maximum Retransmit Timeout
|
2016-05-01 20:32:22 +01:00
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
2015-08-06 23:36:27 +08:00
|
|
|
On OSes where it is supported, sets how long before an unacknowledged TCP
|
2016-02-09 09:33:29 +01:00
|
|
|
retransmit times out. The system normally attempts many TCP retransmits
|
|
|
|
following an exponential backoff strategy. This means that after a network
|
|
|
|
outage, it may take a long time before the session can be re-established.
|
|
|
|
Setting this option allows the timeout to happen at a shorter interval.
|
2015-08-06 23:36:27 +08:00
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: milliseconds
|
|
|
|
Default value:: 0 (leave to OS default)
|
|
|
|
Applicable socket types:: all, when using TCP transports.
|
|
|
|
|
|
|
|
|
2014-01-01 16:28:30 +01:00
|
|
|
ZMQ_TOS: Set the Type-of-Service on socket
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Sets the ToS fields (Differentiated services (DS) and Explicit Congestion
|
|
|
|
Notification (ECN) field of the IP header. The ToS field is typically used
|
|
|
|
to specify a packets priority. The availability of this option is dependent
|
2014-11-07 22:30:15 -08:00
|
|
|
on intermediate network equipment that inspect the ToS field and provide a
|
2014-01-01 16:28:30 +01:00
|
|
|
path for low-delay, high-throughput, highly-reliable service, etc.
|
2013-05-15 17:54:03 +02:00
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
2014-01-01 16:28:30 +01:00
|
|
|
Option value unit:: >0
|
2013-05-15 17:54:03 +02:00
|
|
|
Default value:: 0
|
2014-01-01 16:28:30 +01:00
|
|
|
Applicable socket types:: all, only for connection-oriented transports
|
2013-05-15 17:54:03 +02:00
|
|
|
|
|
|
|
|
2014-01-01 16:28:30 +01:00
|
|
|
ZMQ_UNSUBSCRIBE: Remove message filter
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The 'ZMQ_UNSUBSCRIBE' option shall remove an existing message filter on a
|
|
|
|
'ZMQ_SUB' socket. The filter specified must match an existing filter previously
|
|
|
|
established with the 'ZMQ_SUBSCRIBE' option. If the socket has several
|
|
|
|
instances of the same filter attached the 'ZMQ_UNSUBSCRIBE' option shall remove
|
|
|
|
only one instance, leaving the rest in place and functional.
|
2013-05-15 17:54:03 +02:00
|
|
|
|
|
|
|
[horizontal]
|
2014-01-01 16:28:30 +01:00
|
|
|
Option value type:: binary data
|
2013-05-15 17:54:03 +02:00
|
|
|
Option value unit:: N/A
|
2014-01-01 16:28:30 +01:00
|
|
|
Default value:: N/A
|
|
|
|
Applicable socket types:: ZMQ_SUB
|
2013-06-20 18:09:12 +02:00
|
|
|
|
|
|
|
|
2018-02-25 20:29:20 +00:00
|
|
|
ZMQ_XPUB_VERBOSE: pass duplicate subscribe messages on XPUB socket
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Sets the 'XPUB' socket behaviour on new duplicated subscriptions. If enabled,
|
2016-02-09 09:53:41 +01:00
|
|
|
the socket passes all subscribe messages to the caller. If disabled,
|
2018-02-25 20:29:20 +00:00
|
|
|
only the first subscription to each filter will be passed. The default is 0
|
|
|
|
(disabled).
|
2013-06-20 18:09:12 +02:00
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
2015-07-21 23:35:50 +01:00
|
|
|
Option value unit:: 0, 1
|
|
|
|
Default value:: 0
|
|
|
|
Applicable socket types:: ZMQ_XPUB
|
|
|
|
|
|
|
|
|
2018-02-25 20:29:20 +00:00
|
|
|
ZMQ_XPUB_VERBOSER: pass duplicate subscribe and unsubscribe messages on XPUB socket
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Sets the 'XPUB' socket behaviour on new duplicated subscriptions and
|
|
|
|
unsubscriptions. If enabled, the socket passes all subscribe and unsubscribe
|
|
|
|
messages to the caller. If disabled, only the first subscription to each filter and
|
|
|
|
the last unsubscription from each filter will be passed. The default is 0
|
2016-02-09 09:53:41 +01:00
|
|
|
(disabled).
|
2015-07-21 23:35:50 +01:00
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
2013-06-20 18:09:12 +02:00
|
|
|
Option value unit:: 0, 1
|
|
|
|
Default value:: 0
|
2014-01-01 16:28:30 +01:00
|
|
|
Applicable socket types:: ZMQ_XPUB
|
2013-05-15 17:54:03 +02:00
|
|
|
|
2014-11-26 22:47:42 +02:00
|
|
|
|
2015-07-19 12:20:45 +01:00
|
|
|
ZMQ_XPUB_MANUAL: change the subscription handling to manual
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
2014-11-26 22:47:42 +02:00
|
|
|
Sets the 'XPUB' socket subscription handling mode manual/automatic.
|
|
|
|
A value of '0' is the default and subscription requests will be handled automatically.
|
2020-02-23 12:17:22 -05:00
|
|
|
A value of '1' will change the subscription requests handling to manual,
|
2014-11-26 22:47:42 +02:00
|
|
|
with manual mode subscription requests are not added to the subscription list.
|
|
|
|
To add subscription the user need to call setsockopt with ZMQ_SUBSCRIBE on XPUB socket.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: 0, 1
|
|
|
|
Default value:: 0
|
|
|
|
Applicable socket types:: ZMQ_XPUB
|
|
|
|
|
2015-07-19 12:20:45 +01:00
|
|
|
|
2019-05-18 05:12:32 +08:00
|
|
|
ZMQ_XPUB_MANUAL_LAST_VALUE: change the subscription handling to manual
|
2019-05-18 16:14:58 +01:00
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
2019-05-18 05:12:32 +08:00
|
|
|
This option is similar to ZMQ_XPUB_MANUAL.
|
2019-05-18 16:14:58 +01:00
|
|
|
The difference is that ZMQ_XPUB_MANUAL_LAST_VALUE changes the 'XPUB' socket
|
|
|
|
behaviour to send the first message to the last subscriber after the socket
|
|
|
|
receives a subscription and call setsockopt with ZMQ_SUBSCRIBE on 'XPUB' socket.
|
|
|
|
This prevents duplicated messages when using last value caching(LVC).
|
2019-05-18 05:12:32 +08:00
|
|
|
|
|
|
|
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_XPUB
|
|
|
|
|
|
|
|
|
2015-04-14 18:30:27 +02:00
|
|
|
ZMQ_XPUB_NODROP: do not silently drop messages if SENDHWM is reached
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
2015-04-14 18:32:06 +02:00
|
|
|
Sets the 'XPUB' socket behaviour to return error EAGAIN if SENDHWM is
|
2020-02-23 12:17:22 -05:00
|
|
|
reached and the message could not be send.
|
2015-04-14 18:30:27 +02:00
|
|
|
|
|
|
|
A value of `0` is the default and drops the message silently when the peers
|
|
|
|
SNDHWM is reached. A value of `1` returns an 'EAGAIN' error code if the
|
|
|
|
SNDHWM is reached and ZMQ_DONTWAIT was used.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: 0, 1
|
|
|
|
Default value:: 0
|
|
|
|
Applicable socket types:: ZMQ_XPUB, ZMQ_PUB
|
|
|
|
|
2014-11-26 22:47:42 +02:00
|
|
|
|
2015-07-31 22:36:57 -07:00
|
|
|
ZMQ_XPUB_WELCOME_MSG: set welcome message that will be received by subscriber when connecting
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
2014-11-26 22:47:42 +02:00
|
|
|
Sets a welcome message the will be recieved 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.
|
|
|
|
|
2018-12-13 20:32:29 -08:00
|
|
|
Use NULL and length of zero to disable welcome message.
|
2014-11-26 22:47:42 +02:00
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: binary data
|
|
|
|
Option value unit:: N/A
|
|
|
|
Default value:: NULL
|
|
|
|
Applicable socket types:: ZMQ_XPUB
|
2013-05-15 17:54:03 +02:00
|
|
|
|
2015-07-19 12:20:45 +01:00
|
|
|
|
2020-01-23 20:09:08 +01:00
|
|
|
ZMQ_ONLY_FIRST_SUBSCRIBE: Process only first subscribe/unsubscribe in a multipart message
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
2019-11-20 14:18:02 +01:00
|
|
|
If set, only the first part of the multipart message is processed as
|
|
|
|
a subscribe/unsubscribe message. The rest are forwarded as user data
|
|
|
|
regardless of message contents.
|
|
|
|
|
|
|
|
It not set (default), subscribe/unsubscribe messages in a multipart message
|
|
|
|
are processed as such regardless of their number and order.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: boolean
|
|
|
|
Default value:: 0 (false)
|
|
|
|
Applicable socket types:: ZMQ_XSUB, ZMQ_XPUB
|
|
|
|
|
|
|
|
|
2013-09-09 20:40:34 +02:00
|
|
|
ZMQ_ZAP_DOMAIN: Set RFC 27 authentication domain
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
2020-02-23 12:17:22 -05:00
|
|
|
Sets the domain for ZAP (ZMQ RFC 27) authentication. A ZAP domain must be
|
|
|
|
specified to enable authentication. When the ZAP domain is empty, which is
|
2017-10-07 18:34:18 +01:00
|
|
|
the default, ZAP authentication is disabled. This is not compatible with
|
|
|
|
previous versions of libzmq, so it can be controlled by ZMQ_ZAP_ENFORCE_DOMAIN
|
|
|
|
which for now is disabled by default.
|
2017-09-19 09:13:57 +02:00
|
|
|
See http://rfc.zeromq.org/spec:27 for more details.
|
2013-09-09 20:40:34 +02:00
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: character string
|
|
|
|
Option value unit:: N/A
|
2017-09-19 09:13:57 +02:00
|
|
|
Default value:: empty
|
2013-09-09 20:40:34 +02:00
|
|
|
Applicable socket types:: all, when using TCP transport
|
|
|
|
|
|
|
|
|
2017-10-07 18:34:18 +01:00
|
|
|
ZMQ_ZAP_ENFORCE_DOMAIN: Set ZAP domain handling to strictly adhere the RFC
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The ZAP (ZMQ RFC 27) authentication protocol specifies that a domain must
|
|
|
|
always be set. Older versions of libzmq did not follow the spec and allowed
|
|
|
|
an empty domain to be set.
|
|
|
|
This option can be used to enabled or disable the stricter, backward
|
|
|
|
incompatible behaviour. For now it is disabled by default, but in a future
|
|
|
|
version it will be enabled by default.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: 0, 1
|
|
|
|
Default value:: 0
|
|
|
|
Applicable socket types:: all, when using ZAP
|
|
|
|
|
|
|
|
|
2014-10-14 16:29:54 +02:00
|
|
|
ZMQ_TCP_ACCEPT_FILTER: Assign filters to allow new TCP connections
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Assign an arbitrary number of filters that will be applied for each new TCP
|
|
|
|
transport connection on a listening socket. If no filters are applied, then
|
|
|
|
the TCP transport allows connections from any IP address. If at least one
|
|
|
|
filter is applied then new connection source ip should be matched. To clear
|
|
|
|
all filters call zmq_setsockopt(socket, ZMQ_TCP_ACCEPT_FILTER, NULL, 0).
|
|
|
|
Filter is a null-terminated string with ipv6 or ipv4 CIDR.
|
|
|
|
|
|
|
|
NOTE: This option is deprecated, please use authentication via the ZAP API
|
2020-06-08 19:32:45 +01:00
|
|
|
and IP address allowing / blocking.
|
2014-10-14 16:29:54 +02:00
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: binary data
|
|
|
|
Option value unit:: N/A
|
|
|
|
Default value:: no filters (allow from all)
|
|
|
|
Applicable socket types:: all listening sockets, when using TCP transports.
|
|
|
|
|
|
|
|
|
|
|
|
ZMQ_IPC_FILTER_GID: Assign group ID filters to allow new IPC connections
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Assign an arbitrary number of filters that will be applied for each new IPC
|
|
|
|
transport connection on a listening socket. If no IPC filters are applied, then
|
|
|
|
the IPC transport allows connections from any process. If at least one UID,
|
|
|
|
GID, or PID filter is applied then new connection credentials should be
|
|
|
|
matched. To clear all GID filters call zmq_setsockopt(socket,
|
|
|
|
ZMQ_IPC_FILTER_GID, NULL, 0).
|
|
|
|
|
|
|
|
NOTE: GID filters are only available on platforms supporting SO_PEERCRED or
|
|
|
|
LOCAL_PEERCRED socket options (currently only Linux and later versions of
|
|
|
|
OS X).
|
|
|
|
|
|
|
|
NOTE: This option is deprecated, please use authentication via the ZAP API
|
2020-06-08 19:32:45 +01:00
|
|
|
and IPC allowing / blocking.
|
2014-10-14 16:29:54 +02:00
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: gid_t
|
|
|
|
Option value unit:: N/A
|
|
|
|
Default value:: no filters (allow from all)
|
|
|
|
Applicable socket types:: all listening sockets, when using IPC transports.
|
|
|
|
|
|
|
|
|
|
|
|
ZMQ_IPC_FILTER_PID: Assign process ID filters to allow new IPC connections
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Assign an arbitrary number of filters that will be applied for each new IPC
|
|
|
|
transport connection on a listening socket. If no IPC filters are applied, then
|
|
|
|
the IPC transport allows connections from any process. If at least one UID,
|
|
|
|
GID, or PID filter is applied then new connection credentials should be
|
|
|
|
matched. To clear all PID filters call zmq_setsockopt(socket,
|
|
|
|
ZMQ_IPC_FILTER_PID, NULL, 0).
|
|
|
|
|
|
|
|
NOTE: PID filters are only available on platforms supporting the SO_PEERCRED
|
|
|
|
socket option (currently only Linux).
|
|
|
|
|
|
|
|
NOTE: This option is deprecated, please use authentication via the ZAP API
|
2020-06-08 19:32:45 +01:00
|
|
|
and IPC allowing / blocking.
|
2014-10-14 16:29:54 +02:00
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: pid_t
|
|
|
|
Option value unit:: N/A
|
|
|
|
Default value:: no filters (allow from all)
|
|
|
|
Applicable socket types:: all listening sockets, when using IPC transports.
|
|
|
|
|
|
|
|
|
|
|
|
ZMQ_IPC_FILTER_UID: Assign user ID filters to allow new IPC connections
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Assign an arbitrary number of filters that will be applied for each new IPC
|
|
|
|
transport connection on a listening socket. If no IPC filters are applied, then
|
|
|
|
the IPC transport allows connections from any process. If at least one UID,
|
|
|
|
GID, or PID filter is applied then new connection credentials should be
|
|
|
|
matched. To clear all UID filters call zmq_setsockopt(socket,
|
|
|
|
ZMQ_IPC_FILTER_UID, NULL, 0).
|
|
|
|
|
|
|
|
NOTE: UID filters are only available on platforms supporting SO_PEERCRED or
|
|
|
|
LOCAL_PEERCRED socket options (currently only Linux and later versions of
|
|
|
|
OS X).
|
|
|
|
|
|
|
|
NOTE: This option is deprecated, please use authentication via the ZAP API
|
2020-06-08 19:32:45 +01:00
|
|
|
and IPC allowing / blocking.
|
2014-10-14 16:29:54 +02:00
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: uid_t
|
|
|
|
Option value unit:: N/A
|
|
|
|
Default value:: no filters (allow from all)
|
|
|
|
Applicable socket types:: all listening sockets, when using IPC transports.
|
|
|
|
|
|
|
|
|
|
|
|
ZMQ_IPV4ONLY: Use IPv4-only on socket
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Set the IPv4-only option for the socket. This option is deprecated.
|
|
|
|
Please use the ZMQ_IPV6 option.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: boolean
|
|
|
|
Default value:: 1 (true)
|
|
|
|
Applicable socket types:: all, when using TCP transports.
|
|
|
|
|
2015-01-26 15:59:19 +01:00
|
|
|
|
2015-12-07 18:19:45 +06:00
|
|
|
ZMQ_VMCI_BUFFER_SIZE: Set buffer size of the VMCI socket
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The `ZMQ_VMCI_BUFFER_SIZE` option shall set the size of the underlying
|
|
|
|
buffer for the socket. Used during negotiation before the connection is established.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: uint64_t
|
|
|
|
Option value unit:: bytes
|
|
|
|
Default value:: 65546
|
|
|
|
Applicable socket types:: all, when using VMCI transport
|
|
|
|
|
|
|
|
|
|
|
|
ZMQ_VMCI_BUFFER_MIN_SIZE: Set min buffer size of the VMCI socket
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The `ZMQ_VMCI_BUFFER_MIN_SIZE` option shall set the min size of the underlying
|
|
|
|
buffer for the socket. Used during negotiation before the connection is established.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: uint64_t
|
|
|
|
Option value unit:: bytes
|
|
|
|
Default value:: 128
|
|
|
|
Applicable socket types:: all, when using VMCI transport
|
|
|
|
|
|
|
|
|
|
|
|
ZMQ_VMCI_BUFFER_MAX_SIZE: Set max buffer size of the VMCI socket
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The `ZMQ_VMCI_BUFFER_MAX_SIZE` option shall set the max size of the underlying
|
|
|
|
buffer for the socket. Used during negotiation before the connection is established.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: uint64_t
|
|
|
|
Option value unit:: bytes
|
|
|
|
Default value:: 262144
|
|
|
|
Applicable socket types:: all, when using VMCI transport
|
|
|
|
|
|
|
|
|
|
|
|
ZMQ_VMCI_CONNECT_TIMEOUT: Set connection timeout of the VMCI socket
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The `ZMQ_VMCI_CONNECT_TIMEOUT` option shall set connection timeout
|
|
|
|
for the socket.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: milliseconds
|
|
|
|
Default value:: -1
|
|
|
|
Applicable socket types:: all, when using VMCI transport
|
|
|
|
|
|
|
|
|
2018-05-10 16:56:49 +02:00
|
|
|
ZMQ_MULTICAST_LOOP: Control multicast local loopback
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
For multicast UDP sender sockets this option sets whether the data
|
|
|
|
sent should be looped back on local listening sockets.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: 0, 1
|
|
|
|
Default value:: 1
|
|
|
|
Applicable socket types:: ZMQ_RADIO, when using UDP multicast transport
|
|
|
|
|
2018-08-15 09:54:08 +02:00
|
|
|
|
|
|
|
ZMQ_ROUTER_NOTIFY: Send connect and disconnect notifications
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Enable connect and disconnect notifications on a ROUTER socket.
|
|
|
|
When enabled, the socket delivers a zero-length message (with routing-id
|
|
|
|
as first frame) when a peer connects or disconnects. It's possible
|
|
|
|
to notify both events for a peer by OR-ing the flag values. This option
|
|
|
|
only applies to stream oriented (tcp, ipc) transports.
|
|
|
|
|
|
|
|
NOTE: in DRAFT state, not yet available in stable releases.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
2019-04-12 12:17:03 +01:00
|
|
|
Option value unit:: 0, ZMQ_NOTIFY_CONNECT, ZMQ_NOTIFY_DISCONNECT, ZMQ_NOTIFY_CONNECT | ZMQ_NOTIFY_DISCONNECT
|
2018-08-15 09:54:08 +02:00
|
|
|
Default value:: 0
|
|
|
|
Applicable socket types:: ZMQ_ROUTER
|
|
|
|
|
|
|
|
|
2019-06-27 00:34:56 -04:00
|
|
|
ZMQ_IN_BATCH_SIZE: Maximal receive batch size
|
2019-06-27 18:05:22 +01:00
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
2019-06-27 00:34:56 -04:00
|
|
|
Sets the maximal amount of messages that can be received in a single
|
2019-06-27 18:05:22 +01:00
|
|
|
'recv' system call. WARNING: this option should almost never be changed.
|
|
|
|
The default has been chosen to offer the best compromise between latency and
|
|
|
|
throughtput. In the vast majority of cases, changing this option will result in
|
|
|
|
worst result if not outright breakages.
|
2019-06-27 00:34:56 -04:00
|
|
|
|
|
|
|
Cannot be zero.
|
|
|
|
|
|
|
|
NOTE: in DRAFT state, not yet available in stable releases.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: messages
|
|
|
|
Default value:: 8192
|
2019-06-27 18:05:22 +01:00
|
|
|
Applicable socket types:: All, when using TCP, IPC, PGM or NORM transport.
|
2019-06-27 00:34:56 -04:00
|
|
|
|
|
|
|
|
|
|
|
ZMQ_OUT_BATCH_SIZE: Maximal send batch size
|
2019-06-27 18:05:22 +01:00
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
2019-06-27 00:34:56 -04:00
|
|
|
Sets the maximal amount of messages that can be sent in a single
|
2019-06-27 18:05:22 +01:00
|
|
|
'send' system call. WARNING: this option should almost never be changed.
|
|
|
|
The default has been chosen to offer the best compromise between latency and
|
|
|
|
throughtput. In the vast majority of cases, changing this option will result in
|
|
|
|
worst result if not outright breakages.
|
2019-06-27 00:34:56 -04:00
|
|
|
|
|
|
|
Cannot be zero.
|
|
|
|
|
|
|
|
NOTE: in DRAFT state, not yet available in stable releases.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: messages
|
|
|
|
Default value:: 8192
|
2019-06-27 18:05:22 +01:00
|
|
|
Applicable socket types:: All, when using TCP, IPC, PGM or NORM transport.
|
2019-06-27 00:34:56 -04:00
|
|
|
|
|
|
|
|
2010-02-10 16:18:46 +01:00
|
|
|
RETURN VALUE
|
|
|
|
------------
|
2010-03-09 18:47:31 +01:00
|
|
|
The _zmq_setsockopt()_ function shall return zero if successful. Otherwise it
|
2010-03-10 12:19:39 +01:00
|
|
|
shall return `-1` and set 'errno' to one of the values defined below.
|
2010-02-10 16:18:46 +01:00
|
|
|
|
|
|
|
ERRORS
|
|
|
|
------
|
|
|
|
*EINVAL*::
|
2010-03-09 18:47:31 +01:00
|
|
|
The requested option _option_name_ is unknown, or the requested _option_len_ or
|
|
|
|
_option_value_ is invalid.
|
2010-04-12 09:25:04 +02:00
|
|
|
*ETERM*::
|
2010-05-31 12:53:40 +02:00
|
|
|
The 0MQ 'context' associated with the specified 'socket' was terminated.
|
2011-04-09 09:35:34 +02:00
|
|
|
*ENOTSOCK*::
|
|
|
|
The provided 'socket' was invalid.
|
2010-09-08 08:39:27 +02:00
|
|
|
*EINTR*::
|
|
|
|
The operation was interrupted by delivery of a signal.
|
2010-04-12 09:25:04 +02:00
|
|
|
|
2010-02-10 16:18:46 +01:00
|
|
|
|
|
|
|
EXAMPLE
|
|
|
|
-------
|
2010-03-09 18:47:31 +01:00
|
|
|
.Subscribing to messages on a 'ZMQ_SUB' socket
|
2010-02-10 16:18:46 +01:00
|
|
|
----
|
2010-03-09 18:47:31 +01:00
|
|
|
/* Subscribe to all messages */
|
|
|
|
rc = zmq_setsockopt (socket, ZMQ_SUBSCRIBE, "", 0);
|
2009-11-22 16:51:21 +01:00
|
|
|
assert (rc == 0);
|
2010-03-09 18:47:31 +01:00
|
|
|
/* Subscribe to messages prefixed with "ANIMALS.CATS" */
|
|
|
|
rc = zmq_setsockopt (socket, ZMQ_SUBSCRIBE, "ANIMALS.CATS", 12);
|
|
|
|
----
|
|
|
|
|
|
|
|
.Setting I/O thread affinity
|
|
|
|
----
|
2010-04-06 15:23:13 +02:00
|
|
|
int64_t affinity;
|
2010-03-09 18:47:31 +01:00
|
|
|
/* Incoming connections on TCP port 5555 shall be handled by I/O thread 1 */
|
2010-04-06 15:23:13 +02:00
|
|
|
affinity = 1;
|
2013-05-15 14:11:15 +02:00
|
|
|
rc = zmq_setsockopt (socket, ZMQ_AFFINITY, &affinity, sizeof (affinity));
|
2010-03-09 18:47:31 +01:00
|
|
|
assert (rc);
|
|
|
|
rc = zmq_bind (socket, "tcp://lo:5555");
|
|
|
|
assert (rc);
|
|
|
|
/* Incoming connections on TCP port 5556 shall be handled by I/O thread 2 */
|
2010-04-06 15:23:13 +02:00
|
|
|
affinity = 2;
|
2013-05-15 14:11:15 +02:00
|
|
|
rc = zmq_setsockopt (socket, ZMQ_AFFINITY, &affinity, sizeof (affinity));
|
2010-03-09 18:47:31 +01:00
|
|
|
assert (rc);
|
2010-04-16 09:53:09 +02:00
|
|
|
rc = zmq_bind (socket, "tcp://lo:5556");
|
2010-03-09 18:47:31 +01:00
|
|
|
assert (rc);
|
2010-02-10 16:18:46 +01:00
|
|
|
----
|
|
|
|
|
|
|
|
|
|
|
|
SEE ALSO
|
|
|
|
--------
|
2010-05-31 12:53:40 +02:00
|
|
|
linkzmq:zmq_getsockopt[3]
|
2010-02-10 16:18:46 +01:00
|
|
|
linkzmq:zmq_socket[3]
|
2013-05-15 17:54:03 +02:00
|
|
|
linkzmq:zmq_plain[7]
|
|
|
|
linkzmq:zmq_curve[7]
|
2010-02-10 16:18:46 +01:00
|
|
|
linkzmq:zmq[7]
|
|
|
|
|
2009-11-22 16:51:21 +01:00
|
|
|
|
2010-09-04 15:55:11 +02:00
|
|
|
AUTHORS
|
|
|
|
-------
|
2013-04-11 18:53:02 +02:00
|
|
|
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>.
|