fix: revisions to FTP chapter

docs/ftp/index.html

@@ -363,15 +363,15 @@ <h1>Chapter 21: Transferring Files</h1>
           <div class="page-toc"></div>
           <p>The Internet is simpler than most people realize
 (as well as being more complex than anyone could possibly comprehend).
-Most systems still follow the rules they did thirty years ago;
+Most systems still follow the rules they did 30 years ago;
 in particular,
 most web servers still handle the same kinds of messages in the same way.</p>
 <p>A typical web application is made up of <a class="gl-ref" href="../glossary/#gl:client" title="A program such as a browser that sends requests to a server and does something with the response." markdown="1">clients</a>
 and <a class="gl-ref" href="../glossary/#gl:server" title="A program that waits for requests from clients and sends them data in response." markdown="1">servers</a>.
 A client program initiates communication by sending a message and waiting for a response;
 a server,
 on the other hand,
-waits for requests and the replies to them.
+waits for requests and then replies to them.
 There are typically many more clients than servers:
 for example,
 there may be hundreds or thousands of browsers
@@ -382,7 +382,7 @@ <h1>Chapter 21: Transferring Files</h1>
 <a class="x-ref" href="../http/">Chapter 22</a> will extend this to show
 how to build programs that communicate using HTTP.
 A central concern in both chapters is how to test such programs;
-while who sends what messages when changes from application to application,
+while <em>who</em> sends <em>what</em> messages <em>when</em> changes from application to application,
 the testing techniques largely remain the same.</p>
 <h2 id="ftp-tcpip">Section 21.1: Using TCP/IP</h2>
 <p>Almost every program on the web
@@ -438,7 +438,7 @@ <h2 id="ftp-tcpip">Section 21.1: Using TCP/IP</h2>
 <p class="continue">We call it &ldquo;basic&rdquo; rather than &ldquo;simple&rdquo; because there&rsquo;s a lot going on here.
 From top to bottom:</p>
 <ol>
-<li>We import some modules and defines two constants.
+<li>We import some modules and define two constants.
     The first, <code>SERVER_ADDRESS</code>,
     consists of a host identifier and a port.
     (The string <code>"localhost"</code> means &ldquo;the current machine&rdquo;.)
@@ -506,7 +506,7 @@ <h2 id="ftp-tcpip">Section 21.1: Using TCP/IP</h2>
 we derive a class of our own from <code>BaseRequestHandler</code>
 that provides a <code>handle</code> method
 (<a class="fig-ref" href="../ftp/#ftp-inheritance">Figure 21.3</a>).
-Every time <code>TCPServer</code> gets a new connection
+Every time <code>TCPServer</code> gets a new connection,
 it creates a new object of our class
 and calls that object&rsquo;s <code>handle</code> method.</p>
 <figure id="ftp-inheritance">
@@ -554,7 +554,7 @@ <h2 id="ftp-chunk">Section 21.2: Chunking</h2>
 our server will ignore it.
 This can result in <a class="gl-ref" href="../glossary/#gl:deadlock" title="A situation in which no-one can proceed because everyone is blocked on someone else." markdown="1">deadlock</a>:
 the server is trying to send a reply
-while the client is a trying to send the rest of the message,
+while the client is trying to send the rest of the message,
 and since neither is listening,
 neither can move forward.
 Increasing the size of the <span class="ix-entry" ix-key="buffer (in memory)" markdown="1">memory buffer</span>
@@ -599,7 +599,7 @@ <h2 id="ftp-chunk">Section 21.2: Chunking</h2>
 If that number gets us to the end of the data we&rsquo;re sending,
 the function can exit the loop.
 If not,
-it adds the number of bytes send to <code>total</code>
+it adds the number of bytes sent to <code>total</code>
 so that it knows where to start sending
 the next time around:</p>
 <div class="code-sample lang-py" title="client_chunk.py">
@@ -669,7 +669,7 @@ <h2 id="ftp-chunk">Section 21.2: Chunking</h2>
 </div>
 <h2 id="ftp-test">Section 21.3: Testing</h2>
 <p>Testing single-process command-line applications is hard enough.
-To test a client-server application like the one above
+To test a client-server application like the one above,
 we have to start the server,
 wait for it to be ready,
 then run the client,
