diff options
| -rw-r--r-- | _bibliography/rpc.bib | 26 | ||||
| -rw-r--r-- | chapter/1/rpc.md | 30 |
2 files changed, 46 insertions, 10 deletions
diff --git a/_bibliography/rpc.bib b/_bibliography/rpc.bib index db77c12..266c603 100644 --- a/_bibliography/rpc.bib +++ b/_bibliography/rpc.bib @@ -333,3 +333,29 @@ author={Schantz, Richard}, year={1975} } + +@misc{grpcbetter, + title={GRPC Authentication}, + author={Google}, + url = {https://www.quora.com/Is-GRPC-better-than-Thrift}, + publisher = {Quora} +} + +@misc{multiplexingthrift, + title={Added service multiplexing support}, + author={Yu, Lixin}, + url = {https://github.com/eleme/thriftpy/pull/88/commits/0877531f9246ca993c1d9af5d29cd009ee6ec7d4}, + publisher = {Github} +} + +@techreport{rfc5531, + title={RFC 5531: RPC: Remote Procedure Call Protocol Specification Version 2}, + author={Thurlow, R}, + year={2009} +} + +@techreport{rfc1831, + title={RFC 1831: RPC: Remote Procedure Call Protocol Specification Version 2}, + author={Srinivasan, R}, + year={1995} +} diff --git a/chapter/1/rpc.md b/chapter/1/rpc.md index 05a6452..6806580 100644 --- a/chapter/1/rpc.md +++ b/chapter/1/rpc.md @@ -109,11 +109,10 @@ Thrift is an RPC system created by Facebook and now part of the Apache Foundatio #### Finagle Finagle was generated by Twitter and is an RPC system written in Scala and can run on a JVM. It is based on three object types: Service objects, Filter objects and Future objects {% cite finagle --file rpc %}. The Future objects act by asynchronously being requested for a computation that would return a response at some time in the future. The Service objects are an endpoint that will return a Future upon processing a request. A Filter object transforms requests for further processing in case additional customization is required from a request. -#### Open Network Computing RPC -* Pros and Cons +#### Open Network Computing RPC(ONC RPC) +ONC was originally introduced as SunRPC {%cite sunrpc --file rpc %} for the Sun NFS. It supported NFS read, write, truncate, unlink, etc operations. However, it was later revised as ONC in 1995 {%cite rfc1831 --file rpc %} and then in 2009 {%cite rfc5531 --file rpc %}. The IDL used in ONC is External Data Representation (XDR), a serialization mechanism specific to networks communication and therefore, ONC is limited to applications like Network File Systems. #### Mobile Assistance Using Infrastructure(MAUI) - The MAUI project {% cite maui --file rpc %}, developed by Microsoft is a computation offloading system for mobile systems. It's an automated system that offloads a mobile code to a dedicated infrastructure in order to increase the battery life of the mobile, minimize the load on the programmer and perform complex computations offsite. MAUI uses RPC as the communication protocol between the mobile and the infrastructure. #### gRPC @@ -139,24 +138,35 @@ Thrift was actually released a few years ago, while the first stable release for gRPC {% cite gRPCLanguages --file rpc %} and Thrift, both, support most of the popular languages, including Java, C/C++, and Python. Thrift supports other languages, like Ruby, Erlang, Perl, Javascript, Node.js and OCaml while gRPC currently supports Node.js and Go. -Thrift provides exception-handling as a message while the programmer has to handle exceptions in gRPC. +The gRPC core is written in C(with the exception of Java and Go) and wrappers are written in other languages to communicate with the core, while the Thrift core is written in C++. + +gRPC also provides easier bi-drectional streaming communicaiton between the caller and callee. The client generally initiates the communication {% cite gRPCLanguages --file rpc %} and once the connection is established the client and the server can perform reads and writes independently of each other. However, bi-directional streaming in Thrift might be a little difficult to handle, since it focuses explicitly on a client-server model. To enable bi-directionaly, async streaming, one may have to run two seperate systems {%cite grpcbetter --file rpc%}. + +Thrift provides exception-handling as a message while the programmer has to handle exceptions in gRPC. In Thrift, exceptions can be returned built into the message, while in gRPC, the programmer explicitly defines this behaviour. This Thrift exception-handling makes it easier to write client-side applications. Although custom authentication mechanisms can be implemented in both these system, gRPC come with a Google-backed authentication using SSL/TLS and Google Tokens {% cite grpcauth --file rpc %}. -The major differences between gRPC and Thrift can be summed in this table. +Moreover, gRPC-based network communication is done using HTTP/2. HTTP/2 makes it feasible for communicating parties to multiplex network connections using the same port. This is more efficient(in terms of memory usage) as compared to HTTP/1.1. Since, gRPC communication is done HTTP/2, it means that gRPC can easily multiplex different services. As for Thrift, multiplexing services is possible, however, due to lack of support from underlying transport protocol, it is performed using a `TMulitplexingProcessor` class {% cite multiplexingthrift --file rpc %}. + +However, both gRPC and Thrift allow async RPC calls. This means that a client can send a request to the server and continue with its execution and the response from the server is processed it arrives. + + +The major comparison between gRPC and Thrift can be summed in this table. | Comparison | Thrift | gRPC | | ----- | ----- | ----- | | License | Apache2 | BSD | +| Sync/Async RPC | Both | Both | | Supported Languages | C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, and OCaml | C/C++, Python, Go, Java, Ruby, PHP, C#, Node.js, Objective-C | +| Core Language | C++| C | | Exceptions | Allows being built in the message | Implemented by the programmer | | Authentication | Custom | Custom + Google Tokens | -| Bi-Directionality | Not straightforward | Core Implementation via HTTP/2 | -| Multiplexing | Some functionality via multiplexed server | Core Implementation via HTTP/2 | +| Bi-Directionality | Not straightforward | Straightforward | +| Multiplexing | Possible via | Possible via HTTP/2 | Although, it's difficult to specifically choose one over the other, however, with increasing popularity of gRPC, and the fact that it's still in early stages of development, the general trend{%cite trendrpcthrift --file rpc %} over the past year has started to shift in favor of gRPC and it's giving Thrift a run for its money. -**Note:** This study is performed in December 2016 so the results are expected to change with time. +**Note:** This study is performed in December 2016 so the results are expected to change with time. ## Applications @@ -198,7 +208,7 @@ RPC can be defined as the "glue" that holds all the microservices together{% cit An example of a microservices ecosystem that uses futures/promises is Finagle at Twitter. -## Security in RPC: +## Security in RPC The initial RPC implementation {% cite implementingrpc --file rpc %} was developed for an isolated LAN network and didn't focus much on security. There're various attack surfaces in that model, from the malicious registry, to a malicious server, to a client targeting for Denial-of-Service to Man-in-the-Middle attack between client and server. @@ -208,7 +218,7 @@ For example, the Oracle Network File System uses a *Secure RPC*{% cite oraclenfs Although, it's possible to come up with a *Threat Model* that would make an RPC implementation insecure to use, however, one has to understand that using any distributed system increases the attack surface anyways and claiming one *paradigm* to be more secure than another would be a biased statement, since *paradigms* are generally an idea and it depends on different system designers to use these *paradigms* to build their systems and take care of features specific to real systems, like security and load-balancing. There's always a possibility of rerouting a request to a malicious server(if the registry gets hacked), or there's no trust between the *caller* and *callee*. However, we maintain that RPC *paradigm* is not secure or insecure(for that matter), and that the most secure systems are the ones that are in an isolated environment, disconnected from the public internet with a self-destruct mechanism{% cite self --file rpc %} in place, in an impenetrable bunker, and guarded by the Knights Templar(*they don't exist! Well, maybe Fort Meade comes close*). -## Discussion: +## Discussion RPC *paradigm* shines the most in *request-response* mechanisms. Futures and Promises also appear to a new breed of RPC. This leads one to question, as to whether every *request-response* system is a modified implementation to of the RPC *paradigm*, or does it actually bring anything new to the table? These modern communication protocols, like HTTP and REST, might just be a different flavor of RPC. In HTTP, a client *requests* a web page(or some other content), the server then *responds* with the required content. The dynamics of this communication might be slightly different from your traditional RPC, however, an HTTP Stateless server adheres to most of the concepts behind RPC *paradigm*. Similarly, consider sending a request to your favorite Google API. Say, you want to translate your latitude/longitude to an address using their Reverse Geocoding API, or maybe want to find out a good restaurant in your vicinity using their Places API, you'll send a *request* to their server to perform a *procedure* that would take a few input arguments, like the coordinates, and return the result. Even though these APIs follow a RESTful design, it appears to be an extension to the RPC *paradigm*. |