diff --git a/OVERVIEW.TXT b/OVERVIEW.TXT
index f0b184c9..3e200372 100644
--- a/OVERVIEW.TXT
+++ b/OVERVIEW.TXT
@@ -62,8 +62,8 @@ As a whole, everything works through the following components:
     Host Services:
       These services run within the ADB Server and thus do not need to
       communicate with a device at all. A typical example is "adb devices"
-      which is used to return the list of currently known devices and their
-      states. They are a few other services though.
+      that is used to return the list of currently known devices and their
+      states. There are a few other services, though.
 
     Local Services:
       These services either run within the adbd daemon, or are started by
@@ -77,7 +77,7 @@ II. Protocol details:
 
   1. Client <-> Server protocol:
 
-    This details the protocol used between ADB clients and the ADB
+    This section details the protocol used between ADB clients and the ADB
     server itself. The ADB server listens on TCP:localhost:5037.
 
     A client sends a request using the following format:
diff --git a/README.md b/README.md
index 224387c4..5f37bf21 100644
--- a/README.md
+++ b/README.md
@@ -33,11 +33,11 @@ The Client and the Server are contained in the same executable and both run on t
 
 A smart socket is a simple TCP socket with a smart protocol built on top of it. This is what Clients connect onto from the Host side. The Client must always initiate communication via a human readable request but the response format varies. The smart protocol is documented in [SERVICES.TXT](SERVICES.TXT).
 
-On the other side, the Server communicate with a device via a Transport. adb initially targeted devices connecting over USB, which is restricted to a fixed number of data streams. Therefore, adb multiplexes multiple byte streams over a single pipe via Transport. When devices connecting over other mechanisms (e.g. emulators over TCP) were introduced, the existing transport protocol was maintained.
+On the other side, the Server communicates with a device via a Transport. adb initially targeted devices connecting over USB, which is restricted to a fixed number of data streams. Therefore, adb multiplexes multiple byte streams over a single pipe via Transport. When devices connecting over other mechanisms (e.g. emulators over TCP) were introduced, the existing transport protocol was maintained.
 
 ## THREADING MODEL and FDEVENT system
 
-At the heart of both the Server and Daemon is a main thread running an fdevent loop, which is an platform-independent abstraction over poll/epoll/WSAPoll monitoring file descriptors events. Requests and services are usually server from the main thread but some service requests result in new threads being spawned.
+At the heart of both the Server and Daemon is a main thread running an fdevent loop, which is a platform-independent abstraction over poll/epoll/WSAPoll monitoring file descriptors events. Requests and services are usually served from the main thread but some service requests result in new threads being spawned.
 
 To allow for operations to run on the Main thread, fdevent features a RunQueue combined with an interrupt fd to force polling to return.
 
@@ -61,7 +61,7 @@ To allow for operations to run on the Main thread, fdevent features a RunQueue c
 
 The asocket, apacket, and amessage constructs exist only to wrap data while it transits on a Transport. An asocket handles a stream of apackets. An apacket consists in a amessage header featuring a command (`A_SYNC`, `A_OPEN`, `A_CLSE`, `A_WRTE`, `A_OKAY`, ...) followed by a payload (find more documentation in [protocol.txt](protocol.txt). There is no `A_READ` command because an asocket is unidirectional. To model a bi-directional stream, asocket have a peer which go in the opposite direction.
 
-An asocket features a buffer where the elemental unit is an apacket. Is traffic is inbound, the buffer stores apacket until they are consumed. If the traffic is oubound, the buffer store apackets until they are sent down the wire (with `A_WRTE` commands).
+An asocket features a buffer where the elemental unit is an apacket. If traffic is inbound, the buffer stores the apacket until it is consumed. If the traffic is oubound, the buffer stores apackets until they are sent down the wire (with `A_WRTE` commands).
 
 ```
 +---------------------ASocket------------------------+
diff --git a/SYNC.TXT b/SYNC.TXT
index 4445a761..1bc5d99d 100644
--- a/SYNC.TXT
+++ b/SYNC.TXT
@@ -11,17 +11,17 @@ SERVICES.TXT sets the connection in sync mode. This mode is a binary mode that
 differs from the regular adb protocol. The connection stays in sync mode until
 explicitly terminated (see below).
 
-After the initial "sync:" command is sent the server must respond with either
-"OKAY" or "FAIL" as per usual.
+After the initial "sync:" command is sent, the server must respond with either
+"OKAY" or "FAIL" as per the usual protocol.
 
 In sync mode both the server and the client will frequently use eight-byte
 packets to communicate. In this document these are called sync requests and sync
-responses. The first four bytes are an id that specifies the sync request. It is
-represented by four utf-8 characters. The last four bytes are a Little-Endian
-integer, with various uses. This number will be called "length" below. In fact
-all binary integers are Little-Endian in the sync mode. Sync mode is
-implicitly exited after each sync request, and normal adb communication
-follows as described in SERVICES.TXT.
+responses. The first four bytes constitute an id that specifies the sync request.
+It is represented by four ASCII bytes in order to make them more human-readable
+when debugging. The last four bytes are a Little-Endian integer, with various
+uses. This number shall be called "length" below. In fact, all binary integers
+are Little-Endian in the sync mode. Sync mode is implicitly exited after each
+sync request, and normal adb communication follows as described in SERVICES.TXT.
 
 The following sync requests are accepted:
 LIST - List the files in a folder