Merge pull request #4659 from input-output-hk/coot/eyeinksy-doc-review

Documentation review

docs/network-spec/architecture.tex

@@ -32,9 +32,9 @@ \section{Protocols and node design}
 \end{figure}
 
 Figure~\ref{node-diagram-concurrency} illustrates design of a node.  Circles
-represents threads that run one of the mini-protocols.  
+represents threads that run one of the mini-protocols.
 Each mini-protocols communicate with a remote node over the network.
-Threads communicate communicate by means of a shared mutable variables, which
+Threads communicate by means of a shared mutable variables, which
 are represented by boxes in Figure~\ref{node-diagram-concurrency}.
 We heavily use
 \href{https://en.wikipedia.org/wiki/Software_transactional_memory}{Software
@@ -71,7 +71,7 @@ \section{Congestion Control}
 its memory limits, that is there must be defined limits, breaches of which
 being treated like protocol violations.
 
-Of cause it makes no sense if the system design is robust, but so defensive
+Of course it makes no sense if the system design is robust, but so defensive
 that it fails to meet performance goals.  An example would be a protocol that
 never transmits a message unless it has received an explicit ACK for the
 previous message. This approach might avoid overloading the network, but would

docs/network-spec/intro.tex

@@ -601,7 +601,7 @@ \section{Congestion Control}
 In any condition, a node must not exceed its memory limits,
 that is there must be defined limits, breaches of which being treated like protocol violations.
 
-Of cause it makes no sense if the system design is robust,
+Of course it makes no sense if the system design is robust,
 but so defensive that it fails to meet performance goals.
 An example would be a protocol that never transmits a message unless it has received an
 explicit ACK for the previous message. This approach might avoid overloading the network,

docs/network-spec/miniprotocols.tex

@@ -532,7 +532,7 @@ \subsection{Client and Server Implementation}
 \end{description}
 Note that the above condition guarantees that if either side returns
 \texttt{Accept} then the connection will not be closed by the remote end.
-A weaker condition, in which the returns values are equal if they both return
+A weaker condition, in which the return values are equal if they both return
 \texttt{Accept}, does not guarantee this property.  We also verify that the
 whole Handshake protocol, not just the \texttt{acceptable} satisfies the above
 property, see
@@ -673,7 +673,7 @@ \subsection{State Machine}
       shall be ordered by perference (e.g. points with highest slot number
       first) and it is up to the producer to find the first intersection point
       on its chain and send it back to the consumer.  If an empty list of
-      points is send with \MsgFindIntersect{} the server will reply with
+      points is sent with \MsgFindIntersect{} the server will reply with
       \MsgIntersectNotFound{}.
 \item [\MsgIntersectFound{} {\boldmath $(point_{intersect} ,tip)$}]
       The producer replies with the first point of the request that is on his current chain.
@@ -715,7 +715,7 @@ \subsection{Implementation of the Chain Producer}
 \hide{The trade-offs between the robustness and efficiency of possible chain-sync protocols are
 discussed in Section~\ref{chain-sync-discussion}.
 }
-This section describes a state-full implementation of a chain producer that is suitable for a setting where
+This section describes a stateful implementation of a chain producer that is suitable for a setting where
 the producer cannot trust the chain consumer.
 An important requirement in this setting
 is that a chain consumer must never be able to cause excessive resource use on the producer side.

docs/network-spec/mux.tex

@@ -125,8 +125,8 @@ \section{Node-to-node and node-to-client protocol numbers}
 Ouroboros network defines two protocols: \emph{node-to-node} and
 \emph{node-to-client} protocols.  \emph{Node-to-node} is used for inter node
 communication across the Internet, while \emph{node-to-client} is a inter
-process communication, usedy by clients, e.g. a wallet, db-sync, etc.  Each of them consists of a bundle of mini-protocols (see chapter~\ref{chapter:mini-protocols})
-consists of a bundle of mini-protocols.  The protocol numbers of both protocols
+process communication, usedy by clients, e.g. a wallet, db-sync, etc.  Each of them consists of a bundle of mini-protocols (see chapter~\ref{chapter:mini-protocols}).
+The protocol numbers of both protocols
 are specified in tables~\ref{table:node-to-node-protocol-numbers}
 and~\ref{table:node-to-client-protocol-numbers}.
 \begin{table}[ht]

ouroboros-network-framework/src/Ouroboros/Network/Protocol/Handshake.hs

@@ -75,7 +75,7 @@ tryHandshake doHandshake = do
 
 
 --
--- Record arguemnts
+-- Record arguments
 --
 
 -- | Common arguments for both 'Handshake' client & server.