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 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 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 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

8.4. RPC - 图1

Figure 8.8 RPC working principle

Normally, an RPC call from client to server has the following ten steps:

    1. Call the client handle, execute transfer arguments.
    1. Call local system kernel to send network messages.
    1. Send messages to remote hosts.
    1. The server receives handle and arguments.
    1. Execute remote processes.
    1. Return execution result to corresponding handle.
    1. The server handle calls remote system kernel.
    1. Messages sent back to local system kernel.
    1. The client handle receives messages from system kernel.
    1. The client gets results from corresponding handle.

Go RPC

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 must abide by the following rules for remote access, otherwise the corresponding calls will be ignored.

  • Functions are exported (capitalized).
  • Functions must have two arguments with exported types.
  • 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 must have a return value of error type.

For example:

  1. func (t *T) MethodName(argType T1, replyType *T2) error

Where T, T1 and T2 must be able to be encoded by the package/gob package.

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

HTTP server side code:

  1. package main
  3. import (
  4.     "errors"
  5.     "fmt"
  6.     "net/http"
  7.     "net/rpc"
  8. )
  10. type Args struct {
  11.     A, B int
  12. }
  14. type Quotient struct {
  15.     Quo, Rem int
  16. }
  18. type Arith int
  20. func (t *Arith) Multiply(args *Args, reply *int) error {
  21.     *reply = args.A * args.B
  22.     return nil
  23. }
  25. func (t *Arith) Divide(args *Args, quo *Quotient) error {
  26.     if args.B == 0 {
  27.         return errors.New("divide by zero")
  28.     }
  29.     quo.Quo = args.A / args.B
  30.     quo.Rem = args.A % args.B
  31.     return nil
  32. }
  34. func main() {
  36.     arith := new(Arith)
  37.     rpc.Register(arith)
  38.     rpc.HandleHTTP()
  40.     err := http.ListenAndServe(":1234", nil)
  41.     if err != nil {
  42.         fmt.Println(err.Error())
  43.     }
  44. }

We registered a RPC service of Arith, then registered this service on HTTP through rpc.HandleHTTP. After that, we are able to transfer data through HTTP.

