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

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
81 ../../principles/transport.rst:515
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — An important point to note about the connection-oriented service is its reliability. A `connection-oriented` service can only guarantee the correct delivery of all SDUs provided that the connection has been released gracefully. This implies that while the connection is active, there is no guarantee for the actual delivery of the SDUs exchanged as the connection may need to be abruptly released at any time. 409/10000 · 409
82 ../../principles/transport.rst:520
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The request-response service 28/10000 · 28
83 ../../principles/transport.rst:524
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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. 1051/10000 · 1051
84 ../../principles/transport.rst:526
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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. 224/10000 · 224
85 ../../principles/transport.rst:545
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Services and layers 19/10000 · 19
86 ../../principles/transport.rst:547
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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. 657/10000 · 657
87 ../../principles/transport.rst:554
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The transport layer entity interacts with both a user in the application layer and the network layer. It improves the network layer service to make it usable by applications. From the application's viewpoint, the main limitations of the network layer service come from its unreliable service: 292/10000 · 292
88 ../../principles/transport.rst:556
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the network layer may corrupt data; 35/10000 · 35
89 ../../principles/transport.rst:557
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the network layer may loose data; 33/10000 · 33
90 ../../principles/transport.rst:558
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the network layer may not deliver data in-order; 48/10000 · 48
91 ../../principles/transport.rst:559
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the network layer has an upper bound on maximum length of the data; 67/10000 · 67
92 ../../principles/transport.rst:560
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the network layer may duplicate data. 37/10000 · 37
93 ../../principles/transport.rst:562
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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. 193/10000 · 193
94 ../../principles/transport.rst:568
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Interactions between the transport layer, its user, and its network layer provider 82/10000 · 82