The translation has come to an end.

247 strings / 11628 words

Translation Source string Target string
cnp3-ebook/principles/transport — Czech
This is an unpolished draft of the third edition of this e-book. If you find any error or have suggestions to improve the text, please create an issue via https://github.com/CNP3/ebook/issues?milestone=3 or help us by providing pull requests to close the existing issues.
 
cnp3-ebook/principles/transport — Czech
Applications
 
cnp3-ebook/principles/transport — Czech
Networked applications do not exchange random messages. In order to ensure that the server is able to understand the queries sent by a client, and also that the client is able to understand the responses sent by the server, they must both agree on a set of syntactical and semantic rules. These rules define the format of the messages exchanged as well as their ordering. This set of rules is called an application-level `protocol`.
 
cnp3-ebook/principles/transport — French
Networked applications do not exchange random messages. In order to ensure that the server is able to understand the queries sent by a client, and also that the client is able to understand the responses sent by the server, they must both agree on a set of syntactical and semantic rules. These rules define the format of the messages exchanged as well as their ordering. This set of rules is called an application-level `protocol`.
 
cnp3-ebook/principles/transport — Czech
An `application-level protocol` is similar to a structured conversation between humans. Assume that Alice wants to know the current time but does not have a watch. If Bob passes close by, the following conversation could take place :
 
cnp3-ebook/principles/transport — French
An `application-level protocol` is similar to a structured conversation between humans. Assume that Alice wants to know the current time but does not have a watch. If Bob passes close by, the following conversation could take place :
 
cnp3-ebook/principles/transport — Czech
Alice : `Hello`
 
cnp3-ebook/principles/transport — Czech
Bob : `Hello`
 
cnp3-ebook/principles/transport — Czech
Alice : `What time is it ?`
 
cnp3-ebook/principles/transport — Czech
Bob : `11:55`
 
cnp3-ebook/principles/transport — Czech
Alice : `Thank you`
 
cnp3-ebook/principles/transport — Czech
Bob : `You're welcome`
 
cnp3-ebook/principles/transport — Czech
Such a conversation succeeds if both Alice and Bob speak the same language. If Alice meets Tchang who only speaks Chinese, she won't be able to ask him the current time. A conversation between humans can be more complex. For example, assume that Bob is a security guard whose duty is to only allow trusted secret agents to enter a meeting room. If all agents know a secret password, the conversation between Bob and Trudy could be as follows :
 
cnp3-ebook/principles/transport — French
Such a conversation succeeds if both Alice and Bob speak the same language. If Alice meets Tchang who only speaks Chinese, she won't be able to ask him the current time. A conversation between humans can be more complex. For example, assume that Bob is a security guard whose duty is to only allow trusted secret agents to enter a meeting room. If all agents know a secret password, the conversation between Bob and Trudy could be as follows :
 
cnp3-ebook/principles/transport — Czech
Bob : `What is the secret password ?`
 
cnp3-ebook/principles/transport — French
Bob : `What is the secret password ?`
 
cnp3-ebook/principles/transport — Czech
Trudy : `1234`
 
cnp3-ebook/principles/transport — Czech
Bob : `This is the correct password, you're welcome`
 
cnp3-ebook/principles/transport — French
Bob : `This is the correct password, you're welcome`
 
cnp3-ebook/principles/transport — Czech
If Alice wants to enter the meeting room but does not know the password, her conversation could be as follows :
 
cnp3-ebook/principles/transport — French
If Alice wants to enter the meeting room but does not know the password, her conversation could be as follows :
 
cnp3-ebook/principles/transport — Czech
Alice : `3.1415`
 
cnp3-ebook/principles/transport — Czech
Bob : `This is not the correct password.`
 
cnp3-ebook/principles/transport — Czech
Let us first discuss the syntactical rules. We will later explain how the information flow can be organized by analyzing real networked applications.
 
cnp3-ebook/principles/transport — French
Let us first discuss the syntactical rules. We will later explain how the information flow can be organized by analyzing real networked applications.
 
cnp3-ebook/principles/transport — Czech
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 :
 
cnp3-ebook/principles/transport — French
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 :
 
