diff options
Diffstat (limited to 'man/man7')
| -rw-r--r-- | man/man7/zmq.7 | 151 | ||||
| -rw-r--r-- | man/man7/zmq_cl.7 | 124 | ||||
| -rw-r--r-- | man/man7/zmq_cpp.7 | 103 | ||||
| -rw-r--r-- | man/man7/zmq_inproc.7 | 42 | ||||
| -rw-r--r-- | man/man7/zmq_ipc.7 | 34 | ||||
| -rw-r--r-- | man/man7/zmq_java.7 | 9 | ||||
| -rw-r--r-- | man/man7/zmq_pgm.7 | 98 | ||||
| -rw-r--r-- | man/man7/zmq_python.7 | 9 | ||||
| -rw-r--r-- | man/man7/zmq_tcp.7 | 80 | ||||
| -rw-r--r-- | man/man7/zmq_udp.7 | 45 |
10 files changed, 0 insertions, 695 deletions
diff --git a/man/man7/zmq.7 b/man/man7/zmq.7 deleted file mode 100644 index ed7e08b..0000000 --- a/man/man7/zmq.7 +++ /dev/null @@ -1,151 +0,0 @@ -.TH zmq 7 "" "(c)2007-2010 iMatix Corporation" "0MQ User Manuals" -.SH NAME -0MQ \- a lightweight messaging kernel -.SH SYNOPSIS - -0MQ is an extension of POSIX sockets. It is a library that augments standard -networking sockets by special capabilities that you can otherwise get only -by using specialised "messaging middleware" products, such as automated -handling of connections and disconnections, delivery of a message to multiple -destinations, load balancing messages, sophisticated message filtering etc. - -0MQ is designed to be extremely fast. Expected end-to-end latencies for -messages passed over a LAN are in tens of microseconds. Expected -throughputs are to be measured in millions of messages per second. - -0MQ is designed to be very thin. It requires no more than couple of -pages in resident memory and is thus well suited for any environment ranging -from small embedded devices, routers and cell phones to enterprise-scale -data centers. - -0MQ runs on a wide range of operating systems and supports variety of processor -microarchitectures. - -0MQ is accessible from a large set of programming languages. - -0MQ is fully open sourced LGPL-licensed software. - -.SH CONTEXT -Each 0MQ socket lives within a specific context. Creating and destroying -context is a counterpart of library initialisation/deinitialisation as used -elsewhere. Ability to create multiple contexts saves the day when an application -happens to link (indirectly and involuntarily) with several instances of 0MQ. - -Initialise 0MQ context: -.BR zmq_init(3) - -Uninitialise 0MQ context: -.BR zmq_term(3) - -.SH MESSAGES -Message is a discrete unit of data passed between applications or components -of the same application. 0MQ message has no internal structure, it is an opaque -BLOB. When writing data to or reading data from the message, you are free to -use any of the many serialisation libraries available. Alternatively, you can -use your own serialisation code. The latter option is especially useful when -migrating legacy applications to 0MQ - there's no need to break existing -message formats. - -Initialise a message: -.BR zmq_msg_init(3) -.BR zmq_msg_size(3) -.BR zmq_msg_data(3) - -Uninitialise a message: -.BR zmq_msg_close(3) - -Access message content: -.BR zmq_msg_data(3) -.BR zmq_msg_size(3) - -Message manipulation: -.BR zmq_msg_copy(3) -.BR zmq_msg_move(3) - -.SH SOCKETS -0MQ sockets are very similar to POSIX sockets. See following manual pages to -understand them in depth. - -Creating a socket: -.BR zmq_socket(3) - -Closing a socket: -.BR zmq_close(3) - -Setting socket options: -.BR zmq_setsockopt(3) - -Establishing a message flow: -.BR zmq_bind(3) -.BR zmq_connect(3) - -Sending & receiving messages: -.BR zmq_send(3) -.BR zmq_flush(3) -.BR zmq_recv(3) - -.SH MULTIPLEXING -0MQ allows you to handle multiple sockets (0MQ as well as standard POSIX) -in an asynchronous manner. - -Poll for I/O events: -.BR zmq_poll(3) - -.SH ERROR HANDLING -0MQ defines couple of non-POSIX error codes. Use following functions to handle -them neatly. - -Convert error code into human readable string: -.BR zmq_strerror(3) - -.SH TRANSPORTS -0MQ allows for using different underlying transport mechanisms (even multiple -at once). Each transport mechanism has its own advantages and drawbacks. For -detailed description of individual mechanisms check following manual pages: - -TCP/IP transport: -.BR zmq_tcp(7) - -UDP reliable multicast transport: -.BR zmq_udp(7) - -PGM reliable multicast transport: -.BR zmq_pgm(7) - -Inter-process transport: -.BR zmq_ipc (7) - -In-process (inter-thread) transport: -.BR zmq_inproc(7) - -.SH DEVICES -Aside of the messaging library (a.k.a. messaging kernel) 0MQ provides pre-built -executables - devices - to serve as middle nodes in complex messaging -topologies. For detailed description of individual devices check following -manual pages: - -Forwarder device for PUB/SUB messaging: -.BR zmq_forwarder(1) - -Streamer device for UPSTREAM/DOWNSTREAM messaging: -.BR zmq_streamer(1) -.SH LANGUAGES -0MQ manual pages provide info on C API. To find out how the your -favourite language API maps to C API and thus how to find relevant manual pages, -see following articles: - -C++: -.BR zmq_cpp(7) - -Common Lisp: -.BR zmq_cl(7) - -Python: -.BR zmq_python(7) - -Ruby: -.BR zmq_ruby(7) - -.SH AUTHOR -Martin Sustrik <sustrik at 250bpm dot com> - diff --git a/man/man7/zmq_cl.7 b/man/man7/zmq_cl.7 deleted file mode 100644 index 0439028..0000000 --- a/man/man7/zmq_cl.7 +++ /dev/null @@ -1,124 +0,0 @@ -.TH zmq_cl 7 "" "(c)2007-2010 iMatix Corporation" "0MQ User Manuals" -.SH NAME -0MQ Common Lisp API \- interface between 0MQ and Common Lisp applications -.SH SYNOPSIS - -This manual page explains how Common Lisp API maps to underlying C -API. - -Common Lisp API repeats C API in general. All constants defined with C -API are available with Common Lisp API. C names are mapped to lisp -names by these rules: a) all names are `zmq' namespace; b) all names -are in lower case; c) underscores translate to dashes. - -Example of mappings: - -.IR zmq_msg_init_data -maps to -.IR zmq:msg-init-data - -.IR ZMQ_PUB -maps to -.IR zmq:pub - -To learn about individual functions and parameters check -appropriate C API manual pages. - -For example, to understand -.IR zmq:setsockopt -function check -.BR zmq_setsockopt(3) . - -.SH Data structures -Data structures are wrapped into CLOS classes with automatic memory -management. 0MQ describes two such structures: -.IR msg_t -and -.IR pollitem_t . - -Message constructor supports keywords -.IR :size -and -.IR :data. -Keyword :size specifies the size of -message. Keyword :data specifies initial contents of message, and it -can be either string or 8-bit array. For example: - -* (make-instance 'zmq:msg :data #(1 2 3)) - -creates a message with 3 bytes '1, 2, 3' in it. - -.SH Accessing message data - -There 3 functions to read message body in different forms: -msg-data-as-string, msg-data-as-array and msg-data-as-is, returning -data as string, as array and as raw foreign pointer to underlaying -buffer respectively. For example: - -* (zmq:msg-data-as-array msg) - -returns #(1 2 3) for message from previous example. - -It is possible to access underlying foreign object via class slot -named `raw'. - -* (slot-value obj 'zmq:raw) - -or, if `obj' is of known type `msg': - -* (zmq:msg-raw obj) - -.SH Macros -There are several macroses to help with managing zeromq objects: - -.SH with-context -Macro -.IR with-context -creates 0MQ context and requires 3 obligatory arguments: context name, -number of application threads and number of input/output -threads. Optional parameter `flags' can be also supplied, see -.BR zmq_init(3) . -Context is terminated implicitly at the end of macro block. - -.SH with-socket -Macro -.IR with-socket -creates 0MQ socket within given context. Requires 3 arguments: socket -name, context name and socket type. See -.BR zmq_socket(3) . -Socket is closed implicitly at the end of macro block. - -.SH with-polls -Macro -.IR with-polls -creates 0MQ polls, containing different sets of pollitems. For -example, to create two poll sets for network pipes: - -* (zmq:with-polls ((poll1 . ((sock1 . zmq:pollin) - (sock2 . zmq:pollout))) - (poll2 . ((sock1 . zmq:pollout) - (sock2 . zmq:pollin)))) - - (process-sockets (zmq:poll poll-set1)) - - (process-sockets (zmq:poll poll-set2))) - -Note, -.IR zmq:poll -returns list of revents for sockets from given poll set. - -Polls are closed implicitly at the end of macro block. - -.SH EXAMPLE -.nf - -(zmq::with-context (ctx 1 1) - (zmq:with-socket (s ctx zmq:pub) - (zmq:connect s "tcp://192.168.0.115:5555") - (zmq:send s (make-instance 'zmq:msg :data "Hello, world!")))) - -.SH "SEE ALSO" -.BR zmq(7) -.SH AUTHOR -Martin Sustrik <sustrik at 250bpm dot com>, -Vitaly Mayatskikh <v dot mayatskih at gmail dot com> diff --git a/man/man7/zmq_cpp.7 b/man/man7/zmq_cpp.7 deleted file mode 100644 index e3324ba..0000000 --- a/man/man7/zmq_cpp.7 +++ /dev/null @@ -1,103 +0,0 @@ -.TH zmq_cpp 7 "" "(c)2007-2010 iMatix Corporation" "0MQ User Manuals" -.SH NAME -0MQ C++ API \- interface between 0MQ and C++ applications -.SH SYNOPSIS - -This manual page explains how C++ API maps to underlying C API. To learn about -individual functions and parameters check appropriate C API manual -pages. - -For example, to understand -.IR zmq::socket_t::setsockopt -function check -.BR zmq_setsockopt(3) . - -All 0MQ constants defined with C API are available with C++ API. - -.SH zmq::context_t - -This class encapsulates the functions dealing with initialisation and -termination of 0MQ context. Constructor of the class invokes -.BR zmq_init(3) -while destructor calls -.BR zmq_term(3) . - -.SH zmq::socket_t - -This class encapsulates all the functions to deal with 0MQ sockets. Constructor -calls -.BR zmq_socket(3) , -destructor calls -.BR zmq_close(3) . -Other functions of the class are mapped to C functions with corresponding names. -.IR zmq::socket_t::bind -calls -.BR zmq_bind(3) -etc. - -.SH zmq::message_t - -This class encapsulates -.IR zmq_msg_t -structure and all the C functions that deal with 0MQ messages. -Constructors of the class invoke corresponding initialisation functions ( -.BR zmq_msg_init(3) , -.BR zmq_msg_init_size(3) -and -.BR zmq_msg_init_data(3) , -while destructor invokes -.BR zmq_msg_close(3) -function. - -Remaining functions are mapped to C functions with corresponding names. -For instance, -.IR zmq::message_t::copy -is mapped to -.BR zmq_msg_copy(3) -etc. - -C++ provides an additional function not available with C API. -.IR zmq::message_t::rebuild -is equivalent to calling -.BR zmq_close(3) -followed by -.BR zmq_msg_init(3) , -.BR zmq_msg_init_size (3) -or -.BR zmq_msg_init_data(3) . -It provides a way to reuse existing -.IR zmq::message_t -instances to store different message content. - -.SH zmq::error_t - -All the errors reported using -.IR errno -mechanism in C API are automatically converted to exceptions in C++ API. -.IR zmq::error_t -is derived from -.IR std::exception -and uses -.BR zmq_strerror(3) -function to convert the error code to human-readable string. - -.SH zmq::poll - -.IR zmq::poll -function is a namespaced equivalent of raw C -.BR zmq_poll(3) -function. - -.SH EXAMPLE -.nf -zmq::context_t ctx (1, 1); -zmq::socket_t s (ctx, ZMQ_PUB); -s.connect ("tcp://192.168.0.115:5555"); -zmq::message_t msg (100); -memset (msg.data (), 0, 100); -s.send (msg); -.fi -.SH "SEE ALSO" -.BR zmq(7) -.SH AUTHOR -Martin Sustrik <sustrik at 250bpm dot com> diff --git a/man/man7/zmq_inproc.7 b/man/man7/zmq_inproc.7 deleted file mode 100644 index 279d9b5..0000000 --- a/man/man7/zmq_inproc.7 +++ /dev/null @@ -1,42 +0,0 @@ -.TH zmq_inproc 7 "" "(c)2007-2010 iMatix Corporation" "0MQ User Manuals" -.SH NAME -0MQ In-process Transport \- transport to pass messages between threads -.SH SYNOPSIS - -In-process transport is optimised for passing messages between threads in the -same process. - -Messages are passed directly from one application thread to -another application thread. There are no intervening I/O threads involved. -Thus, if you are using 0MQ for in-process messaging only, you can initialise -the library ( -.IR zmq_init -) with zero I/O worker threads. - -.SH CONNECTION STRING - -Connection string for inproc transport is "inproc://" followed by an arbitrary -string. There are no restrictions on the string format: - -.nf - inproc://my_endpoint - inproc://feeds/opra/cboe - inproc://feeds.opra.nasdaq - inproc://!&W#($)_@_123*((^^^ -.fi - -.SH WIRE FORMAT - -In-process transport transfers messages via memory thus there is no need for a -wire format specification. - -.SH "SEE ALSO" - -.BR zmq_ipc (7) -.BR zmq_tcp (7) -.BR zmq_udp (7) -.BR zmq_pgm (7) - -.SH AUTHOR -Martin Sustrik <sustrik at 250bpm dot com> - diff --git a/man/man7/zmq_ipc.7 b/man/man7/zmq_ipc.7 deleted file mode 100644 index b8c08e5..0000000 --- a/man/man7/zmq_ipc.7 +++ /dev/null @@ -1,34 +0,0 @@ -.TH zmq_ipc 7 "" "(c)2007-2010 iMatix Corporation" "0MQ User Manuals" -.SH NAME -0MQ IPC Transport \- transport to pass messages between processes -.SH SYNOPSIS - -Inter-process transport is optimised for passing messages between processes on -the same physical machine. - -.SH CONNECTION STRING - -Connection string for inproc transport is "ipc://" followed by a file name. -The file will be used as placeholder for a message endpoint. (UNIX domain -sockets associate a file with the listening socket in a similar way.) - -.nf - ipc:///tmp/my_ipc_endpoint - ipc:///tmp/prices.ipc -.fi - -.SH WIRE FORMAT - -IPC transport doesn't transfer messages across the network thus there is no need -for a wire format specification. - -.SH "SEE ALSO" - -.BR zmq_inproc (7) -.BR zmq_tcp (7) -.BR zmq_udp (7) -.BR zmq_pgm (7) - -.SH AUTHOR -Martin Sustrik <sustrik at 250bpm dot com> - diff --git a/man/man7/zmq_java.7 b/man/man7/zmq_java.7 deleted file mode 100644 index dd0242f..0000000 --- a/man/man7/zmq_java.7 +++ /dev/null @@ -1,9 +0,0 @@ -.TH zmq_java 7 "" "(c)2007-2010 iMatix Corporation" "0MQ User Manuals" -.SH NAME -0MQ Java API \- interface between 0MQ and Java applications -.SH SYNOPSIS -.SH DESCRIPTION -.SH "SEE ALSO" -.SH AUTHOR -Martin Sustrik <sustrik at 250bpm dot com> - diff --git a/man/man7/zmq_pgm.7 b/man/man7/zmq_pgm.7 deleted file mode 100644 index e1230ae..0000000 --- a/man/man7/zmq_pgm.7 +++ /dev/null @@ -1,98 +0,0 @@ -.TH zmq_pgm 7 "" "(c)2007-2010 iMatix Corporation" "0MQ User Manuals" -.SH NAME -0MQ PGM Transport \- reliable multicast transport -.SH SYNOPSIS - -PGM is a protocol for reliable multicast (RFC3208). 0MQ's PGM transport allows -you to deliver messages to multiple destinations sending the data over -the network once only. It makes sense to use PGM transport if the data, -delivered to each destination separately, would seriously load or even overload -the network. - -PGM sending is rate limited rather than controlled by receivers. Thus, to get -optimal performance you should set ZMQ_RATE and ZMQ_RECOVERY_IVL socket options -prior to using PGM transport. Also note that passing multicast packets via -loopback interface has negative effect on the overall performance of the system. -Thus, if not needed, you should turn multicast loopback off using ZMQ_MCAST_LOOP -socket option. - -PGM transport can be used only with ZMQ_PUB and ZMQ_SUB sockets. - -Caution: PGM protocol runs directly on top of IP protocol and thus needs to -open raw IP socket. On some operating systems this operation requires special -privileges. On Linux, for example, you would need to either run your application -as root or set adequate capabilities for your executable. Alternative approach -is to use UDP transport, -.IR zmq_udp(7) , -that stacks PGM on top of UDP and thus needs no special privileges. - -.SH CONNECTION STRING - -Connection string for PGM transport is "pgm://" followed by an IP address -of the NIC to use, semicolon, IP address of the multicast group, colon and -port number. IP address of the NIC can be either its numeric representation -or the name of the NIC as reported by operating system. IP address of the -multicast group should be specified in the numeric representation. For example: - -.nf - pgm://eth0;224.0.0.1:5555 - pgm://lo;230.0.0.0:6666 - pgm://192.168.0.111;224.0.0.1:5555 -.fi - -Note that NIC names are not standardised by POSIX. They tend to be rather -arbitrary and platform dependent. Say, "eth0" on Linux would correspond to "en0" -on OSX and "e1000g" on Solaris. On Windows platform, as there are no short NIC -names available, you have to use numeric IP addresses instead. - -.SH WIRE FORMAT - -Consecutive PGM packets are interpreted as a single continuous stream of data. -The data is then split into messages using the wire format described in -.IR zmq_tcp(7) . -Thus, messages are not aligned with packet boundaries and each message can start -at an arbitrary position within the packet and span several packets. - -Given this wire format, it would be impossible for late joining consumers to -identify message boundaries. To solve this problem, each PGM packet payload -starts with 16-bit unsigned integer in network byte order which specifies the -offset of the first message in the packet. If there's no beginning of a message -in the packet (it's a packet transferring inner part of a larger message) -the value of the initial integer is 0xFFFF. - -Each packet thus looks like this: - -.nf -+-----------+------------+------------------+-------- -| IP header | PGM header | offset (16 bits) | data ..... -+-----------+------------+------------------+-------- -.fi - -Following example shows how messages are arranged in subsequent packets: - -.nf -+---------------+--------+-----------+-----------------------------+ -| PGM/IPheaders | 0x0000 | message 1 | message 2 (part 1) | -+---------------+--------+-----------+-----------------------------+ - -+---------------+--------+-----------------------------------------+ -| PGM/IPheaders | 0xFFFF | message 2 (part 2) | -+---------------+--------+-----------------------------------------+ - -+---------------+--------+--------------------------+-----------+ -| PGM/IPheaders | 0x0008 | message 2 (last 8 bytes) | message 3 | -+---------------+--------+--------------------------+-----------+ -.fi - -.SH "SEE ALSO" - -.BR zmq_udp (7) -.BR zmq_tcp (7) -.BR zmq_ipc (7) -.BR zmq_inproc (7) -.BR zmq_setsockopt (3) - -.SH AUTHOR -Martin Sustrik <sustrik at 250bpm dot com> - - diff --git a/man/man7/zmq_python.7 b/man/man7/zmq_python.7 deleted file mode 100644 index 45a3cfe..0000000 --- a/man/man7/zmq_python.7 +++ /dev/null @@ -1,9 +0,0 @@ -.TH zmq_python 7 "" "(c)2007-2010 iMatix Corporation" "0MQ User Manuals" -.SH NAME -0MQ Python API \- interface between 0MQ and Python applications -.SH SYNOPSIS -.SH DESCRIPTION -.SH "SEE ALSO" -.SH AUTHOR -Martin Sustrik <sustrik at 250bpm dot com> - diff --git a/man/man7/zmq_tcp.7 b/man/man7/zmq_tcp.7 deleted file mode 100644 index 23c736b..0000000 --- a/man/man7/zmq_tcp.7 +++ /dev/null @@ -1,80 +0,0 @@ -.TH zmq_tcp 7 "" "(c)2007-2010 iMatix Corporation" "0MQ User Manuals" -.SH NAME -0MQ TCP Transport \- unicast transport over the network -.SH SYNOPSIS - -TCP is an ubiquitous unicast transport. When connecting distributed -applications, you will mostly use TCP transport. - -.SH CONNECTION STRING - -Connection string for TCP transport is "tcp://" followed by an IP address, -colon and port number. IP address can be either its numeric representation, -a NIC name or a hostname (resolved by DNS): - -.nf - tcp://192.168.0.111:5555 - tcp://myserver001:80 - tcp://lo:32768 -.fi - -Note that NIC names are not standardised by POSIX. They tend to be rather -arbitrary and platform dependent. Say, "eth0" on Linux would correspond to "en0" -on OSX and "e1000g" on Solaris. On Windows platform, as there are no short NIC -names available, you have to use numeric IP addresses instead. - -.SH WIRE FORMAT - -A message consists of a message length followed by message data. -Size of message data MUST correspond to the message length. - -For messages of 0 to 254 octets, the length is represented by single octet. - -For messages of 255 or more octets the length is represented by a single octet -%xFF followed by a 64-bit unsigned integer length in network byte order. - -The protocol can be defined by this BNF grammar: - -.nf - frame = length data - length = OCTET | escape 8*OCTET - escape = %xFF - data = *OCTET -.fi - -Binary layout of a message (up to 254 bytes long): - -.nf -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 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Message size | Message body ... | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Message body ... -+-+-+-+-+-+-+- ... - -Binary layout of a larger message: - -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 | Message size ... | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Message size ... | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Message size | Message body ... | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Message body ... -+-+-+-+-+-+-+-+ ... -.fi - -.SH "SEE ALSO" - -.BR zmq_udp (7) -.BR zmq_pgm (7) -.BR zmq_ipc (7) -.BR zmq_inproc (7) - -.SH AUTHOR -Martin Sustrik <sustrik at 250bpm dot com> - diff --git a/man/man7/zmq_udp.7 b/man/man7/zmq_udp.7 deleted file mode 100644 index 5b9e6e1..0000000 --- a/man/man7/zmq_udp.7 +++ /dev/null @@ -1,45 +0,0 @@ -.TH zmq_udp 7 "" "(c)2007-2010 iMatix Corporation" "0MQ User Manuals" -.SH NAME -0MQ UDP Transport \- reliable multicast transport -.SH SYNOPSIS - -UDP transport is exactly the same as PGM transport except that PGM packets -are encapsulated in UDP packets. Rationale for this transport is that user-space -implementation of PGM requires right to create raw sockets (PGM is located -directly on top of IP layer in the networking stack), which is often not -available. UDP encapsulation solves this problem, however, it adds some overhead -related to creating and transferring UDP packet headers. - -.SH CONNECTION STRING - -Connection string for UDP transport is "udp://" followed by an IP address -of the NIC to use, semicolon, IP address of the multicast group, colon and -port number. IP address of the NIC can be either its numeric representation -or the name of the NIC as reported by operating system. IP address of the -multicast group should be specified in the numeric representation. For example: - -.nf - udp://eth0;224.0.0.1:5555 - udp://lo;230.0.0.0:6666 - udp://192.168.0.111;224.0.0.1:5555 -.fi - -Note that NIC names are not standardised by POSIX. They tend to be rather -arbitrary and platform dependent. Say, "eth0" on Linux would correspond to "en0" -on OSX and "e1000g" on Solaris. On Windows platform, as there are no short NIC -names available, you have to use numeric IP addresses instead. - -.SH WIRE FORMAT - -Same as with PGM transport except for UDP packet headers. - -.SH "SEE ALSO" - -.BR zmq_pgm (7) -.BR zmq_tcp (7) -.BR zmq_ipc (7) -.BR zmq_inproc (7) - -.SH AUTHOR -Martin Sustrik <sustrik at 250bpm dot com> - |