Fix typos and grammar

Author: Anchor

en/eBook/08.4.md

@@ -1,48 +1,48 @@
 # 8.4 RPC
 
-In previous sections we talked about how to write network applications based on Sockets and HTTP, we learned that both of them are using "information exchange" model, which clients send requests and servers response. This kind of data exchange are based on certain format so both sides are able to understand. However, many independence applications do not use this model, but call services just like call normal functions.
+In previous sections we talked about how to write network applications based on Sockets and HTTP. We learned that both of them use the "information exchange" model, in which clients send requests and servers respond to them. This kind of data exchange is based on a specific format so that both sides are able to communicate with one another. However, many independent applications do not use this model, but instead call services just like they would call normal functions.
 
-RPC was intended to achieve the function call mode networking. Clients like calling native functions, and then packaged these parameters after passing through the network to the server, the server unpacked process execution, and executes the results back to the client.
+RPC was intended to be the function call mode for networked systems. Clients execute RPCs like they call native functions, except they package the function parameters and send them through the network to the server. The server can then unpack these parameters and process the request, executing the results back to the client.
 
-In computer science, a remote procedure call (RPC) is an inter-process communication that allows a computer program to cause a subroutine or procedure to execute in another address space (commonly on another computer on a shared network) without the programmer explicitly coding the details for this remote interaction. That is, the programmer writes essentially the same code whether the subroutine is local to the executing program, or remote. When the software in question uses object-oriented principles, RPC is called remote invocation or remote method invocation.
+In computer science, a remote procedure call (RPC) is a type of inter-process communication that allows a computer program to cause a subroutine or procedure to execute in another address space (commonly on another computer on a shared network) without the programmer explicitly coding the details for this remote interaction. That is, the programmer writes essentially the same code whether the subroutine is local to the executing program, or remote. When the software in question uses object-oriented principles, RPC is called remote invocation or remote method invocation.
 
 ## RPC working principle
 
 ![](images/8.4.rpc.png?raw=true)
 
-Figure 8.8 RPC working principle.
+Figure 8.8 RPC working principle
 
-Normally, a RPC call from the client to the server has following ten steps:
+Normally, an RPC call from client to server has the following ten steps:
 
 - 1. Call the client handle, execute transfer arguments.
 - 2. Call local system kernel to send network messages.
 - 3. Send messages to remote hosts.
 - 4. The server receives handle and arguments.
 - 5. Execute remote processes.
-- 6. Return execute result to corresponding handle.
+- 6. Return execution result to corresponding handle.
 - 7. The server handle calls remote system kernel.
 - 8. Messages sent back to local system kernel.
 - 9. The client handle receives messages from system kernel.
 - 10. The client gets results from corresponding handle.
 
 ## Go RPC
 
-Go has official support for RPC in standard library with three levels which are TCP, HTTP and JSON RPC. Note that Go RPC is not like other traditional RPC systems, it requires you to use Go applications on both sides of clients and servers because it encodes content through Gob.
+Go has official support for RPC in its standard library on three levels, which are TCP, HTTP and JSON RPC. Note that Go RPC is not like other traditional RPC systems. It requires you to use Go applications on both client and server sides because it encodes content using Gob.
 
-Functions of Go RPC have to follow following rules for remote access, otherwise corresponding calls will be ignored.
+Functions of Go RPC have must abide by the following rules for remote access, otherwise the corresponding calls will be ignored.
 
-- Functions are exported(capitalize).
+- Functions are exported (capitalize).
 - Functions have to have two arguments with exported types.
-- The first argument is for receiving from the client, and the second one has to be pointer type and is for replying to the client.
+- The first argument is for receiving from the client, and the second one has to be a pointer and is for replying to the client.
 - Functions have to have a return value of error type.
 
 For example:
 
 	func (t *T) MethodName(argType T1, replyType *T2) error
 
-Where T, T1 and T2 must be able to encoded by package `encoding/gob`.
+Where T, T1 and T2 must be able to be encoded by the `package/gob` package.
 
-Any kind of RPC have to through network to transfer data, Go RPC can either use HTTP or TCP, the benefits of using HTTP is that you can reuse some function in package `net/http`.
+Any kind of RPC has to go through a network to transfer data. Go RPC can either use HTTP or TCP. The benefits of using HTTP is that you can reuse some functions from the `net/http` package.
 
 ### HTTP RPC 
 
@@ -144,17 +144,17 @@ Client side code:
 
 	}
 
-We compile the client and the server side code separately, start server and start client, then you'll have something similar as follows after you input some data.
+We compile the client and the server side code separately then start the server and client. You'll then have something similar as follows after you input some data.
 
 	$ ./http_c localhost
 	Arith: 17*8=136
 	Arith: 17/8=2 remainder 1
 
-As you can see, we defined a struct for return type, we use it as type of function argument in server side, and use as type of the second and third arguments in the client `client.Call`. This call is very important, it has three arguments, where the first one the name of function that is going to be called, and the second is the argument you want to pass, the last one is the return value(pointer type). So far we see that it's easy to implement RPC in Go.
+As you can see, we defined a struct for the return type. We use it as type of function argument on the server side, and as the type of the second and third arguments on the client `client.Call`. This call is very important. It has three arguments, where the first one is the name of the function that is going to be called, the second is the argument you want to pass, and the last one is the return value (of pointer type). So far we see that it's easy to implement RPC in Go.
 
 ### TCP RPC
 
-Let's try the RPC that is based on TCP, here is the serer side code:
+Let's try the RPC that is based on TCP, here is the server side code:
 
 	package main
 
@@ -218,9 +218,9 @@ Let's try the RPC that is based on TCP, here is the serer side code:
 		}
 	}
 
-The different between HTTP RPC and TCP RPC is that we have to control connections by ourselves if we use TCP RPC, then pass connections to RPC for processing.
+The difference between HTTP RPC and TCP RPC is that we have to control connections by ourselves if we use TCP RPC, then pass connections to RPC for processing.
 
-As you may guess, this is a blocking pattern application, you are free to use goroutine to extend this application for more advanced experiment.
+As you may have guessed, this is a blocking pattern. You are free to use goroutines to extend this application as a more advanced experiment.
 
 The client side code:
 
@@ -270,11 +270,11 @@ The client side code:
 
 	}
 
-The only difference in client side code is that HTTP client uses DialHTTP where TCP client uses Dial(TCP).
+The only difference in the client side code is that HTTP clients use DialHTTP whereas TCP clients use Dial(TCP).
 
 ### JSON RPC
 
-JSON RPC encodes data to JSON instead of gob, let's see an example of Go JSON RPC server side code sample:
+JSON RPC encodes data to JSON instead of gob. Let's see an example of a Go JSON RPC on the server:
 
 	package main
 
@@ -339,7 +339,7 @@ JSON RPC encodes data to JSON instead of gob, let's see an example of Go JSON RP
 		}
 	}
 
-JSON RPC is based on TCP, it hasn't support HTTP yet.
+JSON RPC is based on TCP and doesn't support HTTP yet.
 
 The client side code:
 
@@ -391,7 +391,7 @@ The client side code:
 
 ## Summary
 
-Go has good support of HTTP, TPC, JSON RPC implementation, we can easily develop distributed web applications; however, it is regrettable that Go hasn't support for SOAP RPC which some third-party packages did it on open source.
+Go has good support for HTTP, TPC and JSON RPC implementation which allow us to easily develop distributed web applications; however, it is regrettable that Go doesn't have built-in support for SOAP RPC, although some open source third-party packages do offer this.
 
 ## Links