|
method |
description and examples |
variables data type |
|
creates a new socket within the specified context:
LET socket_name = context_name.Socket("socket_type")
|
STRING for the parameter |
|
|
terminates the specified context:
CALL contex_name.term()
Context termination includes the following steps:
|
|
Possible socket types include:
|
ZMQ.PAIR sockets serve as local in-process communication transport and, thus, provide inter-thread communication. Any ZMQ.PAIR socket can be connected only to one peer at a time. ZMQ.PAIR sockets do not get auto-connected, and messages sent over them cannot be routed or filtered. ZMQ.PAIR sockets enter the mute state if the peer is not connected or if the socket has reached the upper limit defined for messaging over the corresponding peer. When a ZMQ.PAIR socket is in a mute state, no messages are sent through it until the peer becomes available for sending; messages are not cancelled.
Compatible sockets: ZMQ.PAIR Messaging direction: Bidirectional Send/receive pattern: Unrestricted Incoming routing strategy: — Outgoing routing strategy: — Mute state: Block
|
|
|
ZMQ.PUB sockets are used by a publisher to distribute data to a number of subscribers. Messages are distributed in a fan-out fashion to all connected peers. With ZMQ.PUB sockets, a subscriber can receive only a complete message: sending message parts is not available for this type of socket . ZMQ.PUB sockets enter the mute state if the socket has reached the upper limit defined for the subscriber. When a ZMQ.PUB socket is in a mute state, any message sent to the corresponding subscriber will be dropped until the mute state ends. Message sending is never blocked with this socket type.
Compatible sockets: ZMQ.SUB, ZMQ.XSUB Messaging direction: Unidirectional Send/receive pattern: Send only Incoming routing strategy: — Outgoing routing strategy: Fan out Mute state: Drop
|
|
|
Besides embracing the full functionality of ZMQ.PUB sockets, ZMQ.XPUB sockets allow receiving subscriptions from the peers in a form of incoming messages. Subscription message is a message consisting of a subscription prefix (byte 1 for subscriptions or byte 0 for unsubscriptions) and a subscription body. Messages without a prefix are received but produce no effect on subscription status.
Compatible sockets: ZMQ.SUB, ZMQ.XSUB Messaging direction: Unidirectional Send/receive pattern: Send messages, receive subscriptions Incoming routing strategy: — Outgoing routing strategy: Fan out Mute state: Drop
|
|
|
ZMQ.SUB sockets are used by subscribers to subscribe to messages distributed by a publisher. ZMQ.SUB sockets cannot be used for sending messages. Initially, a ZMQ.SUB socket is not subscribed to any messages. In order to subscribe, you have to establish a new message filter on the socket by the subscribe() method and specify what messages to subscribe to.
Compatible sockets: ZMQ.PUB, ZMQ.XPUB Messaging direction: Unidirectional Send/receive pattern: Receive only Incoming routing strategy: Fair-queued Outgoing routing strategy: —
|
|
|
ZMQ.XSUB sockets embrace the full functionality of ZMQ.SUB sockets but require that subscription is performed by sending subscription messages to the socket. Subscription message is a message consisting of a subscription prefix (byte 1 for subscriptions or byte 0 for unsubscriptions) and a subscription body. Messages without a prefix are received but produce no effect on subscription status.
Compatible sockets: ZMQ.PUB, ZMQ.XPUB Messaging direction: Unidirectional Send/receive pattern: Receive messages, send subscriptions Incoming routing strategy: Fair-queued Outgoing routing strategy: — Mute state: Drop
|
|
|
ZMQ.REQ sockets are used by a client for sending requests to and receiving replies from services. A ZMQ.REQ socket supports only an alternating sequence of send() and recv() calls. Each request is round-robined among all services, and each reply received is matched with the latest issued request. With no available services, message sending over the socket stops until at least one service becomes available; messages are not cancelled.
Compatible sockets: ZMQ.REP, ZMQ.ROUTER Messaging direction: Bidirectional Send/receive pattern: Send → Receive → Send → Receive → ... Incoming routing strategy: Round-robin Outgoing routing strategy: Last peer Mute state: Block
|
|
|
ZMQ.REP sockets are used by a service for receiving requests from and sending replies to a client. A ZMQ.REQ socket supports only an alternating sequence of send()and recv() calls. When received, requests are fair-queued among all the clients, and each reply sent is routed to the client that issued the latest request. If the original requester does not exist, the reply is silently cancelled.
Compatible sockets: ZMQ.REQ, ZMQ.DEALER Messaging direction: Bidirectional Send/receive pattern: Receive → Send → Receive → Send → ... Incoming routing strategy: Fair-queued Outgoing routing strategy: Last peer
|
|
|
ZMQ.DEALER sockets are sockets with advanced functionality used for extending request/reply sockets. With ZMQ.DEALER, each message sent is round-robined among all the connected peers, and each message received is fair-queued to all connected peers. ZMQ.DEALER sockets enter the mute state if no peers are connected or if the socket has reached the upper limit defined for messaging over its peers. When a ZMQ.DEALER socket is in a mute state, no messages are sent through it until the mute state ends or at least one peer becomes available for sending; messages are not cancelled. If a ZMQ.DEALER socket is connected to a ZMQ.REP socket, then any message to be sent must consist of an empty message part, a delimiter, and one or more message body parts.
Compatible sockets: ZMQ.ROUTER, ZMQ.REP, ZMQ.DEALER Messaging direction: Bidirectional Send/receive pattern: Unrestricted Incoming routing strategy: Round-robin Outgoing routing strategy: Fair-queued Mute state: Block
|
|
|
ZMQ.ROUTER sockets are sockets with advanced functionality used for extending request/reply sockets. When receiving messages, ZMQ.ROUTER sockets add a message part (which identifies the originating peer) to the beginning of the message before passing it to the application. The received messages are fair-queued to all the connected peers. When sending messages, ZMQ.ROUTER sockets remove the first part of the message and use it to identify the peer to which the message is routed. If the peer does not exist, the message is silently cancelled by default, unless the setRouterMandatory() method is applied to the corresponding object, with the parameter specified as 1:
LET router = context.Socket("ZMQ.ROUTER") CALL router.setRouterMandatory(1)
ZMQ.ROUTER sockets enter the mute state if it has reached the upper limit defined for messaging over all its peers. When a ZMQ.ROUTER socket is in a mute state, all the messages sent to it are dropped until the mute state ends. If a ZMQ.ROUTER socket enters the mute state because it has reached the upper limit defined for messaging over one of its peers, all the messages sent over this peer are dropped in the same manner. If a ZMQ.REQ socket is connected to a ZMQ.ROUTER socket, then any message to be sent must include one or more peer-identifying part, an empty delimiter message part, and one or more message body parts. The replies sent to the ZMQ.REQ socket must include the delimiter.
Compatible sockets: ZMQ.DEALER, ZMQ.REQ, ZMQ.ROUTER Messaging direction: Bidirectional Send/receive pattern: Unrestricted Incoming routing strategy: Described above Outgoing routing strategy: Fair-queued Mute state: Drop
|
|
|
ZMQ.PULL sockets are used by pipeline nodes for receiving messages from the upstream pipeline nodes. Messages are fair-queued to all the connected upstream nodes. ZMQ.PULL sockets cannot be used for sending messages.
Compatible sockets: ZMQ.PUSH Messaging direction: Unidirectional Send/receive pattern: Receive only Incoming routing strategy: Fair-queued Outgoing routing strategy: — Mute state: Block
|
|
|
ZMQ.PUSH sockets are used by pipeline nodes for sending messages to the downstream pipeline nodes. Messages are round-robined to all the connected downstream nodes. ZMQ.PUSH sockets cannot be used for receiving messages. ZMQ.PUSH sockets enter the mute state if no downstream nodes are connected or if the socket has reached the upper limit defined for messaging over all its downstream nodes. When a ZMQ.PUSH socket is in a mute state, no messages are sent through it until the mute state ends or at least one downstream node becomes available for sending; messages are not cancelled.
Compatible sockets: ZMQ.PULL Messaging direction: Unidirectional Send/receive pattern: Send only Incoming routing strategy: — Outgoing routing strategy: Round-robin Mute state: Block
|
|
|
ZMQ.STREAM sockets are used for sending and receiving TCP data from non-ZMQ peers when using the tcp:// transport. A ZMQ.STREAM socket can act as a client and/or server and send and/or receive TCP data asynchronously. When receiving TCP data, ZMQ.STREAM sockets add a message part (which identifies the originating peer) to the beginning of the message before passing it to the application. The received messages are fair-queued to all the connected peers. When sending TCP data, ZMQ.STREAM sockets remove the first part of the message and use it to identify the peer to which the message is routed. Unroutable messages cause an EHOSTUNREACH or EAGAIN error. When sending TCP data, a ZMQ_STREAM socket shall remove the first part of the message and use it to determine the identity of the peer the message shall be routed to, and unroutable messages shall cause an EHOSTUNREACH or EAGAIN error. ZMQ.STREAM sockets require applying connect() to open a connection to a server, setIdentity() to identify the socket, and disconnect() to close the connection.
Compatible sockets: — Messaging direction: Bidirectional Send/receive pattern: Unrestricted Incoming routing strategy: Described above Outgoing routing strategy: Fair-queued Mute state: EAGAIN = resource temporarily unavailable EHOSTUNREACH = no route to host
|