2. cnp3-ebook
3. principles/transport
4. English
5. Zen

23 ../../principles/transport.rst:71
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Organization of the information flow. For many applications, the flow of information must be structured and there are precedence relationships between the different types of information. In the time example above, Alice must greet Bob before asking for the current time. Alice would not ask for the current time first and greet Bob afterwards. Such precedence relationships exist in networked applications as well. For example, a server must receive a username and a valid password before accepting more complex commands from its clients. 538/10000 · 538
24 ../../principles/transport.rst:73
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Let us first discuss the syntactical rules. We will later explain how the information flow can be organized by analyzing real networked applications. 149/10000 · 149
25 ../../principles/transport.rst:75
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Application-layer protocols exchange two types of messages. Some protocols such as those used to support electronic mail exchange messages expressed as strings or lines of characters. As the transport layer allows hosts to exchange bytes, they need to agree on a common representation of the characters. The first and simplest method to encode characters is to use the :term:`ASCII` table. :rfc:`20` provides the ASCII table that is used by many protocols on the Internet. For example, the table defines the following binary representations : 542/10000 · 542
26 ../../principles/transport.rst:77
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `A` : `1000011b` 16/10000 · 16
27 ../../principles/transport.rst:78
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `0` : `0110000b` 16/10000 · 16
28 ../../principles/transport.rst:79
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `z` : `1111010b` 16/10000 · 16
29 ../../principles/transport.rst:80
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `@` : `1000000b` 16/10000 · 16
30 ../../principles/transport.rst:81
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `space` : `0100000b` 20/10000 · 20
31 ../../principles/transport.rst:83
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In addition, the :term:`ASCII` table also defines several non-printable or control characters. These characters were designed to allow an application to control a printer or a terminal. These control characters include `CR` and `LF`, that are used to terminate a line, and the `Bell` character which causes the terminal to emit a sound. 336/10000 · 336
32 ../../principles/transport.rst:85
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `carriage return` (`CR`) : `0001101b` 37/10000 · 37
33 ../../principles/transport.rst:86
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `line feed` (`LF`) : `0001010b` 31/10000 · 31
34 ../../principles/transport.rst:87
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `Bell`: `0000111b` 18/10000 · 18
35 ../../principles/transport.rst:89
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The :term:`ASCII` characters are encoded as a seven bits field, but transmitted as an eight-bits byte whose high order bit is usually set to `0`. Bytes are always transmitted starting from the high order or most significant bit. 228/10000 · 228
36 ../../principles/transport.rst:91
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Most applications exchange strings that are composed of fixed or variable numbers of characters. A common solution to define the character strings that are acceptable is to define them as a grammar using a Backus-Naur Form (:term:`BNF`) such as the Augmented BNF defined in :rfc:`5234`. A BNF is a set of production rules that generate all valid character strings. For example, consider a networked application that uses two commands, where the user can supply a username and a password. The BNF for this application could be defined as shown in the figure below. 563/10000 · 563
37 ../../principles/transport.rst:97
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A simple BNF specification 26/10000 · 26
38 ../../principles/transport.rst:99
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The example above defines several terminals and two commands : `usercommand` and `passwordcommand`. The `ALPHA` terminal contains all letters in upper and lower case. In the `ALPHA` rule, `%x41` corresponds to ASCII character code 41 in hexadecimal, i.e. capital `A`. The `CR` and `LF` terminals correspond to the carriage return and linefeed control characters. The `CRLF` rule concatenates these two terminals to match the standard end of line termination. The `DIGIT` terminal contains all digits. The `SP` terminal corresponds to the white space characters. The `usercommand` is composed of two strings separated by white space. In the ABNF rules that define the messages used by Internet applications, the commands are case-insensitive. The rule `"user"` corresponds to all possible cases of the letters that compose the word between brackets, e.g. `user`, `uSeR`, `USER`, `usER`, ... A `username` contains at least one letter and up to 8 letters. User names are case-sensitive as they are not defined as a string between brackets. The `password` rule indicates that a password starts with a letter and can contain any number of letters or digits. The white space and the control characters cannot appear in a `password` defined by the above rule. 1253/10000 · 1253
39 ../../principles/transport.rst:101
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Besides character strings, some applications also need to exchange 16 bits and 32 bits fields such as integers. A naive solution would have been to send the 16- or 32-bits field as it is encoded in the host's memory. Unfortunately, there are different methods to store 16- or 32-bits fields in memory. Some CPUs store the most significant byte of a 16-bits field in the first address of the field while others store the least significant byte at this location. When networked applications running on different CPUs exchange 16 bits fields, there are two possibilities to transfer them over the transport service : 613/10000 · 613
40 ../../principles/transport.rst:103
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — send the most significant byte followed by the least significant byte 69/10000 · 69
41 ../../principles/transport.rst:104
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — send the least significant byte followed by the most significant byte 69/10000 · 69
42 ../../principles/transport.rst:106
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The first possibility was named `big-endian` in a note written by Cohen [Cohen1980]_ while the second was named `little-endian`. Vendors of CPUs that used `big-endian` in memory insisted on using `big-endian` encoding in networked applications while vendors of CPUs that used `little-endian` recommended the opposite. Several studies were written on the relative merits of each type of encoding, but the discussion became almost a religious issue [Cohen1980]_. Eventually, the Internet chose the `big-endian` encoding, i.e. multi-byte fields are always transmitted by sending the most significant byte first, :rfc:`791` refers to this encoding as the :term:`network-byte order`. Most libraries [#fhtonl]_ used to write networked applications contain functions to convert multi-byte fields from memory to the network byte order and the reverse. 844/10000 · 844