cnp3-ebook/principles/transport — Czech
`A` : `1000011b`
 
cnp3-ebook/principles/transport — French
`A` : `1000011b`
 
cnp3-ebook/principles/transport — Czech
`0` : `0110000b`
 
cnp3-ebook/principles/transport — French
`0` : `0110000b`
 
cnp3-ebook/principles/transport — Czech
`z` : `1111010b`
 
cnp3-ebook/principles/transport — French
`z` : `1111010b`
 
cnp3-ebook/principles/transport — Czech
`@` : `1000000b`
 
cnp3-ebook/principles/transport — French
`@` : `1000000b`
 
cnp3-ebook/principles/transport — Czech
`space` : `0100000b`
 
cnp3-ebook/principles/transport — French
`space` : `0100000b`
 
cnp3-ebook/principles/transport — Czech
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.
 
cnp3-ebook/principles/transport — French
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.
 
cnp3-ebook/principles/transport — Czech
`carriage return` (`CR`) : `0001101b`
 
cnp3-ebook/principles/transport — French
`carriage return` (`CR`) : `0001101b`
 
cnp3-ebook/principles/transport — Czech
`line feed` (`LF`) : `0001010b`
 
cnp3-ebook/principles/transport — French
`line feed` (`LF`) : `0001010b`
 
cnp3-ebook/principles/transport — Czech
`Bell`: `0000111b`
 
cnp3-ebook/principles/transport — French
`Bell`: `0000111b`
 
cnp3-ebook/principles/transport — Czech
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.
 
cnp3-ebook/principles/transport — French
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.
 
cnp3-ebook/principles/transport — Czech
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.
 
cnp3-ebook/principles/transport — French
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.
 
cnp3-ebook/principles/transport — Czech
A simple BNF specification
 
cnp3-ebook/principles/transport — French
A simple BNF specification
 
cnp3-ebook/principles/transport — Czech
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.
 
cnp3-ebook/principles/transport — French
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.
 
cnp3-ebook/principles/transport — Czech
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 :
 
cnp3-ebook/principles/transport — Czech
send the most significant byte followed by the least significant byte
 
cnp3-ebook/principles/transport — Czech
send the least significant byte followed by the most significant byte
 
cnp3-ebook/principles/transport — Czech
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.
 
cnp3-ebook/principles/transport — French
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.
 
cnp3-ebook/principles/transport — Czech
Besides 16 and 32 bit words, some applications need to exchange data structures containing bit fields of various lengths. For example, a message may be composed of a 16 bits field followed by eight, one bit flags, a 24 bits field and two 8 bits bytes. Internet protocol specifications will define such a message by using a representation such as the one below. In this representation, each line corresponds to 32 bits and the vertical lines are used to delineate fields. The numbers above the lines indicate the bit positions in the 32-bits word, with the high order bit at position `0`.
 
cnp3-ebook/principles/transport — Czech
Message format
 
cnp3-ebook/principles/transport — Czech
The message mentioned above will be transmitted starting from the upper 32-bits word in network byte order. The first field is encoded in 16 bits. It is followed by eight one bit flags (`A-H`), a 24 bits field whose high order byte is shown in the first line and the two low order bytes appear in the second line followed by two one byte fields. This ASCII representation is frequently used when defining binary protocols. We will use it for all the binary protocols that are discussed in this book.
 
cnp3-ebook/principles/transport — Czech
The peer-to-peer model emerged during the last ten years as another possible architecture for networked applications. In the traditional client-server model, hosts act either as servers or as clients and a server serves a large number of clients. In the peer-to-peer model, all hosts act as both servers and clients and they play both roles. The peer-to-peer model has been used to develop various networked applications, ranging from Internet telephony to file sharing or Internet-wide filesystems. A detailed description of peer-to-peer applications may be found in [BYL2008]_. Surveys of peer-to-peer protocols and applications may be found in [AS2004]_ and [LCP2005]_.
 
