diff options
| author | Heather Miller <heather.miller@epfl.ch> | 2017-01-02 14:35:59 +0100 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2017-01-02 14:35:59 +0100 |
| commit | 67118db13c3acb378da9a853d8119e82e20d306a (patch) | |
| tree | 3be3c254f83171535ca265f81631487d835780b5 | |
| parent | 1c5a825f249c6153b9225179e0053a6dddfe33d5 (diff) | |
| parent | 0f5037a01416bd24913e5e12d9c4757498d68eee (diff) | |
Merge pull request #23 from tiagocoutinho/patch-1
Replace communication with communicate
| -rw-r--r-- | chapter/1/rpc.md | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/chapter/1/rpc.md b/chapter/1/rpc.md index ccc9739..36d195d 100644 --- a/chapter/1/rpc.md +++ b/chapter/1/rpc.md @@ -36,7 +36,7 @@ Originally, RPC was developed as a synchronous request-response mechanism, tied Modern RPC-based systems are language-agnostic, asynchronous, load-balanced systems. Authentication and authorization to these systems have been added as needed along with other security features. Most of these systems have fault-handling built into them as modules and the systems are generally spread all across the internet. -RPC programs have a network (or a communication channel), therefore, they need to handle remote errors and be able to communication information successfully. Error handling generally varies and is categorized as *remote-host* or *network* failure handling. Depending on the type of the system, and the error, the caller (or the callee) return an error and these errors can be handled accordingly. For asynchronous RPC calls, it's possible to specify events to ensure progress. +RPC programs have a network (or a communication channel), therefore, they need to handle remote errors and be able to communicate information successfully. Error handling generally varies and is categorized as *remote-host* or *network* failure handling. Depending on the type of the system, and the error, the caller (or the callee) return an error and these errors can be handled accordingly. For asynchronous RPC calls, it's possible to specify events to ensure progress. RPC implementations use a *serialization*(also referred to as *marshalling* or *pickling*) scheme on top of an underlying communication protocol (traditionally TCP over IP). These *serialization* schemes allow both the caller *caller* and *callee* to become language agnostic allowing both these systems to be developed in parallel without any language restrictions. Some examples of serialization schemes are JSON, XML, or Protocol Buffers {% cite grpc --file rpc %}. |