Review remarks to the udp-link article.

src.docs/content/articles/udp-link.rst

@@ -12,7 +12,7 @@ Using udp-link to enhance TCP connections stability
 |
 
 I recently discovered udp-link_, a very useful project for all those guys like
-me who spend most of their working time in terminals over ssh connections.
+me who spend most of their working time in terminals over SSH connections.
 The tool implements the UDP transport layer, which acts as a proxy for
 TCP connections. It's designed to be integrated into the OpenSSH configuration.
 However, with a little trick, it can also be used as a general-purpose
@@ -26,35 +26,35 @@ to remain alive even if an IP address changes.
 *udp-link* is written in C by `Pavel Gulchuk`_, who has a lot of experience
 in running unreliable networks. Despite being a young project, the version
 v0.4_ shows pretty stable results. Once configured, you won't think about it
-anymore. Unless you're surprised every time when ssh connections don't brake,
+anymore. Unless you're surprised every time when SSH connections don't break,
 survive a laptop's sleep mode and connections
 to different Wi-Fi networks.
 
 |
 
-In the current architecture, the client-side tool takes data on the standard
+In the current architecture, the client-side tool takes data from the standard
 input and sends it to the server side via UDP. The same copy of the tool takes
 that data from the network on a specific UDP port and sends it to a TCP service
 (local or remote from a server-side perspective).
 The destination TCP service and a UDP listening port on the server
 side can be specified on the client at startup. Otherwise, a TCP connection
-will be established with *127.0.0.1:22* and a port is randomly chosen from
+will be established with *127.0.0.1:22*, and a port will be randomly chosen from
 a predefined port range. Note that the server firewall should allow the
 traffic to this port range on UDP. The TCP service can also reside on a different
-host, if the server side is used as a jumpbox. I consider it one of the greatest
+host if the server side is used as a jumpbox. I consider it one of the greatest
 features that *udp-link* uses a zero server-side configuration, all
 configuration tweaks happen only on the client side.
 
 |
 
 *udp-link* on the server side does not run as a daemon or listen on a UDP port
-all the time. Instead, the client initiates the invocation of the tool on the
+all the time. Instead, the client initiates the invocation of the tool
 on the server side in listening mode with a randomly generated key. This key
 is used to authenticate the client connection. This is done on demand by
-establishing a normal ssh connection over TCP with the server side, temporarily,
+establishing a normal SSH connection over TCP with the server side, temporarily,
 just to run the tool in the background. The connection is then closed.
 This is where a secure client authentication comes into play. *udp-link* **doesn't
-encrypt the transferred data**, which is useful when is used together with ssh
+encrypt the transferred data**, which is useful when is used together with SSH
 because it avoids a double encryption, but needs to be kept that in mind when
 used with other configurations.
 
@@ -72,7 +72,7 @@ the tool on both sides
 
 |
 
-and then make an ssh connection on the client side by executing a command
+and then make an SSH connection on the client side by executing a command
 similar to
 
 .. code-block:: shell
@@ -81,16 +81,16 @@ similar to
 
 |
 
-*ProxyCommand* allows ssh to send all its data to the standard input of
+*ProxyCommand* allows SSH to send all its data to the standard input of
 a specified command instead of to a TCP connection. This command will be
 responsible for sending the data to a server side in some way and should
-eventually deliver it to a target ssh service.
+eventually deliver it to a target SSH service.
 OpenSSH also supports a number of macros such as *%r* and *%p* which can be found
-in its documentation. Personally, I use ssh in a slightly different way and
-never send out my public ssh keys to unknown hosts. More details on this topic
+in its documentation. Personally, I use SSH in a slightly different way and
+never send out my public SSH keys to unknown hosts. More details on this topic
 can be found in a great article '`OpenSSH client side key management for better privacy and security`_',
 written by Timothée Ravier. So I'm actively using *ssh_config* files, where
-I specify all connection-specific details, such as hostname, username, ssh key,
+I specify all connection-specific details, such as hostname, username, SSH key,
 and in this case, **ProxyCommand**. My typical *ssh_config* file looks
 something like this
 
@@ -123,9 +123,9 @@ and then to connect I just run
 
 |
 
-The second **Host some-IP** block is needed to provide a correct ssh key to
-a temporary ssh connection (without *ProxyCommand*) that *udp-link* establishes
-at the beginning of a new session. To debug the connection add *--debug* option
+The second **Host some-IP** block is needed to provide a correct SSH key to
+a temporary SSH connection (without *ProxyCommand*) that *udp-link* establishes
+at the beginning of a new session. To debug the connection, add *--debug* option
 
 .. code-block:: shell
 
@@ -144,7 +144,7 @@ I initiate a connection like this
 
 You can also bind it to a privileged port (1-1024), but *udp-link* needs root
 permissions to do this, which can be achieved in a number of ways, such
-as making it root-owned with the setuid bit turned on on the server-side copy
+as making it root-owned with the setuid bit turned on the server-side copy
 of a binary file.
 
 .. code-block:: shell
@@ -155,14 +155,14 @@ of a binary file.
 |
 
 Unlike other projects with a similar goal, e.g. Mosh_, *udp-link* doesn't
-allocate a pseudo terminal, which I consider a feature, because it opens
+allocate a pseudo-terminal, which I consider a feature, because it opens
 the possibility to use the tool not only for accessing remote terminals, but
 also for proxying any arbitrary TCP connection. However, *udp-link* cannot
 currently listen on a local TCP port on the client
 side. Fortunately, this can be worked around by adding *socat* and its exceptional
 ability to connect things. However, *socat* cannot be paired with *udp-link* via
 an unnamed pipe, because pipes provide a unidirectional interprocess
-communication, while here we need a bi-directional communication to get data
+communication, while here we need a bidirectional communication to get data
 back from the network. The trick is that *udp-link* is invoked by *socat*. Here is
 an example of how to open a listening *2525/TCP* port on the client side, then
 proxy a future TCP connection over a UDP channel to a remote host, and connect
@@ -183,13 +183,13 @@ Summary
 -------
 
 * *udp-link* is a tool that implements the UDP transport layer to act as a proxy for TCP connections over unreliable networks.
-* It is designed to be integrated into OpenSSH configuration to improve stability of ssh connections.
+* It is designed to be integrated into OpenSSH configuration to improve stability of SSH connections.
 * udp-link allows TCP connections to remain alive even if the IP address changes through its IP roaming feature.
 * On the client side, udp-link takes data from standard input and sends it to the server side via UDP, where it is then sent to the target TCP service.
 * The server side of udp-link does not run as a daemon and instead is invoked on demand by the client through a temporary SSH connection.
 * Authentication is done through a randomly generated key during the temporary SSH connection.
 * udp-link doesn't encrypt the transferred data, which is useful when is used together with SSH to avoid double encryption.
-* Installation is done through cloning the GitHub repo, compiling, and installing on both client and server.
+* Installation is done by cloning the GitHub repo, compiling, and installing it on both client and server.
 * All configuration is done only on the client side
 
 .. Links