Fix typos

doc/zmq_disconnect.txt

@@ -19,7 +19,7 @@ by the 'socket' argument from the endpoint specified by the 'endpoint'
 argument. Note the actual disconnect system call might occur at a later time.
 
 Upon disconnection the will also stop receiving messages originating from
-this endpoint. Moreover, the socket will no longuer be able
+this endpoint. Moreover, the socket will no longer be able
 to queue outgoing messages to this endpoint. The outgoing message queue
 associated with the endpoint will be discarded. However, if the socket's linger
 period is non-zero, libzmq will still attempt to transmit these discarded messages,

doc/zmq_getsockopt.txt

@@ -624,7 +624,7 @@ ZMQ_RECONNECT_IVL_MAX: Retrieve maximum reconnection interval
 The 'ZMQ_RECONNECT_IVL_MAX' option shall retrieve the maximum reconnection
 interval for the specified 'socket'.  This is the maximum period 0MQ shall wait
 between attempts to reconnect. On each reconnect attempt, the previous interval
-shall be doubled untill ZMQ_RECONNECT_IVL_MAX is reached. This allows for
+shall be doubled until ZMQ_RECONNECT_IVL_MAX is reached. This allows for
 exponential backoff strategy. Default value means no exponential backoff is
 performed and reconnect interval calculations are only based on
 ZMQ_RECONNECT_IVL.

doc/zmq_pgm.txt

@@ -134,7 +134,7 @@ CONFIGURATION
 -------------
 
 The PGM is protocol is capable of multicasting data at high rates (500Mbps+)
-with large messages (1MB+), however it requires setting the relevent ZMQ socket
+with large messages (1MB+), however it requires setting the relevant ZMQ socket
 options that are documented in linkzmq:zmq_setsockopt[3]:
 
 * The 'ZMQ_RATE' should be set sufficiently high, e.g. 1Gbps

doc/zmq_poll.txt

@@ -71,7 +71,7 @@ _zmq_poll()_.
 
 *ZMQ_POLLPRI*::
 For 0MQ sockets this flags is of no use. For standard sockets this means there
-is urgent data to read. Refer to the POLLPRI flag for more informations.
+is urgent data to read. Refer to the POLLPRI flag for more information.
 For file descriptor, refer to your use case: as an example, GPIO interrupts
 are signaled through a POLLPRI event.
 This flag has no effect on Windows.
@@ -86,7 +86,7 @@ The *zmq_pollitem_t* array must only be used by the thread which
 will/is calling _zmq_poll_.
 
 If a socket is contained in multiple *zmq_pollitem_t* arrays, each owned by a
-different thread, the socket itself needs to be thead-safe (Server, Client, ...).
+different thread, the socket itself needs to be thread-safe (Server, Client, ...).
 Otherwise, behaviour is undefined.
 
 

doc/zmq_poller.txt

@@ -91,7 +91,7 @@ associated with the socket registration, and requires that the _socket_
 remains valid.
 
 _zmq_poller_add_fd_, _zmq_poller_modify_fd_ and _zmq_poller_remove_fd_ are
-analogous to the previous functions but manage regular file descriptiors
+analogous to the previous functions but manage regular file descriptors
 registered with a poller. On Windows, these functions can only be used with
 WinSock sockets.
 
@@ -185,7 +185,7 @@ For 0MQ sockets this flag has no effect on the _zmq_poller_add_ and
 _zmq_poller_modify_ functions, and is never set in the
 'events' member of the zmq_poller_event_t structure.
 For standard sockets this means there
-is urgent data to read. Refer to the POLLPRI flag for more informations.
+is urgent data to read. Refer to the POLLPRI flag for more information.
 For a file descriptor, refer to your OS documentation: as an example, GPIO
 interrupts are signaled through a POLLPRI event.
 This flag has no effect on Windows.

doc/zmq_setsockopt.txt

@@ -257,7 +257,7 @@ Default value:: NULL
 Applicable socket types:: ZMQ_ROUTER, ZMQ_SERVER and ZMQ_PEER
 
 
-ZMQ_HICCUP_MSG: set a hiccup message that the socket will generate when connected peer temporarly disconnect
+ZMQ_HICCUP_MSG: set a hiccup message that the socket will generate when connected peer temporarily disconnect
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 When set, the socket will generate a hiccup message when connect peer has been disconnected.
 You may set this on DEALER, CLIENT and PEER sockets.
@@ -527,9 +527,9 @@ ZMQ_METADATA: Add application metadata properties to a socket
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 The _ZMQ_METADATA_ option shall add application metadata to the specified _socket_,
 the metadata is exchanged with peers during connection setup. A metadata property is
-specfied as a string, delimited by a colon, starting with the metadata _property_
+specified as a string, delimited by a colon, starting with the metadata _property_
 followed by the metadata value, for example "X-key:value".
-_Property_ names are restrited to maximum 255 characters and must be prefixed by "X-".
+_Property_ names are restricted to maximum 255 characters and must be prefixed by "X-".
 Multiple application metadata properties can be added to a socket by executing zmq_setsockopt()
 multiple times. As the argument is a null-terminated string, binary data must be encoded
 before it is added e.g. using Z85 (linkzmq:zmq_z85_encode[3]).
@@ -755,7 +755,7 @@ ZMQ_RECONNECT_IVL_MAX: Set maximum reconnection interval
 The 'ZMQ_RECONNECT_IVL_MAX' option shall set the maximum reconnection interval
 for the specified 'socket'.  This is the maximum period 0MQ shall wait between
 attempts to reconnect. On each reconnect attempt, the previous interval shall be
-doubled untill ZMQ_RECONNECT_IVL_MAX is reached. This allows for exponential
+doubled until ZMQ_RECONNECT_IVL_MAX is reached. This allows for exponential
 backoff strategy. Default value means no exponential backoff is performed and
 reconnect interval calculations are only based on ZMQ_RECONNECT_IVL.
 
@@ -1238,7 +1238,7 @@ Applicable socket types:: ZMQ_XPUB, ZMQ_PUB
 
 ZMQ_XPUB_WELCOME_MSG: set welcome message that will be received by subscriber when connecting
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Sets a welcome message the will be recieved by subscriber when connecting.
+Sets a welcome message the will be received by subscriber when connecting.
 Subscriber must subscribe to the Welcome message before connecting.
 Welcome message will also be sent on reconnecting.
 For welcome message to work well user must poll on incoming subscription messages on the XPUB socket and handle them.

doc/zmq_tcp.txt

@@ -76,7 +76,7 @@ HWM
 For the TCP transport, the high water mark (HWM) mechanism works in conjunction
 with the TCP socket buffers handled at OS level.
 Depending on the OS and several other factors the size of such TCP buffers will
-be different. Moreover TCP buffers provided by the OS will accomodate a varying
+be different. Moreover TCP buffers provided by the OS will accommodate a varying
 number of messages depending on the size of messages (unlike ZMQ HWM settings
 the TCP socket buffers are measured in bytes and not messages).
 

doc/zmq_unbind.txt

@@ -18,7 +18,7 @@ The _zmq_unbind()_ function shall unbind a socket specified
 by the 'socket' argument from the endpoint specified by the 'endpoint'
 argument. 
 
-Addionally the incoming message queue associated with the endpoint will be
+Additionally the incoming message queue associated with the endpoint will be
 discarded. This means that after unbinding an endpoint it is possible to
 received messages originating from that same endpoint if they were already
 present in the incoming message queue before unbinding.