ZeroMQ API (v) Transfer mode

1. Unicast transmission using TCP: ZMQ_TCP (7) 1.1 name

ZMQ_TCP-ZMQ unicast transmission with TCP

1.2 Overview

TCP is a ubiquitous, reliable unicast transmission. Using TCP transport may be your first choice when distributing applications through network connections with ZMQ.

1.3 Resolution

The ZMQ endpoint is a string that consists of a transport://followed by an address. transport specifies the underlying protocol to use. This address specifies the transport-specific address to connect to.

For TCP transmissions, the transport is TCP, and the meaning of the address part is defined as follows.

1.3.1 Assigning a local address to a socket

When a socket local address is assigned to a socket using Zmq_bind () with a TCP transport, the endpoint is interpreted as an interface followed by a colon and the TCP port number to be used.

An interface can be specified by any of the following:

The wildcard * represents all available interfaces.

The primary IPV4 or IPV6 address assigned to the interface, in its numeric representation.

The name of the non-portable interface defined by the operating system.

The TCP port number can be specified in the following ways:

A value that is typically more than 1024 on a POSIX system.

A wildcard * represents a temporary port that is assigned by the system.

When using a temporary port, the caller should use the ZMQ_LAST_ENDPOINT socket option to retrieve the actual assigned port. For more information, see Zmq_getsockopt (3).

1.3.2 de-wildcard address from socket

When a wildcard * endpoint is used in Zmq_bind (), the caller should unbind this endpoint from the socket using the actual endpoind obtained from the zmq_last_endpoint socket option using Zmq_unbind ().

1.3.3 Connecting a socket

When a socket is connected to a peer address using zmq_connect () with TCP transport, the endpoint should be interpreted as a peer address followed by a colon and the TCP port number to be used. You can optionally specify a source_endpoint as the source address for the connection; tcp://Source_endpoint; ' Endpoint ', see the interface instructions above.

A peer address can be specified by any of the following:

The DNS name of the peer.

The IPV4 or IPV6 address of the peer, in its numeric representation.

Note: A description of the ZEROMQ Message Transfer Protocol (ZMTP) that is used by the TCP transport can be found in http://rfc.zeromq.org/spec:15

2. Reliable Multicast transmission using PGM: ZMQ_PGM (7) 2.1 names

ZMQ_PGM-ZMQ Reliable multicast transmission using PGM

2.2 Overview

PGM (Pragmatic General multicast) is a reliable data multicast transport protocol on IP networks.

2.3 Description

ZMQ implements two variants of PGM, and the PGM datagram is layered directly above the RFC 3208 (PGM Transport) and "encapsulated PGM" or EPGM-defined IP datagrams, where the PGM datagram is encapsulated in a UDP datagram (EPGM transmission).

PGM and EPGM transports can only be used with zmq_pub and zmq_sub socket types.

In addition, the PGM socket defaults to the rate limit. For more information, see the Zmq_rate and ZMQ_RECOVERY_IVL options documented in Zmq_setsockopt (3).

The PGM transport implementation requires access to the original IP socket. Additional permissions may be required on some operating systems for this operation. Applications that do not require direct interop with other PGM are encouraged to use the EPGM transport without any special permissions.

2.4 Resolution

The ZMQ endpoint is a string that consists of a transport://followed by an address. transport specifies the underlying protocol to use. This address specifies the transport-specific address to connect to.

For PGM transport, transport is PGM, and for EPGM protocol, shipping is EPGM. The meaning of the address section is defined as follows.

2.5 Connecting a socket

When a socket is connected to a peer address using zmq_connect () with PGM or EPGM transmission, the endpoint is interpreted as an interface followed by a semicolon followed by a multicast address followed by a colon and a port number.

An interface can be specified by any of the following:

The interface name defined by the operating system.

The primary IPV4 address assigned to the interface as a numeric representation.

Note: interface names are not standardized in any way and should be considered arbitrary and depend on the platform. On the Win32 platform, there is no short interface name, so only the primary IPV4 address can be used to specify the interface. The interface section can be omitted, in which case the default interface section will be selected. The multicast address is specified by the IPV4 multicast address in its numeric representation.

2.5 Wire Format

Continuous PGM datagrams are interpreted by ZMQ as a single continuous stream of data, where ZMQ messages are not necessarily aligned with the PGM datagram boundary, and a single ZMQ message can span several PGM datagrams. This stream consists of a ZMQ message encapsulated in a frame described in zmq_tcp (7).

2.5.1 PGM Datagram Payload

The following ABNF syntax represents the payload of a single PGM datagram used by ZMQ:

Datagram = (offset data)
offset = 2OCTET
data = *octet

In order to delay the addition of the consumer to identify the message boundary, each PGM datagram payload starts with a 16-bit unsigned integer in the network byte order, specifies the offset of the first message frame in the datagram, or if the datagram contains a value of 0xFFFF containing only the middle portion of the larger message.

Note that the offset specifies the starting position of the first message, not the first message part. Therefore, if there is a trailing message part at the beginning of the packet, the offset ignores them and points to the first initial message part in the packet.

Illustrates the layout of a single PGM datagram payload:

+------------------+----------------------+
| Offset (bits) | Data |
+------------------+----------------------+

Further illustrates the layout of the three example ZMQ frames in a continuous PGM datagram payload:

First Datagram payload
+--------------+-------------+---------------------+
| Frame Offset | Frame 1 | Frame 2, Part 1 |
| 0x0000 | (Message 1) | (Message 2, part 1) |
+--------------+-------------+---------------------+