@@ -773,9 +773,11 @@ <h2 id="ftp-test">Section 21.3: Testing</h2>
 how close is what we test to what we use in production?
 In an ideal world they are exactly the same,
 but in cases like this it makes sense to sacrifice a little fidelity for testability&rsquo;s sake.</p>
-<div class="pagebreak"></div>
-
 <h2 id="ftp-summary">Section 21.4: Summary</h2>
+<p><a class="fig-ref" href="../ftp/#ftp-concept-map">Figure 21.4</a> summarizes the idea introduces in this chapter.
+While understanding how to send data over a network is important,
+knowing how to test programs that interact with the outside world
+is just as important.</p>
 <figure id="ftp-concept-map" class="here">
 <img src="./concept_map.svg" alt="File transfer concept map"/>
 <figcaption markdown="1">Figure 21.4: File transfer concept map.</figcaption>

src/ftp/index.md

@@ -17,7 +17,7 @@ depends:
 
 The Internet is simpler than most people realize
 (as well as being more complex than anyone could possibly comprehend).
-Most systems still follow the rules they did thirty years ago;
+Most systems still follow the rules they did 30 years ago;
 in particular,
 most web servers still handle the same kinds of messages in the same way.
 
@@ -26,7 +26,7 @@ and [%g server "servers" %].
 A client program initiates communication by sending a message and waiting for a response;
 a server,
 on the other hand,
-waits for requests and the replies to them.
+waits for requests and then replies to them.
 There are typically many more clients than servers:
 for example,
 there may be hundreds or thousands of browsers
@@ -38,7 +38,7 @@ to move files from one machine to another.
 [%x http %] will extend this to show
 how to build programs that communicate using HTTP.
 A central concern in both chapters is how to test such programs;
-while who sends what messages when changes from application to application,
+while *who* sends *what* messages *when* changes from application to application,
 the testing techniques largely remain the same.
 
 ## Using TCP/IP {: #ftp-tcpip}
@@ -86,7 +86,7 @@ We call it "basic" rather than "simple" because there's a lot going on here.
 From top to bottom:
 {: .continue}
 
-1.  We import some modules and defines two constants.
+1.  We import some modules and define two constants.
     The first, `SERVER_ADDRESS`,
     consists of a host identifier and a port.
     (The string `"localhost"` means "the current machine".)
@@ -139,7 +139,7 @@ In order to do that,
 we derive a class of our own from `BaseRequestHandler`
 that provides a `handle` method
 ([%f ftp-inheritance %]).
-Every time `TCPServer` gets a new connection
+Every time `TCPServer` gets a new connection,
 it creates a new object of our class
 and calls that object's `handle` method.
 
@@ -177,7 +177,7 @@ If the client sends more than a kilobyte of data,
 our server will ignore it.
 This can result in [%g deadlock "deadlock" %]:
 the server is trying to send a reply
-while the client is a trying to send the rest of the message,
+while the client is trying to send the rest of the message,
 and since neither is listening,
 neither can move forward.
 Increasing the size of the [%i "buffer (in memory)" "memory buffer" %]
@@ -210,7 +210,7 @@ how many bytes were actually sent.
 If that number gets us to the end of the data we're sending,
 the function can exit the loop.
 If not,
-it adds the number of bytes send to `total`
+it adds the number of bytes sent to `total`
 so that it knows where to start sending
 the next time around:
 
@@ -246,7 +246,7 @@ and the server prints
 ## Testing {: #ftp-test}
 
 Testing single-process command-line applications is hard enough.
-To test a client-server application like the one above
+To test a client-server application like the one above,
 we have to start the server,
 wait for it to be ready,
 then run the client,
@@ -310,10 +310,13 @@ how close is what we test to what we use in production?
 In an ideal world they are exactly the same,
 but in cases like this it makes sense to sacrifice a little fidelity for testability's sake.
 
-<div class="pagebreak"></div>
-
 ## Summary {: #ftp-summary}
 
+[%f ftp-concept-map %] summarizes the idea introduces in this chapter.
+While understanding how to send data over a network is important,
+knowing how to test programs that interact with the outside world
+is just as important.
+
 [% figure
    slug="ftp-concept-map"
    img="concept_map.svg"