2. cnp3-ebook
3. protocols/rpc
4. English
5. Zen

11 ../../protocols/rpc.rst:25
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Encoding data 13/10000 · 13
12 ../../protocols/rpc.rst:27
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The encoding problem exists in a wide range of applications. In the previous sections, we have described how character-based encodings are used by email and HTTP. Although standard encoding techniques such as ASN.1 [Dubuisson2000]_ have been defined to cover most application needs, many applications have defined their specific encoding. `Remote Procedure Call` are no exception to this rule. The three most popular encoding methods are probably XDR :rfc:`1832` used by ONC-RPC :rfc:`1831`, XML, used by XML-RPC and JSON :rfc:`4627`. 534/10000 · 534
13 ../../protocols/rpc.rst:34
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The eXternal Data Representation (XDR) Standard, defined in :rfc:`1832` is an early specification that describes how information exchanged during Remote Procedure Calls should be encoded before being transmitted through a network. Since the transport service enables transfering a block of bytes (with the connectionless service) or a stream of bytes (by using the connection-oriented service), XDR maps each datatype onto a sequence of bytes. The caller encodes each data in the appropriate sequence and the callee decodes the received information. Here are a few examples extracted from :rfc:`1832` to illustrate how this encoding/decoding can be performed. 659/10000 · 659
14 ../../protocols/rpc.rst:36
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — For basic data types, :rfc:`1832` simply maps their representation into a sequence of bytes. For example a 32 bits integer is transmitted as follows (with the most significant byte first, which corresponds to big-endian encoding). 230/10000 · 230
15 ../../protocols/rpc.rst:43
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — XDR also supports 64 bits integers and booleans. The booleans are mapped onto integers (`0` for `false` and `1` for `true`). For the floating point numbers, the encoding defined in the IEEE standard is used. 207/10000 · 207
16 ../../protocols/rpc.rst:50
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In this representation, the first bit (`S`) is the sign (`0` represents positive). The next 11 bits represent the exponent of the number (`E`), in base 2, and the remaining 52 bits are the fractional part of the number (`F`). The floating point number that corresponds to this representation is :math:`(-1)^{S} \times 2^{E-1023} \times 1.F`. XDR also allows encoding complex data types. A first example is the string of bytes. A string of bytes is composed of two parts : a length (encoded as an integer) and a sequence of bytes. For performance reasons, the encoding of a string is aligned to 32 bits boundaries. This implies that some padding bytes may be inserted during the encoding operation is the length of the string is not a multiple of 4. The structure of the string is shown below (source :rfc:`1832`). 813/10000 · 813
17 ../../protocols/rpc.rst:58
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In some situations, it is necessary to encode fixed or variable length arrays. XDR :rfc:`1832` supports such arrays. For example, the encoding below corresponds to a variable length array containing n elements. The encoded representation starts with an integer that contains the number of elements and follows with all elements in sequence. It is also possible to encode a fixed-length array. In this case, the first integer (the `n` field) is missing. 452/10000 · 452
18 ../../protocols/rpc.rst:65
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — XDR also supports the definition of unions, structures, ... Additional details are provided in :rfc:`1832`. 107/10000 · 107
19 ../../protocols/rpc.rst:67
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A second popular method to encode data is the JavaScript Object Notation (JSON). This syntax was initially defined to allow applications written in JavaScript to exchange data, but it has now wider usages. JSON :rfc:`4627` is a text-based representation. The simplest data type is the integer. It is represented as a sequence of digits in ASCII. Strings can also be encoding by using JSON. A JSON string always starts and ends with a quote character (`"`) as in the C language. As in the C language, some characters (like `"` or `\\`) must be escaped if they appear in a string. :rfc:`4627` describes this in details. Booleans are also supported by using the strings `false` and `true`. Like XDR, JSON supports more complex data types. A structure or object is defined as a comma separated list of elements enclosed in curly brackets. :rfc:`4627` provides the following example as an illustration. 897/10000 · 897
20 ../../protocols/rpc.rst:86
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — This object has one field named `Image`. It has five attributes. The first one, `Width`, is an integer set to 800. The third one is a string. The fourth attribute, `Thumbnail` is also an object composed of three different attributes, one string and two integers. JSON can also be used to encode arrays or lists. In this case, square brackets are used as delimiters. The snippet below shows an array which contains the prime integers that are smaller than ten. 459/10000 · 459
21 ../../protocols/rpc.rst:94
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Compared with XDR, the main advantage of JSON is that the transfer syntax is easily readable by a human. However, this comes at the expense of a less compact encoding. Some data encoded in JSON will usually take more space than when it is encoded with XDR. More compact encoding schemes have been defined, see e.g. [BH2013]_ and the references therein. 352/10000 · 352
22 ../../protocols/rpc.rst:98
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Reaching the callee 19/10000 · 19
23 ../../protocols/rpc.rst:100
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The second sub-problem is how to reach the callee. A simple solution to this problem is to make sure that the callee listens on a specific port on the remote machine and then exchange information with this server process. This is the solution chosen for JSON-RPC [JSON-RPC2]_. JSON-RPC can be used over the connectionless or the connection-oriented transport service. A JSON-RPC request contains the following fields: 417/10000 · 417
24 ../../protocols/rpc.rst:102
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `jsonrpc`: a string indicating the version of the protocol used. This is important to allow the protocol to evolve in the future. 129/10000 · 129
25 ../../protocols/rpc.rst:103
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `method`: a string that contains the name of the procedure which is invoked 75/10000 · 75
26 ../../protocols/rpc.rst:104
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `params`: a structure that contains the values of the parameters that are passed to the method 94/10000 · 94
27 ../../protocols/rpc.rst:105
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `id`: an identifier chosen by the caller 40/10000 · 40
28 ../../protocols/rpc.rst:107
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The JSON-RPC is encoded as a JSON object. For example, the example below shows an invocation of a method called `sum` with `1` and `3` as parameters. 149/10000 · 149
29 ../../protocols/rpc.rst:113
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Upon reception of this JSON structure, the callee parses the object, locates the corresponding method and passes the parameters. This method returns a response which is also encoded as a JSON structure. This response contains the following fields: 247/10000 · 247
30 ../../protocols/rpc.rst:115
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `jsonrpc`: a string indicating the version of the protocol used to encode the response 86/10000 · 86