cnp3-ebook/principles/transport — French
The peer-to-peer model emerged during the last ten years as another possible architecture for networked applications. In the traditional client-server model, hosts act either as servers or as clients and a server serves a large number of clients. In the peer-to-peer model, all hosts act as both servers and clients and they play both roles. The peer-to-peer model has been used to develop various networked applications, ranging from Internet telephony to file sharing or Internet-wide filesystems. A detailed description of peer-to-peer applications may be found in [BYL2008]_. Surveys of peer-to-peer protocols and applications may be found in [AS2004]_ and [LCP2005]_.
 
cnp3-ebook/principles/transport — Czech
The transport layer
 
cnp3-ebook/principles/transport — Czech
The network layer ensures the delivery of packets on a hop-by-hop basis through intermediate nodes. As such, it provides a service to the upper layer. In practice, this layer is usually the `transport layer` that improves the service provided by the `network layer` to make it usable by applications.
 
cnp3-ebook/principles/transport — French
The network layer ensures the delivery of packets on a hop-by-hop basis through intermediate nodes. As such, it provides a service to the upper layer. In practice, this layer is usually the `transport layer` that improves the service provided by the `network layer` to make it usable by applications.
 
cnp3-ebook/principles/transport — Czech
Most networks use a datagram organization and provide a simple service which is called the `connectionless service`.
 
cnp3-ebook/principles/transport — French
Most networks use a datagram organization and provide a simple service which is called the `connectionless service`.
 
cnp3-ebook/principles/transport — Czech
The figure below provides a representation of the connectionless service as a `time-sequence diagram`. The user on the left, having address `S`, issues a `Data.request` primitive containing Service Data Unit (SDU) `M` that must be delivered by the service provider to destination `D`. The dashed line between the two primitives indicates that the `Data.indication` primitive that is delivered to the user on the right corresponds to the `Data.request` primitive sent by the user on the left.
 
cnp3-ebook/principles/transport — French
The figure below provides a representation of the connectionless service as a `time-sequence diagram`. The user on the left, having address `S`, issues a `Data.request` primitive containing Service Data Unit (SDU) `M` that must be delivered by the service provider to destination `D`. The dashed line between the two primitives indicates that the `Data.indication` primitive that is delivered to the user on the right corresponds to the `Data.request` primitive sent by the user on the left.
 
cnp3-ebook/principles/transport — Czech
There are several possible implementations of the connectionless service. Before studying these realizations, it is useful to discuss the possible characteristics of the connectionless service. A `reliable connectionless service` is a service where the service provider guarantees that all SDUs submitted in `Data.requests` by a user will eventually be delivered to their destination. Such a service would be very useful for users, but guaranteeing perfect delivery is difficult in practice. For this reason, network layers usually support an `unreliable connectionless service`.
 
cnp3-ebook/principles/transport — French
There are several possible implementations of the connectionless service. Before studying these realizations, it is useful to discuss the possible characteristics of the connectionless service. A `reliable connectionless service` is a service where the service provider guarantees that all SDUs submitted in `Data.requests` by a user will eventually be delivered to their destination. Such a service would be very useful for users, but guaranteeing perfect delivery is difficult in practice. For this reason, network layers usually support an `unreliable connectionless service`.
 
cnp3-ebook/principles/transport — Czech
An `unreliable connectionless` service may suffer from various types of problems compared to a `reliable connectionless service`. First of all, an `unreliable connectionless service` does not guarantee the delivery of all SDUs. This can be expressed graphically by using the time-sequence diagram below.
 
cnp3-ebook/principles/transport — French
An `unreliable connectionless` service may suffer from various types of problems compared to a `reliable connectionless service`. First of all, an `unreliable connectionless service` does not guarantee the delivery of all SDUs. This can be expressed graphically by using the time-sequence diagram below.
 
cnp3-ebook/principles/transport — Czech
In practice, an `unreliable connectionless service` will usually deliver a large fraction of the SDUs. However, since the delivery of SDUs is not guaranteed, the user must be able to recover from the loss of any SDU.
 
cnp3-ebook/principles/transport — French
In practice, an `unreliable connectionless service` will usually deliver a large fraction of the SDUs. However, since the delivery of SDUs is not guaranteed, the user must be able to recover from the loss of any SDU.
 
