From c35b00cd6cda54cf89ab331725b8681c2f497c91 Mon Sep 17 00:00:00 2001 From: Bruce Mitchener Date: Wed, 20 Aug 2014 18:43:45 +0700 Subject: [PATCH] Fix many typos. --- doc/nn_cmsg.txt | 2 +- doc/nn_poll.txt | 2 +- doc/nn_pubsub.txt | 2 +- doc/nn_symbol_info.txt | 2 +- rfc/sp-protocol-ids-01.txt | 2 +- rfc/sp-protocol-ids-01.xml | 2 +- rfc/sp-publish-subscribe-01.txt | 3 +-- rfc/sp-publish-subscribe-01.xml | 2 +- rfc/sp-request-reply-01.txt | 28 ++++++++++++++-------------- rfc/sp-request-reply-01.xml | 28 ++++++++++++++-------------- rfc/sp-tcp-mapping-01.txt | 6 +++--- rfc/sp-tcp-mapping-01.xml | 8 ++++---- rfc/sp-tls-mapping-01.txt | 4 ++-- rfc/sp-tls-mapping-01.xml | 4 ++-- src/core/sock.c | 2 +- src/nn.h | 2 +- src/protocol.h | 6 +++--- src/protocols/survey/surveyor.c | 2 +- src/protocols/utils/priolist.h | 2 +- src/transports/ipc/sipc.h | 2 +- src/transports/tcp/stcp.h | 2 +- src/transports/utils/streamhdr.h | 2 +- tools/nanocat.c | 2 +- 23 files changed, 58 insertions(+), 59 deletions(-) diff --git a/doc/nn_cmsg.txt b/doc/nn_cmsg.txt index 89e823653..23eb9ad7f 100644 --- a/doc/nn_cmsg.txt +++ b/doc/nn_cmsg.txt @@ -25,7 +25,7 @@ DESCRIPTION These functions can be used to iterate over ancillary data attached to a message. -Structure 'nn_cmsghdr' represents a single anciallary property and contains following members: +Structure 'nn_cmsghdr' represents a single ancillary property and contains following members: size_t cmsg_len; int cmsg_level; diff --git a/doc/nn_poll.txt b/doc/nn_poll.txt index 9ec5b99d2..3a212237d 100644 --- a/doc/nn_poll.txt +++ b/doc/nn_poll.txt @@ -71,7 +71,7 @@ nn_poll is a convenience function. You can achieve same behaviour by using NN_RCVFD and NN_SNDFD socket options. However, using the socket options allows for usage that's not possible with nn_poll, such as simultaneous polling for both SP and OS-level sockets, integration of SP sockets with external event -loops et c. +loops etc. EXAMPLE ------- diff --git a/doc/nn_pubsub.txt b/doc/nn_pubsub.txt index 7eb7083eb..dd585c761 100644 --- a/doc/nn_pubsub.txt +++ b/doc/nn_pubsub.txt @@ -36,7 +36,7 @@ Topic with zero length matches any message. If the socket is subscribed to multiple topics, message matching any of them will be delivered to the user. -The entire message, including the the topic, is delivered to the user. +The entire message, including the topic, is delivered to the user. Socket Types ~~~~~~~~~~~~ diff --git a/doc/nn_symbol_info.txt b/doc/nn_symbol_info.txt index a741fb648..b67ed8f39 100644 --- a/doc/nn_symbol_info.txt +++ b/doc/nn_symbol_info.txt @@ -27,7 +27,7 @@ struct nn_symbol_properties { /* The constant value */ int value; - /* The contant name */ + /* The constant name */ const char* name; /* The constant namespace, or zero for namespaces themselves */ diff --git a/rfc/sp-protocol-ids-01.txt b/rfc/sp-protocol-ids-01.txt index 024f3f04c..2435e1d52 100644 --- a/rfc/sp-protocol-ids-01.txt +++ b/rfc/sp-protocol-ids-01.txt @@ -72,7 +72,7 @@ Internet-Draft List of SP protocol IDs June 2014 Protocol IDs denote the SP protocol used (such as request/reply or publish/subscribe), while endpoint role determines the role of the endpoint within the topology (requester vs. replier, publisher vs. - subscriber et c.) Both numbers are in network byte order. + subscriber etc.) Both numbers are in network byte order. Protocol IDs are global, while endpoint roles are specific to any given protocol. As such, protocol IDs are defined in this document, diff --git a/rfc/sp-protocol-ids-01.xml b/rfc/sp-protocol-ids-01.xml index 736a22e45..064cc160d 100644 --- a/rfc/sp-protocol-ids-01.xml +++ b/rfc/sp-protocol-ids-01.xml @@ -50,7 +50,7 @@ Protocol IDs denote the SP protocol used (such as request/reply or publish/subscribe), while endpoint role determines the role of the endpoint within the topology (requester vs. replier, publisher vs. - subscriber et c.) Both numbers are in network byte order. + subscriber etc.) Both numbers are in network byte order. Protocol IDs are global, while endpoint roles are specific to any given protocol. As such, protocol IDs are defined in this document, while diff --git a/rfc/sp-publish-subscribe-01.txt b/rfc/sp-publish-subscribe-01.txt index de4410d0a..6585b62cd 100644 --- a/rfc/sp-publish-subscribe-01.txt +++ b/rfc/sp-publish-subscribe-01.txt @@ -71,8 +71,7 @@ Internet-Draft Publish/Subscribe SP May 2014 arbitrarily complex topology rather than of a single node-to-node communication, several underlying protocols can be used in parallel. For example, publisher can send a message to intermediary node via - TCP. The intermediate node can then forward the message via PGM et - c. + TCP. The intermediate node can then forward the message via PGM etc. +---+ TCP +---+ PGM +---+ | |----------->| |---------->| | diff --git a/rfc/sp-publish-subscribe-01.xml b/rfc/sp-publish-subscribe-01.xml index 6259d890b..06732acc8 100644 --- a/rfc/sp-publish-subscribe-01.xml +++ b/rfc/sp-publish-subscribe-01.xml @@ -53,7 +53,7 @@ arbitrarily complex topology rather than of a single node-to-node communication, several underlying protocols can be used in parallel. For example, publisher can send a message to intermediary node via TCP. - The intermediate node can then forward the message via PGM et c. + The intermediate node can then forward the message via PGM etc.
diff --git a/rfc/sp-request-reply-01.txt b/rfc/sp-request-reply-01.txt index 5a95faaa2..71664d885 100644 --- a/rfc/sp-request-reply-01.txt +++ b/rfc/sp-request-reply-01.txt @@ -85,7 +85,7 @@ Internet-Draft Request/Reply SP August 2013 no matter what instance of the service have computed it. Service that accepts empty requests and produces the number of - requests processed so far (1, 2, 3 et c.), on the other hand, is not + requests processed so far (1, 2, 3 etc.), on the other hand, is not stateless. To prove it you can run two instances of the service. First reply, no matter which instance produces it is going to be 1. Second reply though is going to be either 2 (if processed by the same @@ -153,7 +153,7 @@ Internet-Draft Request/Reply SP August 2013 "enterprise service bus" model. In the simplest case the bus can be implemented as a simple hub-and-spokes topology. In complex cases the bus can span multiple physical locations or multiple - oraganisations with intermediate nodes at the boundaries + organisations with intermediate nodes at the boundaries connecting different parts of the topology. In addition to distributing tasks to processing nodes, request/reply @@ -183,9 +183,9 @@ Internet-Draft Request/Reply SP August 2013 As can be seen from the above, one request may be processed multiple times. For example, reply may be lost on its way back to the client. Client will assume that the request was not processed yet, it will - resend it and thus cause duplicit execution of the task. + resend it and thus cause duplicate execution of the task. - Some applications may want to prevent duplicit execution of tasks. + Some applications may want to prevent duplicate execution of tasks. It often turns out that hardening such applications to be idempotent is relatively easy as they already possess the tools to do so. For example, a payment processing server already has access to a shared @@ -193,8 +193,8 @@ Internet-Draft Request/Reply SP August 2013 ID was not yet processed. On the other hand, many applications don't care about occasional - duplicitly processed tasks. Therefore, request/reply protocol does - not require the service to be idempotent. Instead, the idempotancy + duplicate processed tasks. Therefore, request/reply protocol does + not require the service to be idempotent. Instead, the idempotence issue is left to the user to decide on. Finally, it should be noted that this specification discusses several @@ -213,7 +213,7 @@ Internet-Draft Request/Reply SP August 2013 communication, several underlying protocols can be used in parallel. For example, a client may send a request via WebSocket, then, on the edge of the company network an intermediary node may retransmit it - using TCP et c. + using TCP etc. @@ -288,14 +288,14 @@ Internet-Draft Request/Reply SP August 2013 Thus, when a node is about to send a request, it can choose to send it only to one of the channels that don't report pushback at the - moment. To implement approximately fair distibution of the workload + moment. To implement approximately fair distribution of the workload the node choses a channel from that pool using the round-robin algorithm. As for delivering replies back to the clients, it should be understood that the client may not be directly accessible (say using TCP/IP) from the processing node. It may be beyond a firewall, have - no static IP address et c. Furthermore, the client and the processing + no static IP address etc. Furthermore, the client and the processing may not even speak the same transport protocol -- imagine client connecting to the topology using WebSockets and processing node via SCTP. @@ -317,7 +317,7 @@ Internet-Draft Request/Reply SP August 2013 The upside, on the other hand, is that the nodes in the topology don't have to maintain any routing tables beside the simple table of - adjacent channels along with thier IDs. There's also no need for any + adjacent channels along with their IDs. There's also no need for any additional protocols for distributing routing information within the topology. @@ -381,7 +381,7 @@ Internet-Draft Request/Reply SP August 2013 tag. That allows the algorithm to find out where the tags end and where the message payload begins. - As for the reamining 31 bits, they are either request ID (in the last + As for the remaining 31 bits, they are either request ID (in the last tag) or a channel ID (in all the remaining tags). The first channel ID is added and processed by the REP endpoint closest to the processing node. The last channel ID is added and processed by the @@ -511,7 +511,7 @@ Internet-Draft Request/Reply SP August 2013 responsive. It can be thought of as a crude scheduling algorithm. However crude though, it's probably still the best you can get without knowing estimates of execution time for individual tasks, CPU - capacity of individual processing nodes et c. + capacity of individual processing nodes etc. Alternatively, backpressure can be thought of as a congestion control mechanism. When all available processing nodes are busy, it slows @@ -694,7 +694,7 @@ Internet-Draft Request/Reply SP August 2013 If the request is successfully sent, the endpoint stores the request including its request ID, so that it can be resent later on if needed. At the same time it sets up a timer to trigger the re- - transimission in case the reply is not received within a specified + transmission in case the reply is not received within a specified timeout. The user MUST be allowed to specify the timeout interval. The default timeout interval must be 60 seconds. @@ -795,7 +795,7 @@ Internet-Draft Request/Reply SP August 2013 legitimate setups can cause loop to be created. With no additional guards against the loops, it's likely that - requests will be caugth inside the loop, rotating there forever, each + requests will be caught inside the loop, rotating there forever, each message gradually growing in size as new prefixes are added to it by each REP endpoint on the way. Eventually, a loop can cause congestion and bring the whole system to a halt. diff --git a/rfc/sp-request-reply-01.xml b/rfc/sp-request-reply-01.xml index d8273f722..b7fcab92f 100644 --- a/rfc/sp-request-reply-01.xml +++ b/rfc/sp-request-reply-01.xml @@ -67,7 +67,7 @@ no matter what instance of the service have computed it. Service that accepts empty requests and produces the number - of requests processed so far (1, 2, 3 et c.), on the other hand, is + of requests processed so far (1, 2, 3 etc.), on the other hand, is not stateless. To prove it you can run two instances of the service. First reply, no matter which instance produces it is going to be 1. Second reply though is going to be either 2 (if processed by the same @@ -123,7 +123,7 @@ The "enterprise service bus" model. In the simplest case the bus can be implemented as a simple hub-and-spokes topology. In complex cases the bus can span multiple physical locations or multiple - oraganisations with intermediate nodes at the boundaries connecting + organisations with intermediate nodes at the boundaries connecting different parts of the topology. @@ -149,9 +149,9 @@ As can be seen from the above, one request may be processed multiple times. For example, reply may be lost on its way back to the client. Client will assume that the request was not processed yet, it will - resend it and thus cause duplicit execution of the task. + resend it and thus cause duplicate execution of the task. - Some applications may want to prevent duplicit execution of tasks. It + Some applications may want to prevent duplicate execution of tasks. It often turns out that hardening such applications to be idempotent is relatively easy as they already possess the tools to do so. For example, a payment processing server already has access to a shared @@ -159,8 +159,8 @@ was not yet processed. On the other hand, many applications don't care about occasional - duplicitly processed tasks. Therefore, request/reply protocol does not - require the service to be idempotent. Instead, the idempotancy issue + duplicate processed tasks. Therefore, request/reply protocol does not + require the service to be idempotent. Instead, the idempotence issue is left to the user to decide on. Finally, it should be noted that this specification discusses several @@ -182,7 +182,7 @@ communication, several underlying protocols can be used in parallel. For example, a client may send a request via WebSocket, then, on the edge of the company network an intermediary node may retransmit it - using TCP et c. + using TCP etc.
@@ -248,14 +248,14 @@ Thus, when a node is about to send a request, it can choose to send it only to one of the channels that don't report pushback at the - moment. To implement approximately fair distibution of the workload + moment. To implement approximately fair distribution of the workload the node choses a channel from that pool using the round-robin algorithm. As for delivering replies back to the clients, it should be understood that the client may not be directly accessible (say using TCP/IP) from the processing node. It may be beyond a firewall, have no static IP - address et c. Furthermore, the client and the processing may not even + address etc. Furthermore, the client and the processing may not even speak the same transport protocol -- imagine client connecting to the topology using WebSockets and processing node via SCTP. @@ -276,7 +276,7 @@ The upside, on the other hand, is that the nodes in the topology don't have to maintain any routing tables beside the simple table of - adjacent channels along with thier IDs. There's also no need for any + adjacent channels along with their IDs. There's also no need for any additional protocols for distributing routing information within the topology. @@ -334,7 +334,7 @@ That allows the algorithm to find out where the tags end and where the message payload begins. - As for the reamining 31 bits, they are either request ID (in the last + As for the remaining 31 bits, they are either request ID (in the last tag) or a channel ID (in all the remaining tags). The first channel ID is added and processed by the REP endpoint closest to the processing node. The last channel ID is added and processed by the REP endpoint @@ -445,7 +445,7 @@ responsive. It can be thought of as a crude scheduling algorithm. However crude though, it's probably still the best you can get without knowing estimates of execution time for individual tasks, - CPU capacity of individual processing nodes et c. + CPU capacity of individual processing nodes etc. Alternatively, backpressure can be thought of as a congestion control mechanism. When all available processing nodes are busy, it slows @@ -613,7 +613,7 @@ If the request is successfully sent, the endpoint stores the request including its request ID, so that it can be resent later on if needed. At the same time it sets up a timer to trigger the - re-transimission in case the reply is not received within a specified + re-transmission in case the reply is not received within a specified timeout. The user MUST be allowed to specify the timeout interval. The default timeout interval must be 60 seconds. @@ -704,7 +704,7 @@ legitimate setups can cause loop to be created. With no additional guards against the loops, it's likely that - requests will be caugth inside the loop, rotating there forever, + requests will be caught inside the loop, rotating there forever, each message gradually growing in size as new prefixes are added to it by each REP endpoint on the way. Eventually, a loop can cause congestion and bring the whole system to a halt. diff --git a/rfc/sp-tcp-mapping-01.txt b/rfc/sp-tcp-mapping-01.txt index 95bb61e7a..4ce2361f6 100644 --- a/rfc/sp-tcp-mapping-01.txt +++ b/rfc/sp-tcp-mapping-01.txt @@ -98,7 +98,7 @@ Internet-Draft TCP mapping for SPs March 2014 The fact that the first byte of the protocol header is binary zero eliminates any text-based protocols that were accidentally connected - to the endpiont. Subsequent two bytes make the check even more + to the endpoint. Subsequent two bytes make the check even more rigorous. At the same time they can be used as a debugging hint to indicate that the connection is supposed to use one of the scalability protocols -- ASCII representation of these bytes is 'SP' @@ -143,7 +143,7 @@ Internet-Draft TCP mapping for SPs March 2014 +------------+-----------------+ It may seem that 64 bit message size is excessive and consumes too - much of valueable bandwidth, especially given that most scenarios + much of valuable bandwidth, especially given that most scenarios call for relatively small messages, in order of bytes or kilobytes. Variable length field may seem like a better solution, however, our @@ -154,7 +154,7 @@ Internet-Draft TCP mapping for SPs March 2014 portion of the message and the performance impact is not even measurable. - For small messages, the overal throughput is heavily CPU-bound, never + For small messages, the overall throughput is heavily CPU-bound, never I/O-bound. In other words, CPU processing associated with each individual message limits the message rate in such a way that network bandwidth limit is never reached. In the future we expect it to be diff --git a/rfc/sp-tcp-mapping-01.xml b/rfc/sp-tcp-mapping-01.xml index d15e2e8d0..06675d0d4 100644 --- a/rfc/sp-tcp-mapping-01.xml +++ b/rfc/sp-tcp-mapping-01.xml @@ -27,7 +27,7 @@ This document defines the TCP mapping for scalability protocols. The main purpose of the mapping is to turn the stream of bytes - into stream of messages. Additionaly, the mapping provides some + into stream of messages. Additionally, the mapping provides some additional checks during the connection establishment phase. @@ -80,7 +80,7 @@ The fact that the first byte of the protocol header is binary zero eliminates any text-based protocols that were accidentally connected - to the endpiont. Subsequent two bytes make the check even more + to the endpoint. Subsequent two bytes make the check even more rigorous. At the same time they can be used as a debugging hint to indicate that the connection is supposed to use one of the scalability protocols -- ASCII representation of these bytes is 'SP' that can @@ -123,7 +123,7 @@
It may seem that 64 bit message size is excessive and consumes too much - of valueable bandwidth, especially given that most scenarios call for + of valuable bandwidth, especially given that most scenarios call for relatively small messages, in order of bytes or kilobytes. Variable length field may seem like a better solution, however, our @@ -133,7 +133,7 @@ For large messages, 64 bits used by the field form a negligible portion of the message and the performance impact is not even measurable. - For small messages, the overal throughput is heavily CPU-bound, never + For small messages, the overall throughput is heavily CPU-bound, never I/O-bound. In other words, CPU processing associated with each individual message limits the message rate in such a way that network bandwidth limit is never reached. In the future we expect it to be diff --git a/rfc/sp-tls-mapping-01.txt b/rfc/sp-tls-mapping-01.txt index fff09f7bc..64b7127f8 100644 --- a/rfc/sp-tls-mapping-01.txt +++ b/rfc/sp-tls-mapping-01.txt @@ -69,7 +69,7 @@ Internet-Draft TLS/TCP mapping for SPs March 2014 details as discussed here. As when running SP over TCP directly, the TCP port number is - determined by the applicaton or user. + determined by the application or user. This mapping follows the details of SP over TCP [SPoverTCP]. @@ -80,7 +80,7 @@ Internet-Draft TLS/TCP mapping for SPs March 2014 of the connection, including negotiation of cipher suites, exchanging keys, and possibly performing one or two-way authentication. - The specific details of the TLS negotiation are determined by the the + The specific details of the TLS negotiation are determined by the application(s) involved, and are not specified here. This includes selection of the specific version of TLS or possibly falling back to SSL version 3 (but not SSL version 1 or 2). diff --git a/rfc/sp-tls-mapping-01.xml b/rfc/sp-tls-mapping-01.xml index 6cbc247c2..0028a3365 100644 --- a/rfc/sp-tls-mapping-01.xml +++ b/rfc/sp-tls-mapping-01.xml @@ -44,7 +44,7 @@ and should follow the same details as discussed here. As when running SP over TCP directly, the TCP port number is - determined by the applicaton or user. + determined by the application or user. This mapping follows the details of SP over TCP. @@ -59,7 +59,7 @@ keys, and possibly performing one or two-way authentication. The specific details of the TLS negotiation are determined by the - the application(s) involved, and are not specified here. This includes + application(s) involved, and are not specified here. This includes selection of the specific version of TLS or possibly falling back to SSL version 3 (but not SSL version 1 or 2). diff --git a/src/core/sock.c b/src/core/sock.c index ec7896e3e..fd4973c55 100644 --- a/src/core/sock.c +++ b/src/core/sock.c @@ -720,7 +720,7 @@ static void nn_sock_onleave (struct nn_ctx *self) if (nn_slow (sock->state != NN_SOCK_STATE_ACTIVE)) return; - /* Check whether socket is readable and/or writeable at the moment. */ + /* Check whether socket is readable and/or writable at the moment. */ events = sock->sockbase->vfptr->events (sock->sockbase); errnum_assert (events >= 0, -events); diff --git a/src/nn.h b/src/nn.h index ca250bcc6..af8b9bff9 100644 --- a/src/nn.h +++ b/src/nn.h @@ -233,7 +233,7 @@ struct nn_symbol_properties { /* The constant value */ int value; - /* The contant name */ + /* The constant name */ const char* name; /* The constant namespace, or zero for namespaces themselves */ diff --git a/src/protocol.h b/src/protocol.h index 38d9b82b4..38db31f7c 100644 --- a/src/protocol.h +++ b/src/protocol.h @@ -98,14 +98,14 @@ struct nn_sockbase_vfptr { to send to or to be received from at the moment. 'rm' unregisters the pipe. The pipe should not be used after this call as it may already be deallocated. 'in' informs the socket that pipe is readable. 'out' - informs it that it is writeable. */ + informs it that it is writable. */ int (*add) (struct nn_sockbase *self, struct nn_pipe *pipe); void (*rm) (struct nn_sockbase *self, struct nn_pipe *pipe); void (*in) (struct nn_sockbase *self, struct nn_pipe *pipe); void (*out) (struct nn_sockbase *self, struct nn_pipe *pipe); /* Return any combination of event flags defined above, thus specifying - whether the socket should be readable, writeable, both or none. */ + whether the socket should be readable, writable, both or none. */ int (*events) (struct nn_sockbase *self); /* Send a message to the socket. Returns -EAGAIN if it cannot be done at @@ -150,7 +150,7 @@ struct nn_ctx *nn_sockbase_getctx (struct nn_sockbase *self); int nn_sockbase_getopt (struct nn_sockbase *self, int option, void *optval, size_t *optvallen); -/* Add some statitistics for socket */ +/* Add some statistics for socket */ void nn_sockbase_stat_increment (struct nn_sockbase *self, int name, int increment); diff --git a/src/protocols/survey/surveyor.c b/src/protocols/survey/surveyor.c index d077857ad..bf3c86ffb 100644 --- a/src/protocols/survey/surveyor.c +++ b/src/protocols/survey/surveyor.c @@ -174,7 +174,7 @@ static int nn_surveyor_events (struct nn_sockbase *self) surveyor = nn_cont (self, struct nn_surveyor, xsurveyor.sockbase); - /* Determine the actual readability/writeability of the socket. */ + /* Determine the actual readability/writability of the socket. */ rc = nn_xsurveyor_events (&surveyor->xsurveyor.sockbase); /* If there's no survey going on we'll signal IN to interrupt polling diff --git a/src/protocols/utils/priolist.h b/src/protocols/utils/priolist.h index bf8e30273..260202df9 100644 --- a/src/protocols/utils/priolist.h +++ b/src/protocols/utils/priolist.h @@ -92,7 +92,7 @@ int nn_priolist_is_active (struct nn_priolist *self); struct nn_pipe *nn_priolist_getpipe (struct nn_priolist *self); /* Moves to the next pipe in the list. If 'release' is set to 1, the current - pipe is removed from the list. To re-insert it into thr list use + pipe is removed from the list. To re-insert it into the list use nn_priolist_activate function. */ void nn_priolist_advance (struct nn_priolist *self, int release); diff --git a/src/transports/ipc/sipc.h b/src/transports/ipc/sipc.h index 2d6d882ea..4090e2d40 100644 --- a/src/transports/ipc/sipc.h +++ b/src/transports/ipc/sipc.h @@ -44,7 +44,7 @@ struct nn_sipc { struct nn_fsm fsm; int state; - /* The undelrying socket. */ + /* The underlying socket. */ struct nn_usock *usock; /* Child state machine to do protocol header exchange. */ diff --git a/src/transports/tcp/stcp.h b/src/transports/tcp/stcp.h index ca6a7c107..a158f03a2 100644 --- a/src/transports/tcp/stcp.h +++ b/src/transports/tcp/stcp.h @@ -44,7 +44,7 @@ struct nn_stcp { struct nn_fsm fsm; int state; - /* The undelrying socket. */ + /* The underlying socket. */ struct nn_usock *usock; /* Child state machine to do protocol header exchange. */ diff --git a/src/transports/utils/streamhdr.h b/src/transports/utils/streamhdr.h index 8680dd1f6..6bd81c077 100644 --- a/src/transports/utils/streamhdr.h +++ b/src/transports/utils/streamhdr.h @@ -47,7 +47,7 @@ struct nn_streamhdr { /* Used to timeout the protocol header exchange. */ struct nn_timer timer; - /* The undelrying socket. */ + /* The underlying socket. */ struct nn_usock *usock; /* The original owner of the underlying socket. */ diff --git a/tools/nanocat.c b/tools/nanocat.c index 0e2ec1bc9..ea8d7dc45 100644 --- a/tools/nanocat.c +++ b/tools/nanocat.c @@ -362,7 +362,7 @@ int nn_create_socket (nn_options_t *options) nn_assert_errno (rc == 0, "Can't set socket name"); } - /* Specific intitalization */ + /* Specific initialization */ switch (options->socket_type) { case NN_SUB: nn_sub_init (options, sock);