From 4a7aad06d95701cf232198093ce396dcdbb53e5b Mon Sep 17 00:00:00 2001 From: Martin Sustrik Date: Thu, 16 Feb 2012 10:01:47 +0900 Subject: ZeroMQ renamed to Crossroads Signed-off-by: Martin Sustrik --- doc/zmq_tcp.txt | 162 -------------------------------------------------------- 1 file changed, 162 deletions(-) delete mode 100644 doc/zmq_tcp.txt (limited to 'doc/zmq_tcp.txt') diff --git a/doc/zmq_tcp.txt b/doc/zmq_tcp.txt deleted file mode 100644 index f5499d3..0000000 --- a/doc/zmq_tcp.txt +++ /dev/null @@ -1,162 +0,0 @@ -zmq_tcp(7) -========== - - -NAME ----- -zmq_tcp - 0MQ unicast transport using TCP - - -SYNOPSIS --------- -TCP is an ubiquitous, reliable, unicast transport. When connecting distributed -applications over a network with 0MQ, using the TCP transport will likely be -your first choice. - - -ADDRESSING ----------- -A 0MQ address string consists of two parts as follows: -'transport'`://`'endpoint'. The 'transport' part specifies the underlying -transport protocol to use, and for the TCP transport shall be set to `tcp`. -The meaning of the 'endpoint' part for the TCP transport is defined below. - - -Assigning a local address to a socket -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -When assigning a local address to a socket using _zmq_bind()_ with the 'tcp' -transport, the 'endpoint' shall be interpreted as an 'interface' followed by a -colon and the TCP port number to use. - -An 'interface' may be specified by either of the following: - -* The wild-card `*`, meaning all available interfaces. -* The primary IPv4 or IPv6 address assigned to the interface, in its numeric - representation. -* The interface name as defined by the operating system. - -NOTE: Interface names are not standardised in any way and should be assumed to -be arbitrary and platform dependent. On Win32 platforms no short interface -names exist, thus only the primary IP address may be used to specify an -'interface'. - -Connecting a socket -~~~~~~~~~~~~~~~~~~~ -When connecting a socket to a peer address using _zmq_connect()_ with the 'tcp' -transport, the 'endpoint' shall be interpreted as a 'peer address' followed by -a colon and the TCP port number to use. - -A 'peer address' may be specified by either of the following: - -* The DNS name of the peer. -* The IPv4 or IPv6 address of the peer, in it's numeric representation. - - -WIRE FORMAT ------------ -0MQ messages are transmitted over TCP in frames consisting of an encoded -'payload length', followed by a 'flags' field and the message body. The 'payload -length' is defined as the combined length in octets of the message body and the -'flags' field. - -For frames with a 'payload length' not exceeding 254 octets, the 'payload -length' shall be encoded as a single octet. The minimum valid 'payload length' -of a frame is 1 octet, thus a 'payload length' of 0 octets is invalid and such -frames SHOULD be ignored. - -For frames with a 'payload length' exceeding 254 octets, the 'payload length' -shall be encoded as a single octet with the value `255` followed by the -'payload length' represented as a 64-bit unsigned integer in network byte -order. - -The 'flags' field consists of a single octet containing various control flags: - -Bit 0 (MORE): _More message parts to follow_. A value of 0 indicates that there -are no more message parts to follow; or that the message being sent is not a -multi-part message. A value of 1 indicates that the message being sent is a -multi-part message and more message parts are to follow. - -Bits 1-7: _Reserved_. Bits 1-7 are reserved for future expansion and MUST be -set to zero. - -The following ABNF grammar represents a single 'frame': - -.... - frame = (length flags data) - length = OCTET / (escape 8OCTET) - flags = OCTET - escape = %xFF - data = *OCTET -.... - -The following diagram illustrates the layout of a frame with a 'payload length' -not exceeding 254 octets: - -.... -0 1 2 3 -0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Payload length| Flags | Message body ... | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Message body ... -+-+-+-+-+-+-+- ... -.... - -The following diagram illustrates the layout of a frame with a 'payload length' -exceeding 254 octets: - -.... -0 1 2 3 -0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| 0xff | Payload length ... | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Payload length ... | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Payload length| Flags | Message body ... | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Message body ... -+-+-+-+-+-+-+-+ ... -.... - - -EXAMPLES --------- -.Assigning a local address to a socket ----- -/* TCP port 5555 on all available interfaces */ -rc = zmq_bind(socket, "tcp://*:5555"); -assert (rc == 0); -/* TCP port 5555 on the local loop-back interface on all platforms */ -rc = zmq_bind(socket, "tcp://127.0.0.1:5555"); -assert (rc == 0); -/* TCP port 5555 on the first Ethernet network interface on Linux */ -rc = zmq_bind(socket, "tcp://eth0:5555"); -assert (rc == 0); ----- - -.Connecting a socket ----- -/* Connecting using an IP address */ -rc = zmq_connect(socket, "tcp://192.168.1.1:5555"); -assert (rc == 0); -/* Connecting using a DNS name */ -rc = zmq_connect(socket, "tcp://server1:5555"); -assert (rc == 0); ----- - - -SEE ALSO --------- -linkzmq:zmq_bind[3] -linkzmq:zmq_connect[3] -linkzmq:zmq_pgm[7] -linkzmq:zmq_ipc[7] -linkzmq:zmq_inproc[7] -linkzmq:zmq[7] - - -AUTHORS -------- -The 0MQ documentation was written by Martin Sustrik and -Martin Lucina . -- cgit v1.2.3