cnp3-ebook/principles/transport — Czech
A second imperfection that may affect an `unreliable connectionless service` is that it may duplicate SDUs. Some packets may be duplicated in a network and be delivered twice to their destination. This is illustrated by the time-sequence diagram below.
 
cnp3-ebook/principles/transport — French
A second imperfection that may affect an `unreliable connectionless service` is that it may duplicate SDUs. Some packets may be duplicated in a network and be delivered twice to their destination. This is illustrated by the time-sequence diagram below.
 
cnp3-ebook/principles/transport — Czech
Finally, some unreliable connectionless service providers may deliver to a destination a different SDU than the one that was supplied in the `Data.request`. This is illustrated in the figure below.
 
cnp3-ebook/principles/transport — French
Finally, some unreliable connectionless service providers may deliver to a destination a different SDU than the one that was supplied in the `Data.request`. This is illustrated in the figure below.
 
cnp3-ebook/principles/transport — Czech
As the transport layer is built on top of the network layer, it is important to know the key features of the network layer service. In this book, we only consider the `connectionless network layer service` which is the most widespread. Its main characteristics are :
 
cnp3-ebook/principles/transport — French
As the transport layer is built on top of the network layer, it is important to know the key features of the network layer service. In this book, we only consider the `connectionless network layer service` which is the most widespread. Its main characteristics are :
 
cnp3-ebook/principles/transport — Czech
the `connectionless network layer service` can only transfer SDUs of *limited size*
 
cnp3-ebook/principles/transport — French
the `connectionless network layer service` can only transfer SDUs of *limited size*
 
cnp3-ebook/principles/transport — Czech
the `connectionless network layer service` may discard SDUs
 
cnp3-ebook/principles/transport — French
the `connectionless network layer service` may discard SDUs
 
cnp3-ebook/principles/transport — Czech
the `connectionless network layer service` may corrupt SDUs
 
cnp3-ebook/principles/transport — French
the `connectionless network layer service` may corrupt SDUs
 
cnp3-ebook/principles/transport — Czech
the `connectionless network layer service` may delay, reorder or even duplicate SDUs
 
cnp3-ebook/principles/transport — French
the `connectionless network layer service` may delay, reorder or even duplicate SDUs
 
cnp3-ebook/principles/transport — Czech
Transport layer services
 
cnp3-ebook/principles/transport — French
Transport layer services
 
cnp3-ebook/principles/transport — Czech
When two applications need to communicate, they need to structure their exchange of information. Structuring this exchange of information requires solving two different problems. The first problem is how to represent the information being exchanged knowing that the two applications may be running on hosts that use different operating systems, different processors and have different conventions to store information. This requires a common syntax to transfer the information between the two applications. For this chapter, let us assume that this syntax exists and that the two applications simply need to exchange bytes. We will discuss later how more complex data can be encoded as sequences of bytes to be exchanged. The second problem is how to organize the interactions between the application and the underlying network. From the application's viewpoint, the `network` will appear as the `transport layer` service. This `transport layer` can provide three types of services to the applications :
 
cnp3-ebook/principles/transport — French
When two applications need to communicate, they need to structure their exchange of information. Structuring this exchange of information requires solving two different problems. The first problem is how to represent the information being exchanged knowing that the two applications may be running on hosts that use different operating systems, different processors and have different conventions to store information. This requires a common syntax to transfer the information between the two applications. For this chapter, let us assume that this syntax exists and that the two applications simply need to exchange bytes. We will discuss later how more complex data can be encoded as sequences of bytes to be exchanged. The second problem is how to organize the interactions between the application and the underlying network. From the application's viewpoint, the `network` will appear as the `transport layer` service. This `transport layer` can provide three types of services to the applications :
 
cnp3-ebook/principles/transport — Czech
the `connectionless service`
 
cnp3-ebook/principles/transport — French
the `connectionless service`
 
cnp3-ebook/principles/transport — Czech
the `connection oriented service`
 
cnp3-ebook/principles/transport — French
the `connection oriented service`
 
cnp3-ebook/principles/transport — Czech
the `request-response service`
 
cnp3-ebook/principles/transport — French
the `request-response service`