Convert documentation to AsciiDoc

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>
-