Second Datagram payload
+--------------+---------------------+
| Frame Offset | Frame 2, Part 2 |
| 0xFFFF | (Message 2, part 2) |
+--------------+---------------------+

Third Datagram payload
+--------------+----------------------------+-------------+
| Frame Offset | Frame 2, final 8 bytes | Frame 3 |
| 0x0008 | (Message 2, Final 8 bytes) | (Message 3) |
+--------------+----------------------------+-------------+

3, local interprocess communication transmission: ZMQ_IPC (7) 3.1 name

ZMQ_IPC-ZMQ local inter-process communication transmission

3.2 Overview

Inter-process transport uses a system-dependent IPC mechanism to pass messages between local processes.

Note: Interprocess transfers are currently implemented only on operating systems that provide UNIX domain sockets.

3.3 Resolution

The ZMQ endpoint is a string that consists of a transport://followed by an address. transport specifies the underlying protocol to use.

This address specifies the transport-specific address to connect to. For inter-process transfers, the transmission is IPC, and the meaning of the address part is defined below.

3.3.1 Binding a socket

When binding a socket to a local address using zmq_bind () with an IPC transfer, the endpoint should be interpreted as identifying any string that identifies the pathname to be created. The pathname must be unique within the operating system namespace used by the IPC implementation, and must meet any restrictions on the format and length of the pathname by the operating system.

When the address is *, zmq_bind () should generate a unique temporary path name. The caller should use the ZMQ_LAST_ENDPOINT socket option to retrieve this pathname. For more information, see Zmq_getsockopt (3).

Any existing bindings to the same endpoint should be overwritten. That is, if the second process is bound to an endpoint that has already been bound by the process, this succeeds, and the first process loses its binding. In this behavior, the IPC transmission is inconsistent with the TCP or INPROC transmission.

The process must be able to write to the endpoint path name. This will be the absolute pathname when the endpoint starts with/, for example, the ipc:///pathname. If the endpoint specifies a directory that does not exist, the binding fails.

On Linux only, an abstract namespace should be used when the endpoint pathname begins with @. The abstract namespace is independent of the file system, and it will fail if a process attempts to bind an endpoint that has already been bound by the process. For more information, see UNIX (7).

The maximum size of the IPC path name depends on the operating system. On Linux, up to 113 characters, including the "ipc://" prefix (the real path name is 107 characters).

3.3.2 de-wildcard address from socket

When a wildcard * endpoint is used in Zmq_bind (), the caller should unbind this endpoint from the socket using the actual endpoind obtained from the zmq_last_endpoint socket option using Zmq_unbind ().

3.3.3 Connecting a socket

When a socket is connected to a peer address using zmq_connect () with an IPC transmission, the endpoint should be interpreted as identifying any string that identifies the pathname to be connected. The pathname must first be created within the operating system namespace by assigning it to a socket with zmq_bind ().

4, Local in-process (inter-thread) communication transmission: Zmq_inproc (7) 4.1 name

ZMQ_INPROC-ZMQ Local in-process (inter-thread) communication transmission

4.2 Overview

In-Process transports pass messages through memory directly between threads that share a single ZMQ context.

Note: I/O threads are not involved when passing messages using inproc transport. Therefore, if you are using the ZMQ context for in-process messaging, you can initialize the context with just 0 I/O threads. For more information, see Zmq_init (3).

4.3 Resolution

The ZMQ endpoint is a string that consists of a transport://followed by an address. transport specifies the underlying protocol to use. This address specifies the transport-specific address to connect to.

For the carrying out of the transport, transport is unreasonable, the meaning of the address section is defined below.

4.3.1 Assigning a local address to a socket

When a local address is assigned to a socket using Zmq_bind () with InProc transport, the endpoint should be interpreted as identifying any string of names to be created. The name must be unique in the ZMQ context associated with the socket and can be up to 256 characters in length. There are no other restrictions on the format of names.

4.3.2 Connecting a socket

When a socket is connected to a peer address using zmq_connect () with INPROC transmission, the endpoint is interpreted as an arbitrary string identifying the name to be connected. The name must first be created by assigning it to at least one socket in the same ZMQ context as the connected socket.

5. Cluster IPC protocol: zmq_tipc5.1 Name

ZMQ_TIPC-ZMQ unicast transmission with TIPC

5.2 Overview

TIPC is a cluster IPC protocol with a location-transparent addressing scheme.

5.3 Resolution

The ZMQ endpoint is a string that consists of a transport://followed by an address. transport specifies the underlying protocol to use. This address specifies the transport-specific address to connect to.

For TIPC transport, transport is tipc, the meaning of the address section is defined as follows.

5.3.1 Assigning a port name to a socket

When assigning port names to sockets using _zmq_bind () _ and ' TIPC '

Transport, the ' endpoint ' is defined as follows:
{Type,lower,upper}

* Type is the number (U32) ID of your service.
* Lower and Upper specify a range for your service.

Willingness to publish the same service with overlapping lower/higher IDs
Causes connection requests to be distributed to these requests in a circular manner.

5.3.2 Connecting a socket

When a socket is connected to a peer address using zmq_connect () with TIPC transmission, the endpoint is interpreted as a service ID followed by a comma and an instance ID.

The instance ID must be in the lower/higher range of the port name of the publication for the endpoint to be valid.

ZeroMQ API (v) Transfer mode