msgid "" msgstr "" "Project-Id-Version: French (cnp3-ebook)\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2026-04-19 06:44+0200\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: French \n" "Language: fr\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=2; plural=n > 1;\n" "X-Generator: Weblate 5.14.3\n" #: ../../principles/transport.rst:25 msgid "" "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`." msgstr "" #: ../../principles/transport.rst:27 msgid "" "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 :" msgstr "" #: ../../principles/transport.rst:41 msgid "" "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 :" msgstr "" #: ../../principles/transport.rst:43 #: ../../principles/transport.rst:49 msgid "Bob : `What is the secret password ?`" msgstr "" #: ../../principles/transport.rst:45 msgid "Bob : `This is the correct password, you're welcome`" msgstr "" #: ../../principles/transport.rst:47 msgid "" "If Alice wants to enter the meeting room but does not know the password, her " "conversation could be as follows :" msgstr "" #: ../../principles/transport.rst:58 msgid "" "Let us first discuss the syntactical rules. We will later explain how the " "information flow can be organized by analyzing real networked applications." msgstr "" #: ../../principles/transport.rst:60 msgid "" "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 :" msgstr "" #: ../../principles/transport.rst:62 msgid "`A` : `1000011b`" msgstr "" #: ../../principles/transport.rst:63 msgid "`0` : `0110000b`" msgstr "" #: ../../principles/transport.rst:64 msgid "`z` : `1111010b`" msgstr "" #: ../../principles/transport.rst:65 msgid "`@` : `1000000b`" msgstr "" #: ../../principles/transport.rst:66 msgid "`space` : `0100000b`" msgstr "" #: ../../principles/transport.rst:68 msgid "" "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." msgstr "" #: ../../principles/transport.rst:70 msgid "`carriage return` (`CR`) : `0001101b`" msgstr "" #: ../../principles/transport.rst:71 msgid "`line feed` (`LF`) : `0001010b`" msgstr "" #: ../../principles/transport.rst:72 msgid "`Bell`: `0000111b`" msgstr "" #: ../../principles/transport.rst:74 msgid "" "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." msgstr "" #: ../../principles/transport.rst:76 msgid "" "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." msgstr "" #: ../../principles/transport.rst:82 msgid "A simple BNF specification" msgstr "" #: ../../principles/transport.rst:84 #, python-format msgid "" "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." msgstr "" #: ../../principles/transport.rst:91 msgid "" "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." msgstr "" #: ../../principles/transport.rst:105 msgid "" "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]_." msgstr "" #: ../../principles/transport.rst:115 msgid "" "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." msgstr "" #: ../../principles/transport.rst:125 msgid "" "Most networks use a datagram organization and provide a simple service which " "is called the `connectionless service`." msgstr "" #: ../../principles/transport.rst:127 msgid "" "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." msgstr "" #: ../../principles/transport.rst:146 msgid "" "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`." msgstr "" #: ../../principles/transport.rst:148 msgid "" "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." msgstr "" #: ../../principles/transport.rst:165 msgid "" "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." msgstr "" #: ../../principles/transport.rst:167 msgid "" "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." msgstr "" #: ../../principles/transport.rst:185 msgid "" "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." msgstr "" #: ../../principles/transport.rst:201 msgid "" "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 :" msgstr "" #: ../../principles/transport.rst:203 msgid "" "the `connectionless network layer service` can only transfer SDUs of *" "limited size*" msgstr "" #: ../../principles/transport.rst:204 msgid "the `connectionless network layer service` may discard SDUs" msgstr "" #: ../../principles/transport.rst:205 msgid "the `connectionless network layer service` may corrupt SDUs" msgstr "" #: ../../principles/transport.rst:206 msgid "" "the `connectionless network layer service` may delay, reorder or even " "duplicate SDUs" msgstr "" #: ../../principles/transport.rst:219 msgid "Transport layer services" msgstr "" #: ../../principles/transport.rst:222 msgid "" "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 :" msgstr "" #: ../../principles/transport.rst:224 msgid "the `connectionless service`" msgstr "" #: ../../principles/transport.rst:225 msgid "the `connection oriented service`" msgstr "" #: ../../principles/transport.rst:226 msgid "the `request-response service`" msgstr "" #: ../../principles/transport.rst:229 msgid "The connectionless service" msgstr "" #: ../../principles/transport.rst:231 msgid "" "The `connectionless service` that we have described earlier is frequently " "used by users who need to exchange small SDUs. It can be easily built on top " "of the connectionless network layer service that we have described earlier. " "Users needing to either send or receive several different and potentially " "large SDUs, or who need structured exchanges often prefer the `connection-" "oriented service`." msgstr "" #: ../../principles/transport.rst:234 msgid "The connection-oriented service" msgstr "" #: ../../principles/transport.rst:241 msgid "" "The establishment of a connection can be modeled by using four primitives : " "`Connect.request`, `Connect.indication`, `Connect.response` and " "`Connect.confirm`. The `Connect.request` primitive is used to request the " "establishment of a connection. The main parameter of this primitive is the " "`address` of the destination user. The service provider delivers a " "`Connect.indication` primitive to inform the destination user of the " "connection attempt. If it accepts to establish a connection, it responds " "with a `Connect.response` primitive. At this point, the connection is " "considered to be established and the destination user can start sending SDUs " "over the connection. The service provider processes the `Connect.response` " "and will deliver a `Connect.confirm` to the user who initiated the " "connection. The delivery of this primitive terminates the connection " "establishment phase. At this point, the connection is considered to be open " "and both users can send SDUs. A successful connection establishment is " "illustrated below." msgstr "" #: ../../principles/transport.rst:262 msgid "" "The example above shows a successful connection establishment. However, in " "practice not all connections are successfully established. One reason is " "that the destination user may not agree, for policy or performance reasons, " "to establish a connection with the initiating user at this time. In this " "case, the destination user responds to the `Connect.indication` primitive by " "a `Disconnect.request` primitive that contains a parameter to indicate why " "the connection has been refused. The service provider will then deliver a " "`Disconnect.indication` primitive to inform the initiating user." msgstr "" #: ../../principles/transport.rst:283 msgid "" "A second reason is when the service provider is unable to reach the " "destination user. This might happen because the destination user is not " "currently attached to the network or due to congestion. In these cases, the " "service provider responds to the `Connect.request` with a " "`Disconnect.indication` primitive whose `reason` parameter contains " "additional information about the failure of the connection." msgstr "" #: ../../principles/transport.rst:303 msgid "" "Once the connection has been established, the service provider supplies two " "data streams to the communicating users. The first data stream can be used " "by the initiating user to send SDUs. The second data stream allows the " "responding user to send SDUs to the initiating user. The data streams can be " "organized in different ways. A first organization is the `message-mode` " "transfer. With the `message-mode` transfer, the service provider guarantees " "that one and only one `Data.indication` will be delivered to the endpoint of " "the data stream for each `Data.request` primitive issued by the other " "endpoint. The `message-mode` transfer is illustrated in the figure below. " "The main advantage of the `message-transfer` mode is that the recipient " "receives exactly the SDUs that were sent by the other user. If each SDU " "contains a command, the receiving user can process each command as soon as " "it receives a SDU." msgstr "" #: ../../principles/transport.rst:338 msgid "" "Unfortunately, the `message-mode` transfer is not widely used on the " "Internet. On the Internet, the most popular connection-oriented service " "transfers SDUs in `stream-mode`. With the `stream-mode`, the service " "provider supplies a byte stream that links the two communicating users. The " "sending user sends bytes by using `Data.request` primitives that contain " "sequences of bytes as SDUs. The service provider delivers SDUs containing " "consecutive bytes to the receiving user by using `Data.indication` " "primitives. The service provider ensures that all the bytes sent at one end " "of the stream are delivered correctly in the same order at the other " "endpoint. However, the service provider does not attempt to preserve the " "boundaries of the SDUs. There is no relation enforced by the service " "provider between the number of `Data.request` and the number of " "`Data.indication` primitives. The `stream-mode` is illustrated in the figure " "below. In practice, a consequence of the utilization of the `stream-mode` is " "that if the users want to exchange structured SDUs, they will need to " "provide the mechanisms that allow the receiving user to separate successive " "SDUs in the byte stream that it receives. Application layer protocols often " "use specific delimiters such as the end of line character to delineate SDUs " "in a bytestream." msgstr "" #: ../../principles/transport.rst:409 msgid "" "An abrupt connection release can also be triggered by one of the users. If a " "user needs, for any reason, to terminate a connection quickly, it can issue " "a `Disconnect.request` primitive and to request an abrupt release. The " "service provider will process the request, stop the two data streams and " "deliver the `Disconnect.indication` primitive to the remote user as soon as " "possible. As illustrated in the figure below, this abrupt connection release " "may cause losses of SDUs." msgstr "" #: ../../principles/transport.rst:447 msgid "" "To ensure a reliable delivery of the SDUs sent by each user over a " "connection, we need to consider the two streams that compose a connection as " "independent. A user should be able to release the stream that it uses to " "send SDUs once it has sent all the SDUs that it planned to send over this " "connection, but still continue to receive SDUs over the opposite stream. " "This `graceful` connection release is usually performed as shown in the " "figure below. One user issues a `Disconnect.request` primitive to its " "provider once it has issued all its `Data.request` primitives. The service " "provider will wait until all `Data.indication` primitives have been " "delivered to the receiving user before issuing the `Disconnnect.indication` " "primitive. This primitive informs the receiving user that it will no longer " "receive SDUs over this connection, but it is still able to issue " "`Data.request` primitives on the stream in the opposite direction. Once the " "user has issued all of its `Data.request` primitives, it issues a " "`Disconnnect.request` primitive to request the termination of the remaining " "stream. The service provider will process the request and deliver the " "corresponding `Disconnect.indication` to the other user once it has " "delivered all the pending `Data.indication` primitives. At this point, all " "data has been delivered, the two streams have been released successfully and " "the connection is completely closed." msgstr "" #: ../../principles/transport.rst:487 msgid "Reliability of the connection-oriented service" msgstr "" #: ../../principles/transport.rst:494 msgid "The request-response service" msgstr "" #: ../../principles/transport.rst:498 msgid "" "The `request-response service` is a compromise between the `connectionless " "service` and the `connection-oriented service`. Many applications need to " "send a small amount of data and receive a small amount of information back. " "This is similar to procedure calls in programming languages. A call to a " "procedure takes a few arguments and returns a simple answer. In a network, " "it is sometimes useful to execute a procedure on a different host and " "receive the result of the computation. Executing a procedure on another host " "is often called Remote Procedure Call. It is possible to use the `" "connectionless service` for this application. However, since this service is " "usually unreliable, this would force the application to deal with any type " "of error that could occur. Using the `connection oriented service` is " "another alternative. This service ensures the reliable delivery of the data, " "but a connection must be created before the beginning of the data transfer. " "This overhead can be important for applications that only exchange a small " "amount of data." msgstr "" #: ../../principles/transport.rst:500 msgid "" "The `request-response service` allows to efficiently exchange small amounts " "of information in a request and associate it with the corresponding " "response. This service can be depicted by using the time-sequence diagram " "below." msgstr "" #: ../../principles/transport.rst:519 msgid "Services and layers" msgstr "" #: ../../principles/transport.rst:521 msgid "" "In the previous sections, we have described services that are provided by " "the transport layer. However, it is important to note that the notion of " "service is more general than in the transport layer. As explained earlier, " "the network layer also provides a service, which in most networks is an " "unreliable connectionless service. There are network layers that provide a " "connection-oriented service. Similarly, the datalink layer also provides " "services. Some datalink layers will provide a connectionless service. This " "will be the case in Local Area Networks for examples. Other datalink layers, " "e.g. in public networks, provide a connection oriented service." msgstr "" #: ../../principles/transport.rst:536 msgid "" "To deal with these issues, the transport layer includes several mechanisms " "that depend on the service that it provides. It interacts with both the " "applications and the underlying network layer." msgstr "" #: ../../principles/transport.rst:542 msgid "" "Interactions between the transport layer, its user, and its network layer " "provider" msgstr "" #: ../../principles/transport.rst:544 msgid "" "We have already described in the datalink layers mechanisms to deal with " "data losses and transmission errors. These techniques are also used in the " "transport layer." msgstr "" #: ../../principles/transport.rst:548 msgid "Connectionless transport" msgstr "" #: ../../principles/transport.rst:550 msgid "" "The simplest service that can be provided in the transport layer is the " "connectionless transport service. Compared to the connectionless network " "layer service, this transport service includes two additional features :" msgstr "" #: ../../principles/transport.rst:553 msgid "" "a `multiplexing technique` that enables several applications running on one " "host to exchange information with another host" msgstr "" #: ../../principles/transport.rst:557 msgid "" "To exchange data, the transport protocol encapsulates the SDU produced by " "its user inside a `segment`. The `segment` is the unit of transfer of " "information in the transport layer. Transport layer entities always exchange " "segments. When a transport layer entity creates a segment, this segment is " "encapsulated by the network layer into a packet which contains the segment " "as its payload and a network header. The packet is then encapsulated in a " "frame to be transmitted in the datalink layer." msgstr "" #: ../../principles/transport.rst:559 msgid "" "A `segment` also contains control information, usually stored inside a " "`header` and the payload that comes from the application. To detect " "transmission errors, transport protocols rely on checksums or CRCs like the " "datalink layer protocols." msgstr "" #: ../../principles/transport.rst:563 msgid "" "The figure below shows a typical usage of port numbers. The client process " "uses port number `1234` while the server process uses port number `5678`. " "When the client sends a request, it is identified as originating from port " "number `1234` on the client host and destined to port number `5678` on the " "server host. When the server process replies to this request, the server's " "transport layer returns the reply as originating from port `5678` on the " "server host and destined to port `1234` on the client host." msgstr "" #: ../../principles/transport.rst:571 msgid "" "To support the connection-oriented service, the transport layer needs to " "include several mechanisms to enrich the connectionless network-layer " "service. We discuss these mechanisms in the following sections." msgstr "" #: ../../principles/transport.rst:575 msgid "Connection establishment" msgstr "" #: ../../principles/transport.rst:579 msgid "" "An important difference between the connectionless service and the " "connection-oriented one is that the transport entities in the latter " "maintain some state during lifetime of the connection. This state is created " "when a connection is established and is removed when it is released." msgstr "" #: ../../principles/transport.rst:608 msgid "" "Unfortunately, this scheme is not sufficient to ensure the reliability of " "the transport service. Consider for example a short-lived transport " "connection where a single, but important transfer " "(e.g. money transfer from a bank account) is sent. Such a short-lived " "connection starts with a `CR` segment acknowledged by a `CA` segment, then " "the data segment is sent, acknowledged and the connection terminates. " "Unfortunately, as the network layer service is unreliable, delays combined " "to retransmissions may lead to the situation depicted in the figure below, " "where a delayed `CR` and data segments from a former connection are accepted " "by the receiving entity as valid segments, and the corresponding data is " "delivered to the user. Duplicating SDUs is not acceptable, and the transport " "protocol must solve this problem." msgstr "" #: ../../principles/transport.rst:648 msgid "" "To avoid these duplicates, transport protocols require the network layer to " "bound the `Maximum Segment Lifetime (MSL)`. The organization of the network " "must guarantee that no segment remains in the network for longer than `MSL` " "seconds. For example, on today's Internet, `MSL` is expected to be 2 " "minutes. To avoid duplicate transport connections, transport protocol " "entities must be able to safely distinguish between a duplicate `CR` segment " "and a new `CR` segment, without forcing each transport entity to remember " "all the transport connections that it has established in the past." msgstr "" #: ../../principles/transport.rst:650 msgid "" "A classical solution to avoid remembering the previous transport connections " "to detect duplicates is to use a clock inside each transport entity. This `" "transport clock` has the following characteristics :" msgstr "" #: ../../principles/transport.rst:652 msgid "" "the `transport clock` is implemented as a `k` bits counter and its clock " "cycle is such that :math:`2^k \\times cycle >> MSL`. Furthermore, the `" "transport clock` counter is incremented every clock cycle and after each " "connection establishment. This clock is illustrated in the figure below." msgstr "" #: ../../principles/transport.rst:653 msgid "" "the `transport clock` must continue to be incremented even if the transport " "entity stops or reboots" msgstr "" #: ../../principles/transport.rst:659 msgid "Transport clock" msgstr "" #: ../../principles/transport.rst:662 msgid "" "It should be noted that `transport clocks` do not need and usually are not " "synchronized to the real-time clock. Precisely synchronizing real-time " "clocks is an interesting problem, but it is outside the scope of this " "document. See [Mills2006]_ for a detailed discussion on synchronizing the " "real-time clock." msgstr "" #: ../../principles/transport.rst:664 msgid "" "This `transport clock` can now be combined with an exchange of three " "segments, called the `three way handshake`, to detect duplicates. This `" "three way handshake` occurs as follows :" msgstr "" #: ../../principles/transport.rst:666 msgid "" "The initiating transport entity sends a `CR` segment. This segment requests " "the establishment of a transport connection. It contains a port number " "(not shown in the figure) and a sequence number (`seq=x` in the figure below)" " whose value is extracted from the `transport clock`. The transmission of " "the `CR` segment is protected by a retransmission timer." msgstr "" #: ../../principles/transport.rst:668 msgid "" "The remote transport entity processes the `CR` segment and creates state for " "the connection attempt. At this stage, the remote entity does not yet know " "whether this is a new connection attempt or a duplicate segment. It returns " "a `CA` segment that contains an acknowledgment number to confirm the " "reception of the `CR` segment (`ack=x` in the figure below) and a sequence " "number (`seq=y` in the figure below) whose value is extracted from its " "transport clock. At this stage, the connection is not yet established." msgstr "" #: ../../principles/transport.rst:670 msgid "" "The initiating entity receives the `CA` segment. The acknowledgment number " "of this segment confirms that the remote entity has correctly received the " "`CR` segment. The transport connection is considered to be established by " "the initiating entity and the numbering of the data segments starts at " "sequence number `x`. Before sending data segments, the initiating entity " "must acknowledge the received `CA` segments by sending another `CA` segment." msgstr "" #: ../../principles/transport.rst:672 msgid "" "The remote entity considers the transport connection to be established after " "having received the segment that acknowledges its `CA` segment. The " "numbering of the data segments sent by the remote entity starts at sequence " "number `y`." msgstr "" #: ../../principles/transport.rst:674 msgid "The three way handshake is illustrated in the figure below." msgstr "" #: ../../principles/transport.rst:680 msgid "Three-way handshake" msgstr "" #: ../../principles/transport.rst:682 msgid "" "Thanks to the three way handshake, transport entities avoid duplicate " "transport connections. This is illustrated by considering the three " "scenarios below." msgstr "" #: ../../principles/transport.rst:684 msgid "" "The first scenario is when the remote entity receives an old `CR` segment. " "It considers this `CR` segment as a connection establishment attempt and " "replies by sending a `CA` segment. However, the initiating host cannot match " "the received `CA` segment with a previous connection attempt. It sends a " "control segment (`REJECT` in the figure below) to cancel the spurious " "connection attempt. The remote entity cancels the connection attempt upon " "reception of this control segment." msgstr "" #: ../../principles/transport.rst:690 msgid "Three-way handshake : recovery from a duplicate `CR`" msgstr "" #: ../../principles/transport.rst:692 msgid "" "A second scenario is when the initiating entity sends a `CR` segment that " "does not reach the remote entity and receives a duplicate `CA` segment from " "a previous connection attempt. This duplicate `CA` segment cannot contain a " "valid acknowledgment for the `CR` segment as the sequence number of the `CR` " "segment was extracted from the transport clock of the initiating entity. The " "`CA` segment is thus rejected and the `CR` segment is retransmitted upon " "expiration of the retransmission timer." msgstr "" #: ../../principles/transport.rst:699 msgid "Three-way handshake : recovery from a duplicate `CA`" msgstr "" #: ../../principles/transport.rst:707 msgid "Three-way handshake : recovery from duplicates `CR` and `CA`" msgstr "" #: ../../principles/transport.rst:711 msgid "Data transfer" msgstr "" #: ../../principles/transport.rst:713 msgid "" "Now that the transport connection has been established, it can be used to " "transfer data. To ensure a reliable delivery of the data, the transport " "protocol will include sliding windows, retransmission timers and `go-back-n` " "or `selective repeat`. However, we cannot simply reuse the techniques from " "the datalink because a transport protocol needs to deal with more types of " "errors than a reliable protocol in datalink layer. The first difference " "between the two layers is the transport layer must face with more variable " "delays. In the datalink layer, when two hosts are connected by a link, the " "transmission delay or the round-trip-time over the link is almost fixed. In " "a network that can span the globe, the delays and the round-trip-times can " "vary significantly on a per packet basis. This variability can be caused by " "two factors. First, packets sent through a network do not necessarily follow " "the same path to reach their destination. Second, some packets may be queued " "in the buffers of routers when the load is high and these queuing delays can " "lead to increased end-to-end delays. A second difference between the " "datalink layer and the transport layer is that a network does not always " "deliver packets in sequence. This implies that packets may be reordered by " "the network. Furthermore, the network may sometimes duplicate packets. The " "last issue that needs to be dealt with in the transport layer is the " "transmission of large SDUs. In the datalink layer, reliable protocols " "transmit small frames. Applications could generate SDUs that are much larger " "than the maximum size of a packet in the network layer. The transport layer " "needs to include mechanisms to fragment and reassemble these large SDUs." msgstr "" #: ../../principles/transport.rst:715 msgid "" "To deal with all these characteristics of the network layer, we need to " "adapt the techniques that we have introduced in the datalink layer." msgstr "" #: ../../principles/transport.rst:738 msgid "" "Using sequence numbers to count bytes has also one advantage when the " "transport layer needs to fragment SDUs in several segments. The figure below " "shows the fragmentation of a large SDU in two segments. Upon reception of " "the segments, the receiver will use the sequence numbers to correctly " "reorder the data." msgstr "" #: ../../principles/transport.rst:757 msgid "" "`Go-back-n` and `selective repeat` can be used in the transport layer as in " "the datalink layer. Since the network layer does not guarantee an in-order " "delivery of the packets, a transport entity should always store the segments " "that it receives out-of-sequence. For this reason, most transport protocols " "will opt for some form of selective repeat mechanism." msgstr "" #: ../../principles/transport.rst:759 msgid "" "In the datalink layer, the sliding window has usually a fixed size which " "depends on the amount of buffers allocated to the datalink layer entity. " "Such a datalink layer entity usually serves one or a few network layer " "entities. In the transport layer, the situation is different. A single " "transport layer entity serves a large and varying number of application " "processes. Each transport layer entity manages a pool of buffers that needs " "to be shared between all these processes. Transport entity are usually " "implemented inside the operating system kernel and shares memory with other " "parts of the system. Furthermore, a transport layer entity must support " "several (possibly hundreds or thousands) of transport connections at the " "same time. This implies that the memory which can be used to support the " "sending or the receiving buffer of a transport connection may change during " "the lifetime of the connection [#fautotune]_ . Thus, a transport protocol " "must allow the sender and the receiver to adjust their window sizes." msgstr "" #: ../../principles/transport.rst:761 msgid "" "To deal with this issue, transport protocols allow the receiver to advertise " "the current size of its receiving window in all the acknowledgments that it " "sends. The receiving window advertised by the receiver bounds the size of " "the sending buffer used by the sender. In practice, the sender maintains two " "state variables : `swin`, the size of its sending window " "(that may be adjusted by the system) and `rwin`, the size of the receiving " "window advertised by the receiver. At any time, the number of unacknowledged " "segments cannot be larger than :math:`\\min(swin,rwin)` [#facklost]_ . The " "utilization of dynamic windows is illustrated in the figure below." msgstr "" #: ../../principles/transport.rst:767 msgid "Dynamic receiving window" msgstr "" #: ../../principles/transport.rst:769 msgid "" "The receiver may adjust its advertised receive window based on its current " "memory consumption, but also to limit the bandwidth used by the sender. In " "practice, the receive buffer can also shrink as the application may not able " "to process the received data quickly enough. In this case, the receive " "buffer may be completely full and the advertised receive window may shrink " "to `0`. When the sender receives an acknowledgment with a receive window set " "to `0`, it is blocked until it receives an acknowledgment with a positive " "receive window. Unfortunately, as shown in the figure below, the loss of " "this acknowledgment could cause a deadlock as the sender waits for an " "acknowledgment while the receiver is waiting for a data segment." msgstr "" #: ../../principles/transport.rst:775 msgid "Risk of deadlock with dynamic windows" msgstr "" #: ../../principles/transport.rst:780 msgid "" "To solve this problem, transport protocols rely on a special timer : the `" "persistence timer`. This timer is started by the sender whenever it receives " "an acknowledgment advertising a receive window set to `0`. When the timer " "expires, the sender retransmits an old segment in order to force the " "receiver to send a new acknowledgment, and hence send the current receive " "window size." msgstr "" #: ../../principles/transport.rst:782 msgid "" "To conclude our description of the basic mechanisms found in transport " "protocols, we still need to discuss the impact of segments arriving in the " "wrong order. If two consecutive segments are reordered, the receiver relies " "on their sequence numbers to reorder them in its receive buffer. " "Unfortunately, as transport protocols reuse the same sequence number for " "different segments, if a segment is delayed for a prolonged period of time, " "it might still be accepted by the receiver. This is illustrated in the " "figure below where segment `D(1,b)` is delayed." msgstr "" #: ../../principles/transport.rst:789 msgid "Ambiguities caused by excessive delays" msgstr "" #: ../../principles/transport.rst:793 msgid "" "To deal with this problem, transport protocols combine two solutions. First, " "they use 32 bits or more to encode the sequence number in the segment " "header. This increases the overhead, but also increases the delay between " "the transmission of two different segments having the same sequence number. " "Second, transport protocols require the network layer to enforce a `Maximum " "Segment Lifetime (MSL)`. The network layer must ensure that no packet " "remains in the network for more than MSL seconds. In the Internet the MSL is " "assumed [#fmsl]_ to be 2 minutes :rfc:`793`. Note that this limits the " "maximum bandwidth of a transport protocol. If it uses `n` bits to encode its " "sequence numbers, then it cannot send more than :math:`2^n` segments every " "MSL seconds." msgstr "" #: ../../principles/transport.rst:797 msgid "Connection release" msgstr "" #: ../../principles/transport.rst:801 msgid "" "When we discussed the connection-oriented service, we mentioned that there " "are two types of connection releases : `abrupt release` and `graceful " "release`." msgstr "" #: ../../principles/transport.rst:810 msgid "Abrupt connection release" msgstr "" #: ../../principles/transport.rst:812 msgid "" "As the entity that sends the `DR` segment cannot know whether the other " "entity has already sent all its data on the connection, SDUs can be lost " "during such an `abrupt connection release`." msgstr "" #: ../../principles/transport.rst:816 msgid "" "The second method to release a transport connection is to release " "independently the two directions of data transfer. Once a user of the " "transport service has sent all its SDUs, it performs a `DISCONNECT.req` for " "its direction of data transfer. The transport entity sends a control segment " "to request the release of the connection *after* the delivery of all " "previous SDUs to the remote user. This is usually done by placing in the `DR`" " the next sequence number and by delivering the `DISCONNECT.ind` only after " "all previous `DATA.ind`. The remote entity confirms the reception of the `DR`" " segment and the release of the corresponding direction of data transfer by " "returning an acknowledgment. This is illustrated in the figure below." msgstr "" #: ../../principles/transport.rst:822 msgid "Graceful connection release" msgstr "" #: ../../principles/transport.rst:828 msgid "" "For example, the :manpage:`htonl(3)` (resp. :manpage:`ntohl(3)`) function " "the standard C library converts a 32-bits unsigned integer from the byte " "order used by the CPU to the network byte order " "(resp. from the network byte order to the CPU byte order). Similar functions " "exist in other programming languages." msgstr "" #: ../../principles/transport.rst:830 msgid "" "In the application layer, most servers are implemented as processes. The " "network and transport layer on the other hand are usually implemented inside " "the operating system and the amount of memory that they can use is limited " "by the amount of memory allocated to the entire kernel." msgstr "" #: ../../principles/transport.rst:834 msgid "" "For a discussion on how the sending buffer can change, see e.g. [SMM1998]_" msgstr "" #: ../../principles/transport.rst:836 msgid "" "Note that if the receive window shrinks, it might happen that the sender has " "already sent a segment that is not anymore inside its window. This segment " "will be discarded by the receiver and the sender will retransmit it later." msgstr "" #: ../../principles/transport.rst:838 msgid "" "In reality, the Internet does not strictly enforce this MSL. However, it is " "reasonable to expect that most packets on the Internet will not remain in " "the network during more than 2 minutes. There are a few exceptions to this " "rule, such as :rfc:`1149` whose implementation is described in http://" "www.blug.linux.no/rfc1149/ but there are few real links supporting " ":rfc:`1149` in the Internet." msgstr ""