Client side code:

  1. package main
  3. import (
  4.     "fmt"
  5.     "log"
  6.     "net/rpc"
  7.     "os"
  8. )
  10. type Args struct {
  11.     A, B int
  12. }
  14. type Quotient struct {
  15.     Quo, Rem int
  16. }
  19. func main() {
  20.     if len(os.Args) != 2 {
  21.         fmt.Println("Usage: ", os.Args[0], "server")
  22.         os.Exit(1)
  23.     }
  24.     serverAddress := os.Args[1]
  26.     client, err := rpc.DialHTTP("tcp", serverAddress+":1234")
  27.     if err != nil {
  28.         log.Fatal("dialing:", err)
  29.     }
  30.     // Synchronous call
  31.     args := Args{17, 8}
  32.     var reply int
  33.     err = client.Call("Arith.Multiply", args, &reply)
  34.     if err != nil {
  35.         log.Fatal("arith error:", err)
  36.     }
  37.     fmt.Printf("Arith: %d*%d=%d\n", args.A, args.B, reply)
  39.     var quot Quotient
  40.     err = client.Call("Arith.Divide", args, &quot)
  41.     if err != nil {
  42.         log.Fatal("arith error:", err)
  43.     }
  44.     fmt.Printf("Arith: %d/%d=%d remainder %d\n", args.A, args.B, quot.Quo, quot.Rem)
  46. }

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.

  1. $ ./http_c localhost
  2. Arith: 17*8=136
  3. Arith: 17/8=2 remainder 1

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 server side code:

  1. package main
  3. import (
  4.     "errors"
  5.     "fmt"
  6.     "net"
  7.     "net/rpc"
  8.     "os"
  9. )
  11. type Args struct {
  12.     A, B int
  13. }
  15. type Quotient struct {
  16.     Quo, Rem int
  17. }
  19. type Arith int
  21. func (t *Arith) Multiply(args *Args, reply *int) error {
  22.     *reply = args.A * args.B
  23.     return nil
  24. }
  26. func (t *Arith) Divide(args *Args, quo *Quotient) error {
  27.     if args.B == 0 {
  28.         return errors.New("divide by zero")
  29.     }
  30.     quo.Quo = args.A / args.B
  31.     quo.Rem = args.A % args.B
  32.     return nil
  33. }
  35. func main() {
  37.     arith := new(Arith)
  38.     rpc.Register(arith)
  40.     tcpAddr, err := net.ResolveTCPAddr("tcp", ":1234")
  41.     checkError(err)
  43.     listener, err := net.ListenTCP("tcp", tcpAddr)
  44.     checkError(err)
  46.     for {
  47.         conn, err := listener.Accept()
  48.         if err != nil {
  49.             continue
  50.         }
  51.         rpc.ServeConn(conn)
  52.     }
  54. }
  56. func checkError(err error) {
  57.     if err != nil {
  58.         fmt.Println("Fatal error ", err.Error())
  59.         os.Exit(1)
  60.     }
  61. }

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 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:

  1. package main
  3. import (
  4.     "fmt"
  5.     "log"
  6.     "net/rpc"
  7.     "os"
  8. )
  10. type Args struct {
  11.     A, B int
  12. }
  14. type Quotient struct {
  15.     Quo, Rem int
  16. }
  18. func main() {
  19.     if len(os.Args) != 2 {
  20.         fmt.Println("Usage: ", os.Args[0], "server:port")
  21.         os.Exit(1)
  22.     }
  23.     service := os.Args[1]
  25.     client, err := rpc.Dial("tcp", service)
  26.     if err != nil {
  27.         log.Fatal("dialing:", err)
  28.     }
  29.     // Synchronous call
  30.     args := Args{17, 8}
  31.     var reply int
  32.     err = client.Call("Arith.Multiply", args, &reply)
  33.     if err != nil {
  34.         log.Fatal("arith error:", err)
  35.     }
  36.     fmt.Printf("Arith: %d*%d=%d\n", args.A, args.B, reply)
  38.     var quot Quotient
  39.     err = client.Call("Arith.Divide", args, &quot)
  40.     if err != nil {
  41.         log.Fatal("arith error:", err)
  42.     }
  43.     fmt.Printf("Arith: %d/%d=%d remainder %d\n", args.A, args.B, quot.Quo, quot.Rem)
  45. }

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 a Go JSON RPC on the server:

  1. package main
  3. import (
  4.     "errors"
  5.     "fmt"
  6.     "net"
  7.     "net/rpc"
  8.     "net/rpc/jsonrpc"
  9.     "os"
  10. )
  12. type Args struct {
  13.     A, B int
  14. }
  16. type Quotient struct {
  17.     Quo, Rem int
  18. }
  20. type Arith int
  22. func (t *Arith) Multiply(args *Args, reply *int) error {
  23.     *reply = args.A * args.B
  24.     return nil
  25. }
  27. func (t *Arith) Divide(args *Args, quo *Quotient) error {
  28.     if args.B == 0 {
  29.         return errors.New("divide by zero")
  30.     }
  31.     quo.Quo = args.A / args.B
  32.     quo.Rem = args.A % args.B
  33.     return nil
  34. }
  36. func main() {
  38.     arith := new(Arith)
  39.     rpc.Register(arith)
  41.     tcpAddr, err := net.ResolveTCPAddr("tcp", ":1234")
  42.     checkError(err)
  44.     listener, err := net.ListenTCP("tcp", tcpAddr)
  45.     checkError(err)
  47.     for {
  48.         conn, err := listener.Accept()
  49.         if err != nil {
  50.             continue
  51.         }
  52.         jsonrpc.ServeConn(conn)
  53.     }
  55. }
  57. func checkError(err error) {
  58.     if err != nil {
  59.         fmt.Println("Fatal error ", err.Error())
  60.         os.Exit(1)
  61.     }
  62. }

JSON RPC is based on TCP and doesn’t support HTTP yet.

The client side code:

  1. package main
  3. import (
  4.     "fmt"
  5.     "log"
  6.     "net/rpc/jsonrpc"
  7.     "os"
  8. )
  10. type Args struct {
  11.     A, B int
  12. }
  14. type Quotient struct {
  15.     Quo, Rem int
  16. }
  18. func main() {
  19.     if len(os.Args) != 2 {
  20.         fmt.Println("Usage: ", os.Args[0], "server:port")
  21.         log.Fatal(1)
  22.     }
  23.     service := os.Args[1]
  25.     client, err := jsonrpc.Dial("tcp", service)
  26.     if err != nil {
  27.         log.Fatal("dialing:", err)
  28.     }
  29.     // Synchronous call
  30.     args := Args{17, 8}
  31.     var reply int
  32.     err = client.Call("Arith.Multiply", args, &reply)
  33.     if err != nil {
  34.         log.Fatal("arith error:", err)
  35.     }
  36.     fmt.Printf("Arith: %d*%d=%d\n", args.A, args.B, reply)
  38.     var quot Quotient
  39.     err = client.Call("Arith.Divide", args, &quot)
  40.     if err != nil {
  41.         log.Fatal("arith error:", err)
  42.     }
  43.     fmt.Printf("Arith: %d/%d=%d remainder %d\n", args.A, args.B, quot.Quo, quot.Rem)
  45. }

Summary

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.