2010-05-31 12:53:40 +02:00
|
|
|
zmq_getsockopt(3)
|
|
|
|
=================
|
|
|
|
|
|
|
|
|
|
|
|
NAME
|
|
|
|
----
|
|
|
|
|
|
|
|
zmq_getsockopt - get 0MQ socket options
|
|
|
|
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
--------
|
2010-05-31 17:24:50 +02:00
|
|
|
*int zmq_getsockopt (void '*socket', int 'option_name', void '*option_value', size_t '*option_len');*
|
2010-05-31 12:53:40 +02:00
|
|
|
|
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
-----------
|
|
|
|
The _zmq_getsockopt()_ function shall retrieve the value for the option
|
|
|
|
specified by the 'option_name' argument for the 0MQ socket pointed to by the
|
|
|
|
'socket' argument, and store it in the buffer pointed to by the 'option_value'
|
|
|
|
argument. The 'option_len' argument is the size in bytes of the buffer pointed
|
2010-05-31 17:24:50 +02:00
|
|
|
to by 'option_value'; upon successful completion _zmq_getsockopt()_ shall
|
2010-06-15 08:01:43 +02:00
|
|
|
modify the 'option_len' argument to indicate the actual size of the option
|
2010-05-31 17:24:50 +02:00
|
|
|
value stored in the buffer.
|
2010-05-31 12:53:40 +02:00
|
|
|
|
|
|
|
The following options can be retrieved with the _zmq_getsockopt()_ function:
|
|
|
|
|
|
|
|
|
2010-12-01 10:57:37 +01:00
|
|
|
ZMQ_TYPE: Retrieve socket type
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
2010-10-17 10:26:06 +02:00
|
|
|
The 'ZMQ_TYPE' option shall retrieve the socket type for the specified
|
2010-09-28 15:27:45 +02:00
|
|
|
'socket'. The socket type is specified at socket creation time and
|
|
|
|
cannot be modified afterwards.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: N/A
|
|
|
|
Default value:: N/A
|
|
|
|
Applicable socket types:: all
|
|
|
|
|
|
|
|
|
2010-05-31 14:12:27 +02:00
|
|
|
ZMQ_RCVMORE: More message parts to follow
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The 'ZMQ_RCVMORE' option shall return a boolean value indicating if the
|
|
|
|
multi-part message currently being read from the specified 'socket' has more
|
|
|
|
message parts to follow. If there are no message parts to follow or if the
|
|
|
|
message currently being read is not a multi-part message a value of zero shall
|
|
|
|
be returned. Otherwise, a value of 1 shall be returned.
|
|
|
|
|
|
|
|
Refer to linkzmq:zmq_send[3] and linkzmq:zmq_recv[3] for a detailed description
|
|
|
|
of sending/receiving multi-part messages.
|
|
|
|
|
2010-06-03 14:15:05 +02:00
|
|
|
[horizontal]
|
2011-03-24 14:59:43 +01:00
|
|
|
Option value type:: int
|
2010-05-31 14:12:27 +02:00
|
|
|
Option value unit:: boolean
|
|
|
|
Default value:: N/A
|
|
|
|
Applicable socket types:: all
|
|
|
|
|
|
|
|
|
2011-03-24 16:47:33 +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.
|
2010-06-02 18:36:34 +02: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.
|
2010-05-31 12:53:40 +02:00
|
|
|
|
2011-03-24 16:47:33 +01:00
|
|
|
The default 'ZMQ_SNDHWM' value of zero means "no limit".
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: messages
|
|
|
|
Default value:: 0
|
|
|
|
Applicable socket types:: all
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
The default 'ZMQ_RCVHWM' value of zero means "no limit".
|
2010-05-31 12:53:40 +02:00
|
|
|
|
2010-06-03 14:15:05 +02:00
|
|
|
[horizontal]
|
2011-03-24 15:43:03 +01:00
|
|
|
Option value type:: int
|
2010-05-31 12:53:40 +02:00
|
|
|
Option value unit:: messages
|
|
|
|
Default value:: 0
|
|
|
|
Applicable socket types:: all
|
|
|
|
|
|
|
|
|
|
|
|
ZMQ_AFFINITY: Retrieve I/O thread affinity
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The 'ZMQ_AFFINITY' option shall retrieve the I/O thread affinity for newly
|
|
|
|
created connections on the specified 'socket'.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
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-05-31 12:53:40 +02:00
|
|
|
Option value unit:: N/A (bitmap)
|
|
|
|
Default value:: 0
|
|
|
|
Applicable socket types:: N/A
|
|
|
|
|
|
|
|
|
|
|
|
ZMQ_IDENTITY: Retrieve socket identity
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The 'ZMQ_IDENTITY' option shall retrieve the identity of the specified
|
2010-11-04 21:21:01 +01:00
|
|
|
'socket'. Socket identity determines if existing 0MQ infrastructure (_message
|
2010-05-31 12:53:40 +02:00
|
|
|
queues_, _forwarding devices_) shall be identified with a specific application
|
|
|
|
and persist across multiple runs of the application.
|
|
|
|
|
|
|
|
If the socket has no identity, each run of an application is completely
|
|
|
|
separate from other runs. However, with identity set the socket shall re-use
|
|
|
|
any existing 0MQ infrastructure configured by the previous run(s). Thus the
|
|
|
|
application may receive messages that were sent in the meantime, _message
|
|
|
|
queue_ limits shall be shared with previous run(s) and so on.
|
|
|
|
|
|
|
|
Identity can be at least one byte and at most 255 bytes long. Identities
|
|
|
|
starting with binary zero are reserved for use by 0MQ infrastructure.
|
|
|
|
|
2010-06-03 14:15:05 +02:00
|
|
|
[horizontal]
|
2010-05-31 12:53:40 +02:00
|
|
|
Option value type:: binary data
|
|
|
|
Option value unit:: N/A
|
|
|
|
Default value:: NULL
|
|
|
|
Applicable socket types:: all
|
|
|
|
|
|
|
|
|
|
|
|
ZMQ_RATE: Retrieve multicast data rate
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The 'ZMQ_RATE' option shall retrieve the maximum send or receive data rate for
|
|
|
|
multicast transports using the specified 'socket'.
|
|
|
|
|
2010-06-03 14:15:05 +02:00
|
|
|
[horizontal]
|
2011-03-24 15:18:20 +01:00
|
|
|
Option value type:: int
|
2010-05-31 12:53:40 +02:00
|
|
|
Option value unit:: kilobits per second
|
|
|
|
Default value:: 100
|
|
|
|
Applicable socket types:: all, when using multicast transports
|
|
|
|
|
|
|
|
|
|
|
|
ZMQ_RECOVERY_IVL: Get multicast recovery interval
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The 'ZMQ_RECOVERY_IVL' option shall retrieve the recovery interval for
|
|
|
|
multicast transports using the specified 'socket'. The recovery interval
|
2011-03-24 14:36:40 +01:00
|
|
|
determines the maximum time in milliseconds that a receiver can be absent from a
|
2010-05-31 12:53:40 +02:00
|
|
|
multicast group before unrecoverable data loss will occur.
|
|
|
|
|
2010-12-09 21:42:58 +01:00
|
|
|
[horizontal]
|
2011-03-24 15:18:20 +01:00
|
|
|
Option value type:: int
|
2010-12-09 21:42:58 +01:00
|
|
|
Option value unit:: milliseconds
|
2011-03-24 14:36:40 +01:00
|
|
|
Default value:: 10000
|
2010-12-09 21:42:58 +01:00
|
|
|
Applicable socket types:: all, when using multicast transports
|
|
|
|
|
|
|
|
|
2010-05-31 12:53:40 +02:00
|
|
|
ZMQ_SNDBUF: Retrieve kernel transmit buffer size
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The 'ZMQ_SNDBUF' option shall retrieve the underlying kernel transmit buffer
|
|
|
|
size for the specified 'socket'. A value of zero means that the OS default is
|
|
|
|
in effect. For details refer to your operating system documentation for the
|
|
|
|
'SO_SNDBUF' socket option.
|
|
|
|
|
2010-06-03 14:15:05 +02:00
|
|
|
[horizontal]
|
2011-03-24 14:48:50 +01:00
|
|
|
Option value type:: int
|
2010-05-31 12:53:40 +02:00
|
|
|
Option value unit:: bytes
|
|
|
|
Default value:: 0
|
|
|
|
Applicable socket types:: all
|
|
|
|
|
|
|
|
|
|
|
|
ZMQ_RCVBUF: Retrieve kernel receive buffer size
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The 'ZMQ_RCVBUF' option shall retrieve the underlying kernel receive buffer
|
|
|
|
size for the specified 'socket'. A value of zero means that the OS default is
|
|
|
|
in effect. For details refer to your operating system documentation for the
|
|
|
|
'SO_RCVBUF' socket option.
|
|
|
|
|
2010-06-03 14:15:05 +02:00
|
|
|
[horizontal]
|
2011-03-24 14:48:50 +01:00
|
|
|
Option value type:: int
|
2010-05-31 12:53:40 +02:00
|
|
|
Option value unit:: bytes
|
|
|
|
Default value:: 0
|
|
|
|
Applicable socket types:: all
|
|
|
|
|
|
|
|
|
2010-10-17 09:54:12 +02:00
|
|
|
ZMQ_LINGER: Retrieve linger period for socket shutdown
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
2010-12-01 10:57:37 +01:00
|
|
|
The 'ZMQ_LINGER' option shall retrieve the linger period for the specified
|
|
|
|
'socket'. The linger period determines how long pending messages which have
|
|
|
|
yet to be sent to a peer shall linger in memory after a socket is closed with
|
|
|
|
linkzmq:zmq_close[3], and further affects the termination of the socket's
|
|
|
|
context with linkzmq:zmq_term[3]. The following outlines the different
|
|
|
|
behaviours:
|
|
|
|
|
|
|
|
* The default value of '-1' specifies an infinite linger period. Pending
|
|
|
|
messages shall not be discarded after a call to _zmq_close()_; attempting to
|
|
|
|
terminate the socket's context with _zmq_term()_ shall block until all
|
|
|
|
pending messages have been sent to a peer.
|
|
|
|
|
|
|
|
* The value of '0' specifies no linger period. Pending messages shall be
|
|
|
|
discarded immediately when the socket is closed with _zmq_close()_.
|
|
|
|
|
|
|
|
* Positive values specify an upper bound for the linger period in milliseconds.
|
|
|
|
Pending messages shall not be discarded after a call to _zmq_close()_;
|
|
|
|
attempting to terminate the socket's context with _zmq_term()_ 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
|
2010-12-01 10:57:37 +01:00
|
|
|
Default value:: -1 (infinite)
|
2010-10-16 10:53:29 +02:00
|
|
|
Applicable socket types:: all
|
|
|
|
|
2011-01-26 07:01:06 +01:00
|
|
|
|
2010-12-01 10:57:37 +01:00
|
|
|
ZMQ_RECONNECT_IVL: Retrieve reconnection interval
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
2011-01-26 07:01:06 +01:00
|
|
|
The 'ZMQ_RECONNECT_IVL' option shall retrieve the initial reconnection interval
|
|
|
|
for the specified 'socket'. The reconnection interval is the period 0MQ shall
|
2010-12-01 10:57:37 +01:00
|
|
|
wait between attempts to reconnect disconnected peers when using
|
|
|
|
connection-oriented transports.
|
|
|
|
|
|
|
|
NOTE: The reconnection interval may be randomized by 0MQ to prevent
|
|
|
|
reconnection storms in topologies with a large number of peers per socket.
|
2010-10-17 09:54:12 +02:00
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: milliseconds
|
|
|
|
Default value:: 100
|
2010-12-01 10:57:37 +01:00
|
|
|
Applicable socket types:: all, only for connection-oriented transports
|
2010-10-17 09:54:12 +02:00
|
|
|
|
2010-10-16 10:53:29 +02:00
|
|
|
|
2011-01-26 07:01:06 +01:00
|
|
|
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
|
2011-06-17 12:22:02 +02:00
|
|
|
performed and reconnect interval calculations are only based on
|
|
|
|
ZMQ_RECONNECT_IVL.
|
2011-01-26 07:01:06 +01:00
|
|
|
|
|
|
|
NOTE: Values less than ZMQ_RECONNECT_IVL will be ignored.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: milliseconds
|
|
|
|
Default value:: 0 (only use ZMQ_RECONNECT_IVL)
|
|
|
|
Applicable socket types:: all, only for connection-oriented transport
|
|
|
|
|
|
|
|
|
2010-12-01 10:57:37 +01:00
|
|
|
ZMQ_BACKLOG: Retrieve maximum length of the queue of outstanding connections
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The 'ZMQ_BACKLOG' option shall retrieve 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-10-17 10:23:58 +02:00
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: connections
|
|
|
|
Default value:: 100
|
2010-12-01 10:57:37 +01:00
|
|
|
Applicable socket types:: all, only for connection-oriented transports
|
2010-10-17 10:23:58 +02:00
|
|
|
|
|
|
|
|
2011-03-02 09:00:36 +01:00
|
|
|
ZMQ_MAXMSGSIZE: Maximum acceptable inbound message size
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
2011-05-15 18:25:43 +02:00
|
|
|
The option shall retrieve limit for the inbound messages. If a peer sends
|
2011-03-02 09:00:36 +01:00
|
|
|
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
|
|
|
|
|
|
|
|
|
2011-05-15 18:25:43 +02:00
|
|
|
ZMQ_MULTICAST_HOPS: Maximum network hops for multicast packets
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
2011-06-12 15:24:08 +02:00
|
|
|
The option shall retrieve time-to-live used for outbound multicast packets.
|
2011-05-15 18:25:43 +02:00
|
|
|
The default of 1 means that the multicast packets don't leave the local network.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: network hops
|
|
|
|
Default value:: 1
|
|
|
|
Applicable socket types:: all, when using multicast transports
|
|
|
|
|
|
|
|
|
2011-06-12 15:24:08 +02:00
|
|
|
ZMQ_FILTER: Switches message filtering on or off
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
The option shall retrieve the filtering behaiour of the socket.
|
|
|
|
If 1, messages are filtered according to subcriptions as expected.
|
|
|
|
If 0, messages are not filtered. This is a performance tweak. If a device
|
|
|
|
receives a message from XSUB socket and it is about to send it to XPUB socket
|
|
|
|
immediately, filtering would be done twice. We can thus turn off filtering in
|
|
|
|
XSUB socket and rely on filtering in XPUB socket.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: boolean
|
|
|
|
Default value:: 1
|
|
|
|
Applicable socket types:: ZMQ_SUB, ZMQ_XSUB
|
|
|
|
|
|
|
|
|
2011-06-17 12:22:02 +02:00
|
|
|
ZMQ_RCVTIMEO: Maximum time before a socket operation returns with EAGAIN
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
Retrieve the timeout for recv 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
|
|
|
|
|
|
|
|
|
|
|
|
ZMQ_SNDTIMEO: Maximum time before a socket operation returns with EAGAIN
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
Retrieve 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.
|
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int
|
|
|
|
Option value unit:: milliseconds
|
|
|
|
Default value:: -1 (infinite)
|
|
|
|
Applicable socket types:: all
|
|
|
|
|
|
|
|
|
2010-09-27 09:53:30 +02:00
|
|
|
ZMQ_FD: Retrieve file descriptor associated with the socket
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
2010-12-01 10:57:37 +01:00
|
|
|
The 'ZMQ_FD' option shall retrieve the file descriptor associated with the
|
|
|
|
specified 'socket'. The returned file descriptor can be used to integrate the
|
|
|
|
socket into an existing event loop; the 0MQ library shall signal any pending
|
|
|
|
events on the socket in an _edge-triggered_ fashion by making the file
|
|
|
|
descriptor become ready for reading.
|
|
|
|
|
|
|
|
NOTE: The ability to read from the returned file descriptor does not
|
|
|
|
necessarily indicate that messages are available to be read from, or can be
|
|
|
|
written to, the underlying socket; applications must retrieve the actual event
|
|
|
|
state with a subsequent retrieval of the 'ZMQ_EVENTS' option.
|
|
|
|
|
|
|
|
CAUTION: The returned file descriptor is intended for use with a 'poll' or
|
|
|
|
similar system call only. Applications must never attempt to read or write data
|
2011-02-24 16:57:53 +01:00
|
|
|
to it directly, neither should they try to close it.
|
2010-09-27 09:53:30 +02:00
|
|
|
|
|
|
|
[horizontal]
|
|
|
|
Option value type:: int on POSIX systems, SOCKET on Windows
|
|
|
|
Option value unit:: N/A
|
|
|
|
Default value:: N/A
|
|
|
|
Applicable socket types:: all
|
|
|
|
|
|
|
|
|
2010-12-01 10:57:37 +01:00
|
|
|
ZMQ_EVENTS: Retrieve socket event state
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The 'ZMQ_EVENTS' option shall retrieve the event state for the specified
|
|
|
|
'socket'. The returned value is a bit mask constructed by OR'ing a combination
|
|
|
|
of the following event flags:
|
|
|
|
|
|
|
|
*ZMQ_POLLIN*::
|
|
|
|
Indicates that at least one message may be received from the specified socket
|
|
|
|
without blocking.
|
|
|
|
|
|
|
|
*ZMQ_POLLOUT*::
|
|
|
|
Indicates that at least one message may be sent to the specified socket without
|
|
|
|
blocking.
|
|
|
|
|
|
|
|
The combination of a file descriptor returned by the 'ZMQ_FD' option being
|
|
|
|
ready for reading but no actual events returned by a subsequent retrieval of
|
|
|
|
the 'ZMQ_EVENTS' option is valid; applications should simply ignore this case
|
|
|
|
and restart their polling operation/event loop.
|
2010-09-27 09:53:30 +02:00
|
|
|
|
|
|
|
[horizontal]
|
2011-03-24 15:07:23 +01:00
|
|
|
Option value type:: int
|
2010-09-27 09:53:30 +02:00
|
|
|
Option value unit:: N/A (flags)
|
|
|
|
Default value:: N/A
|
|
|
|
Applicable socket types:: all
|
|
|
|
|
|
|
|
|
2010-05-31 12:53:40 +02:00
|
|
|
RETURN VALUE
|
|
|
|
------------
|
|
|
|
The _zmq_getsockopt()_ function shall return zero if successful. Otherwise it
|
|
|
|
shall return `-1` and set 'errno' to one of the values defined below.
|
|
|
|
|
|
|
|
|
|
|
|
ERRORS
|
|
|
|
------
|
|
|
|
*EINVAL*::
|
|
|
|
The requested option _option_name_ is unknown, or the requested _option_len_ or
|
|
|
|
_option_value_ is invalid, or the size of the buffer pointed to by
|
|
|
|
_option_value_, as specified by _option_len_, is insufficient for storing the
|
|
|
|
option value.
|
|
|
|
*ETERM*::
|
|
|
|
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-05-31 12:53:40 +02:00
|
|
|
|
|
|
|
|
|
|
|
EXAMPLE
|
|
|
|
-------
|
2011-04-11 12:14:00 +02:00
|
|
|
.Retrieving the high water mark for outgoing messages
|
2010-05-31 12:53:40 +02:00
|
|
|
----
|
2011-04-11 12:14:00 +02:00
|
|
|
/* Retrieve high water mark into sndhwm */
|
2011-03-24 16:47:33 +01:00
|
|
|
int sndhwm;
|
|
|
|
size_t sndhwm_size = sizeof (sndhwm);
|
|
|
|
rc = zmq_getsockopt (socket, ZMQ_SNDHWM, &sndhwm, &sndhwm_size);
|
2010-05-31 12:53:40 +02:00
|
|
|
assert (rc == 0);
|
|
|
|
----
|
|
|
|
|
|
|
|
|
|
|
|
SEE ALSO
|
|
|
|
--------
|
|
|
|
linkzmq:zmq_setsockopt[3]
|
|
|
|
linkzmq:zmq_socket[3]
|
|
|
|
linkzmq:zmq[7]
|
|
|
|
|
|
|
|
|
2010-09-04 15:55:11 +02:00
|
|
|
AUTHORS
|
|
|
|
-------
|
|
|
|
The 0MQ documentation was written by Martin Sustrik <sustrik@250bpm.com> and
|
|
|
|
Martin Lucina <mato@kotelna.sk>.
|