mirror of
https://github.com/zeromq/libzmq.git
synced 2025-11-17 01:16:02 +01:00
problem: no thread-safe alternative for ZMQ_PAIR
Solution: create ZMQ_CHANNEL, the thread safe alternative
This commit is contained in:
@@ -30,7 +30,7 @@ The 'endpoint' is a string consisting of a 'transport'`://` followed by an
|
||||
'vmci':: virtual machine communications interface (VMCI), see linkzmq:zmq_vmci[7]
|
||||
'udp':: unreliable unicast and multicast using UDP, see linkzmq:zmq_udp[7]
|
||||
|
||||
Every 0MQ socket type except 'ZMQ_PAIR' supports one-to-many and many-to-one
|
||||
Every 0MQ socket type except 'ZMQ_PAIR' and 'ZMQ_CHANNEL' supports one-to-many and many-to-one
|
||||
semantics. The precise semantics depend on the socket type and are defined in
|
||||
linkzmq:zmq_socket[3].
|
||||
|
||||
|
||||
@@ -30,7 +30,7 @@ The 'endpoint' is a string consisting of a 'transport'`://` followed by an
|
||||
'vmci':: virtual machine communications interface (VMCI), see linkzmq:zmq_vmci[7]
|
||||
'udp':: unreliable unicast and multicast using UDP, see linkzmq:zmq_udp[7]
|
||||
|
||||
Every 0MQ socket type except 'ZMQ_PAIR' supports one-to-many and many-to-one
|
||||
Every 0MQ socket type except 'ZMQ_PAIR' and 'ZMQ_CHANNEL' supports one-to-many and many-to-one
|
||||
semantics. The precise semantics depend on the socket type and are defined in
|
||||
linkzmq:zmq_socket[3].
|
||||
|
||||
@@ -39,7 +39,7 @@ immediately but as needed by 0MQ. Thus a successful call to _zmq_connect()_
|
||||
does not mean that the connection was or could actually be established.
|
||||
Because of this, for most transports and socket types the order in which
|
||||
a 'server' socket is bound and a 'client' socket is connected to it does not
|
||||
matter. The _ZMQ_PAIR_ sockets are an exception, as they do not automatically
|
||||
matter. The _ZMQ_PAIR_ and _ZMQ_CHANNEL_ sockets are an exception, as they do not automatically
|
||||
reconnect to endpoints.
|
||||
|
||||
NOTE: following a _zmq_connect()_, for socket types except for ZMQ_ROUTER,
|
||||
|
||||
@@ -41,7 +41,7 @@ the event that a peer is unavailable to receive them.
|
||||
|
||||
Conventional sockets allow only strict one-to-one (two peers), many-to-one
|
||||
(many clients, one server), or in some cases one-to-many (multicast)
|
||||
relationships. With the exception of 'ZMQ_PAIR', 0MQ sockets may be connected
|
||||
relationships. With the exception of 'ZMQ_PAIR' and 'ZMQ_CHANNEL', 0MQ sockets may be connected
|
||||
*to multiple endpoints* using _zmq_connect()_, while simultaneously accepting
|
||||
incoming connections *from multiple endpoints* bound to the socket using
|
||||
_zmq_bind()_, thus allowing many-to-many relationships.
|
||||
@@ -60,6 +60,7 @@ Following are the thread safe sockets:
|
||||
* ZMQ_SCATTER
|
||||
* ZMQ_GATHER
|
||||
* ZMQ_PEER
|
||||
* ZMQ_CHANNEL
|
||||
|
||||
.Socket types
|
||||
The following sections present the socket types defined by 0MQ, grouped by the
|
||||
@@ -476,6 +477,47 @@ Outgoing routing strategy:: See text
|
||||
Incoming routing strategy:: Fair-queued
|
||||
Action in mute state:: Return EAGAIN
|
||||
|
||||
Channel pattern
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
The channel pattern is the thread-safe version of the exclusive pair pattern.
|
||||
The channel pattern is used to connect a peer to precisely one other
|
||||
peer. This pattern is used for inter-thread communication across the inproc
|
||||
transport.
|
||||
|
||||
NOTE: Channel is still in draft phase.
|
||||
|
||||
ZMQ_CHANNEL
|
||||
^^^^^^^^
|
||||
A socket of type 'ZMQ_CHANNEL' can only be connected to a single peer at any one
|
||||
time. No message routing or filtering is performed on messages sent over a
|
||||
'ZMQ_CHANNEL' socket.
|
||||
|
||||
When a 'ZMQ_CHANNEL' socket enters the 'mute' state due to having reached the
|
||||
high water mark for the connected peer, or, for connection-oriented transports,
|
||||
if the ZMQ_IMMEDIATE option is set and there is no connected peer, then
|
||||
any linkzmq:zmq_send[3] operations on the socket shall block until the peer
|
||||
becomes available for sending; messages are not discarded.
|
||||
|
||||
While 'ZMQ_CHANNEL' sockets can be used over transports other than linkzmq:zmq_inproc[7],
|
||||
their inability to auto-reconnect coupled with the fact new incoming connections will
|
||||
be terminated while any previous connections (including ones in a closing state)
|
||||
exist makes them unsuitable for TCP in most cases.
|
||||
|
||||
NOTE: 'ZMQ_CHANNEL' sockets are designed for inter-thread communication across
|
||||
the linkzmq:zmq_inproc[7] transport and do not implement functionality such
|
||||
as auto-reconnection.
|
||||
|
||||
NOTE: 'ZMQ_CHANNEL' sockets are threadsafe. They do not accept ZMQ_RCVMORE on receives.
|
||||
This limits them to single part data.
|
||||
|
||||
[horizontal]
|
||||
.Summary of ZMQ_CHANNEL characteristics
|
||||
Compatible peer sockets:: 'ZMQ_CHANNEL'
|
||||
Direction:: Bidirectional
|
||||
Send/receive pattern:: Unrestricted
|
||||
Incoming routing strategy:: N/A
|
||||
Outgoing routing strategy:: N/A
|
||||
Action in mute state:: Block
|
||||
|
||||
Native Pattern
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
Reference in New Issue
Block a user