Principles of Reliable Data Transfer

Principles of Reliable Data Transfer

In this section, we look at the problem of reliable data transfer in a general context. This is appropriate since the problem of implementing reliable data transfer takes place not only at the transport layer, but also at the link layer and the application layer as well. The common problem is thus of central importance to networking. In fact, if one had to identify a "top-ten" list of basically important problems in all of networking, this would be a candidate to lead the list. In the next section we'll consider TCP and show, particularly, that TCP exploits many of the principles that we are about to explain.

Figure 1 shows the framework for our study of reliable data transfer. The service abstraction provided to the upper-layer entities is that of a reliable channel through which data can be transferred. With a reliable channel, no transferred data bits are corrupted (flipped from 0 to 1, or vice versa) or lost, and all are delivered in the order in which they were sent. This is exactly the service model offered by TCP to the Internet applications that invoke it.

It is the responsibility of a reliable data transfer protocol to implement this service abstraction. This task is made difficult by the fact that the layer below the reliable data transfer protocol may be unreliable. For instance, TCP is a reliable data transfer protocol that is implemented on top of an unreliable (IP) end-to-end network layer. More commonly, the layer beneath the two reliably communicating end points might consist of a single physical link (as in the case of a link-level data transfer protocol) or a global internetwork (as in the case of a transport-level protocol). For our purposes, however, we can view this lower layer simply as an unreliable point-to-point channel.

In this section, we will gradually develop the sender and receiver sides of a reliable data transfer protocol, considering increasingly complicated models of the underlying channel. Figure 1(b) shows the interfaces for our data transfer protocol. The sending side of the data transfer protocol will be invoked from above by a call to rdt_send ( ). It will pass the data to be delivered to the upper layer at the receiving side. (Here rdt stands for reliable data transfer protocol and _send indicates that the sending side of rdt is being called. The first step in developing any protocol is to choose a good name). On the receiving side, rdt_rcv ( ) will be called when a packet

Reliable data transfer - Service model and service implementation

arrives from the receiving side of the channel. When the rdt protocol wants to deliver data to the upper layer, it will do so by calling deliver_data ( ). In the following we use the terminology "packet" rather than transport-layer "segment". Because the theory developed in this section applies to computer networks on the whole and not just to the Internet transport layer, the generic term "packet" is perhaps more appropriate here.

In this section we examine only the case of unidirectional data transfer, that is, data transfer from the sending to the receiving side. The case of reliable bidirectional (that is, full-duplex) data transfer is conceptually no more difficult but significantly more tedious to explain. Although we examine only unidirectional data transfer, it is important to note that the sending and receiving sides of our protocol will nonetheless need to transmit packets in both directions, as indicated in Figure 1. We will see shortly that, in addition to exchanging packets containing the data to be transferred, the sending and receiving sides of rdt will also need to exchange control packets back and forth. Both the send and receive sides of rdt send packets to the other side by a call to udt_send ( ) (where udt stands for unreliable data transfer).


data transfer, transport layer, link layer, application layer, unidirectional data transfer

Copy Right

The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.