mirror of
https://github.com/zeromq/libzmq.git
synced 2024-12-26 23:01:04 +08:00
typos in man pages fixed
This commit is contained in:
parent
bddff50271
commit
4ceb839350
13
.gitignore
vendored
13
.gitignore
vendored
@ -16,3 +16,16 @@ autom4te.cache
|
||||
.*
|
||||
src/platform.hpp
|
||||
src/stamp-h1
|
||||
devices/zmq_forwarder/zmq_forwarder
|
||||
devices/zmq_queue/zmq_queue
|
||||
devices/zmq_streamer/zmq_streamer
|
||||
examples/chat/display
|
||||
examples/chat/prompt
|
||||
perf/c/local_lat
|
||||
perf/c/local_thr
|
||||
perf/c/remote_lat
|
||||
perf/c/remote_thr
|
||||
perf/cpp/local_lat
|
||||
perf/cpp/local_thr
|
||||
perf/cpp/remote_lat
|
||||
perf/cpp/remote_thr
|
||||
|
@ -8,7 +8,7 @@ The function binds socket
|
||||
.IR s
|
||||
to a particular transport. Actual semantics of the
|
||||
command depend on the underlying transport mechanism, however, in cases where
|
||||
peers connect in an asymetric manner,
|
||||
peers connect in an asymmetric manner,
|
||||
.IR zmq_bind
|
||||
should be called first,
|
||||
.IR zmq_connect
|
||||
|
@ -9,7 +9,7 @@ The function connect socket
|
||||
to the peer identified by
|
||||
.IR addr .
|
||||
Actual semantics of the command depend on the underlying transport mechanism,
|
||||
however, in cases where peers connect in an asymetric manner,
|
||||
however, in cases where peers connect in an asymmetric manner,
|
||||
.IR zmq_bind
|
||||
should be called first,
|
||||
.IR zmq_connect
|
||||
|
@ -33,7 +33,7 @@ it's a non-blocking receive and there's no message available at the moment.
|
||||
function isn't supported by particular socket type.
|
||||
.IP "\fBEFSM\fP"
|
||||
function cannot be called at the moment, because socket is not in the
|
||||
approprite state. This error may occur with sockets that switch between
|
||||
appropriate state. This error may occur with sockets that switch between
|
||||
several states (e.g. ZMQ_REQ).
|
||||
.SH EXAMPLE
|
||||
.nf
|
||||
|
@ -41,7 +41,7 @@ it's a non-blocking send and message cannot be sent at the moment.
|
||||
function isn't supported by particular socket type.
|
||||
.IP "\fBEFSM\fP"
|
||||
function cannot be called at the moment, because socket is not in the
|
||||
approprite state. This error may occur with sockets that switch between
|
||||
appropriate state. This error may occur with sockets that switch between
|
||||
several states (e.g. ZMQ_REQ).
|
||||
.SH EXAMPLE
|
||||
.nf
|
||||
|
@ -21,7 +21,7 @@ single bind. There's no message routing or message filtering involved.
|
||||
Compatible peer sockets: ZMQ_P2P.
|
||||
|
||||
.IP "\fBZMQ_PUB\fP"
|
||||
Socket to distribute data. Recv fuction is not implemented for this socket
|
||||
Socket to distribute data. Recv function is not implemented for this socket
|
||||
type. Messages are distributed in fanout fashion to all the peers.
|
||||
|
||||
Compatible peer sockets: ZMQ_SUB.
|
||||
@ -50,7 +50,7 @@ Compatible peer sockets: ZMQ_REQ, ZMQ_XREQ.
|
||||
.IP "\fBZMQ_XREQ\fP"
|
||||
Special socket type to be used in request/reply middleboxes such as
|
||||
.BR zmq_queue(7) .
|
||||
Requests forwarded using this socket type should be tagged by a proper postix
|
||||
Requests forwarded using this socket type should be tagged by a proper prefix
|
||||
identifying the original requester. Replies received by this socket are tagged
|
||||
with a proper postfix that can be use to route the reply back to the original
|
||||
requester.
|
||||
@ -60,9 +60,9 @@ Compatible peer sockets: ZMQ_REP, ZMQ_XREP.
|
||||
.IP "\fBZMQ_XREP\fP"
|
||||
Special socket type to be used in request/reply middleboxes such as
|
||||
.BR zmq_queue(7) .
|
||||
Requests received using this socket are already properly tagged with postfix
|
||||
Requests received using this socket are already properly tagged with prefix
|
||||
identifying the original requester. When sending a reply via XREP socket the
|
||||
message should be tagged with a postfix from a corresponding request.
|
||||
message should be tagged with a prefix from a corresponding request.
|
||||
|
||||
Compatible peer sockets: ZMQ_REQ, ZMQ_XREQ.
|
||||
|
||||
|
@ -16,7 +16,7 @@ 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
|
||||
datacenters.
|
||||
data centers.
|
||||
|
||||
0MQ runs on a wide range of operating systems and supports variety of processor
|
||||
microarchitectures.
|
||||
@ -92,7 +92,7 @@ Poll for I/O events:
|
||||
.BR zmq_poll(3)
|
||||
|
||||
.SH ERROR HANDLING
|
||||
0MQ defines couple of non-POSIX error codes. Use following fuctions to handle
|
||||
0MQ defines couple of non-POSIX error codes. Use following functions to handle
|
||||
them neatly.
|
||||
|
||||
Convert error code into human readable string:
|
||||
|
@ -56,7 +56,7 @@ is mapped to
|
||||
.BR zmq_msg_copy(3)
|
||||
etc.
|
||||
|
||||
C++ provides an additional function not avialable with C API.
|
||||
C++ provides an additional function not available with C API.
|
||||
.IR zmq::message_t::rebuild
|
||||
is equivalent to calling
|
||||
.BR zmq_close(3)
|
||||
|
@ -1,6 +1,6 @@
|
||||
.TH zmq_inproc 7 "" "(c)2007-2010 iMatix Corporation" "0MQ User Manuals"
|
||||
.SH NAME
|
||||
In-process (inter-thread) tranport for 0MQ
|
||||
In-process (inter-thread) transport for 0MQ
|
||||
.SH SYNOPSIS
|
||||
|
||||
In-process transport is optimised for passing messages between threads in the
|
||||
|
@ -1,14 +1,14 @@
|
||||
.TH zmq_ipc 7 "" "(c)2007-2010 iMatix Corporation" "0MQ User Manuals"
|
||||
.SH NAME
|
||||
Inter-process tranport for 0MQ
|
||||
Inter-process transport for 0MQ
|
||||
.SH SYNOPSIS
|
||||
|
||||
In-process transport is optimised for passing messages between processes on the
|
||||
same physical machine.
|
||||
Inter-process transport is optimised for passing messages between processes on
|
||||
the same physical machine.
|
||||
|
||||
.SH CONNECTION STRING
|
||||
|
||||
Connection string for inproc transport is "inproc://" followed by a file name.
|
||||
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.)
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
.TH zmq_pgm 7 "" "(c)2007-2010 iMatix Corporation" "0MQ User Manuals"
|
||||
.SH NAME
|
||||
PGM-based tranport for 0MQ
|
||||
PGM-based transport for 0MQ
|
||||
.SH SYNOPSIS
|
||||
|
||||
PGM is a protocol for reliable multicast (RFC3208). 0MQ's PGM transport allows
|
||||
@ -20,11 +20,11 @@ PGM transport can be used only with ZMQ_PUB and ZMQ_SUB sockets.
|
||||
|
||||
.SH CONNECTION STRING
|
||||
|
||||
Connection string for PGM transport is "pgm://" followed by an IP adress
|
||||
of the NIC to use, semicolon, IP adress of the multicast group, colon and
|
||||
port numbrt. IP address of the NIC can be either its numeric representation
|
||||
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
|
||||
mutlicast group should be specified in the numeric representation. For example:
|
||||
multicast group should be specified in the numeric representation. For example:
|
||||
|
||||
.nf
|
||||
pgm://eth0:224.0.0.1:5555
|
||||
|
@ -1,6 +1,6 @@
|
||||
.TH zmq_tcp 7 "" "(c)2007-2010 iMatix Corporation" "0MQ User Manuals"
|
||||
.SH NAME
|
||||
TCP-based tranport for 0MQ
|
||||
TCP-based transport for 0MQ
|
||||
.SH SYNOPSIS
|
||||
|
||||
TCP is an ubiquitous unicast transport. When connecting distributed
|
||||
@ -8,7 +8,7 @@ applications, you will mostly use TCP transport.
|
||||
|
||||
.SH CONNECTION STRING
|
||||
|
||||
Connection string for TCP transport is "tcp://" followed by an IP adress,
|
||||
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):
|
||||
|
||||
|
@ -1,22 +1,22 @@
|
||||
.TH zmq_udp 7 "" "(c)2007-2010 iMatix Corporation" "0MQ User Manuals"
|
||||
.SH NAME
|
||||
UDP-based tranport for 0MQ
|
||||
UDP-based transport for 0MQ
|
||||
.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 netwroking stack), which is often not
|
||||
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 adress
|
||||
of the NIC to use, semicolon, IP adress of the multicast group, colon and
|
||||
port numbrt. IP address of the NIC can be either its numeric representation
|
||||
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
|
||||
mutlicast group should be specified in the numeric representation. For example:
|
||||
multicast group should be specified in the numeric representation. For example:
|
||||
|
||||
.nf
|
||||
udp://eth0:224.0.0.1:5555
|
||||
|
Loading…
x
Reference in New Issue
Block a user