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

61 ../../principles/transport.rst:239
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `connectionless network layer service` may delay, reorder or even duplicate SDUs 84/10000 · 84
62 ../../principles/transport.rst:242
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — These imperfections of the `connectionless network layer service` are caused by the operations of the `network layer`. This `layer` is able to deliver packets to their intended destination, but it cannot guarantee their delivery. The main cause of packet losses and errors are the buffers used on the network nodes. If the buffers of one of these nodes becomes full, all arriving packets must be discarded. This situation frequently happens in practice [#fqueuesize]_. Transmission errors can also affect packet transmissions on links where reliable transmission techniques are not enabled or because of errors in the buffers of the network nodes. 647/10000 · 647
63 ../../principles/transport.rst:246
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Transport layer services 24/10000 · 24
64 ../../principles/transport.rst:248
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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 : 1003/10000 · 1003
65 ../../principles/transport.rst:250
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `connectionless service` 28/10000 · 28
66 ../../principles/transport.rst:251
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `connection oriented service` 33/10000 · 33
67 ../../principles/transport.rst:252
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `request-response service` 30/10000 · 30
68 ../../principles/transport.rst:255
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The connectionless service 26/10000 · 26
69 ../../principles/transport.rst:257
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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`. 393/10000 · 393
70 ../../principles/transport.rst:260
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The connection-oriented service 31/10000 · 31
71 ../../principles/transport.rst:264
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — An invocation of the `connection-oriented service` is divided into three phases. The first phase is the establishment of a `connection`. A `connection` is a temporary association between two users through a service provider. Several connections may exist at the same time between any pair of users. Once established, the connection is used to transfer SDUs. `Connections` usually provide one bidirectional stream supporting the exchange of SDUs between the two users that are associated through the `connection`. This stream is used to transfer data during the second phase of the connection called the `data transfer` phase. The third phase is the termination of the connection. Once the users have finished exchanging SDUs, they request the service provider to terminate the connection. As we will see later, there are also some cases where the service provider may need to terminate a connection itself. 906/10000 · 906
72 ../../principles/transport.rst:267
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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. 1021/10000 · 1021
73 ../../principles/transport.rst:288
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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. 587/10000 · 587
74 ../../principles/transport.rst:309
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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. 401/10000 · 401
75 ../../principles/transport.rst:329
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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. 905/10000 · 905
76 ../../principles/transport.rst:364
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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. 1319/10000 · 1319
77 ../../principles/transport.rst:403
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The third phase of a connection is its release. As a connection involves three parties (two users and one service provider), any of them can request the termination of the connection. Usually, connections are terminated upon request of one user once the data transfer is finished. However, sometimes the service provider may be forced to terminate a connection. This can be due to lack of resources inside the service provider or because one of the users is not reachable anymore through the network. In this case, the service provider will issue `Disconnect.indication` primitives to both users. These primitives will contain, as parameter, some information about the reason for the termination of the connection. Unfortunately, as illustrated in the figure below, when a service provider is forced to terminate a connection it cannot guarantee that all SDUs sent by each user have been delivered to the other user. This connection release is said to be abrupt as it can cause losses of data. 993/10000 · 993
78 ../../principles/transport.rst:435
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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. 475/10000 · 475
79 ../../principles/transport.rst:473
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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. 1410/10000 · 1410
80 ../../principles/transport.rst:513
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Reliability of the connection-oriented service 46/10000 · 46