3.4 Principles of Reliable Data Tra

3.4 Principles of Reliable Data Transfer
In this section, we consider the problem of reliable data transfer in a general con-text. This is appropriate since the problem of implementing reliable data transfer occurs not only at the transport layer, but also at the link layer and the application layer as well. The general problem is thus of central importance to networking. Indeed, if one had to identify a “top-ten” list of fundamentally important problems in all of networking, this would be a candidate to lead the list. In the next section we’ll examine TCP and show, in particular, that TCP exploits many of the principles that we are about to describe.
Figure 3.8 illustrates 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 precisely 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 example, TCP is a reliable data transfer protocol that is implemented on top of an unreliable (IP) end-to-end net-work layer. More generally, 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 proto-col). For our purposes, however, we can view this lower layer simply as an unreli-able point-to-point channel.
In this section, we will incrementally develop the sender and receiver sides of a reliable data transfer protocol, considering increasingly complex models of the under-lying channel. For example, we’ll consider what protocol mechanisms are needed when the underlying channel can corrupt bits or lose entire packets. One assumption we’ll adopt throughout our discussion here is that packets will be delivered in the order in which they were sent, with some packets possibly being lost; that is, the underlying channel will not reorder packets. Figure 3.8(b) illustrates 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 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 in general and not just to the Internet transport layer, the generic term “packet” is perhaps more appropriate here.
In this section we consider 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 considerably more tedious to explain. Although we consider 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 3.8. 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).
3.4.1 Building a Reliable Data Transfer Protocol
We now step through a series of protocols, each one becoming more complex, arriv-ing at a flawless, reliable data transfer protocol.
Reliable Data Transfer over a Perfectly Reliable Channel: rdt1.0
We first consider the simplest case, in which the underlying channel is completely reliable. The protocol itself, which we’ll call rdt1.0, is trivial. The finite-state machine (FSM) definitions for the rdt1.0 sender and receiver are shown in Figure 3.9. The FSM in Figure 3.9(a) defines the operation of the sender, while the FSM in Figure 3.9(b) defines the operation of the receiver. It is important to note that there are separate FSMs for the sender and for the receiver. The sender and receiver FSMs in Figure 3.9 each have just one state. The arrows in the FSM description indicate the transition of the protocol from one state to another. (Since each FSM in Figure 3.9 has just one state, a transition is necessarily from the one state back to itself; we’ll see more complicated state diagrams shortly.) The event causing the transition is shown above the horizontal line labeling the transition, and the actions taken when the event occurs are shown below the horizontal line. When no action is taken on an event, or no event occurs and an action is taken, we’ll use the symbol below or above the horizontal, respectively, to explicitly denote the lack of an action or event. The initial state of the FSM is indicated by the dashed arrow. Although the FSMs in Figure 3.9 have but one state, the FSMs we will see shortly have multiple states, so it will be important to identify the initial state of each FSM.
The sending side of rdt simply accepts data from the upper layer via the rdt_send(data) event, creates a packet containing the data (via the action make_pkt(data)) and sends the packet into the channel. In practice, the rdt_send(data) event would result from a procedure call (for example, to rdt_send()) by the upper-layer application.
On the receiving side, rdt receives a packet from the underlying channel via the rdt_rcv(packet) event, removes the data from the packet (via the action extract (packet, data)) and passes the data up to the upper layer (via the action deliver_data(data)). In practice, the rdt_rcv(packet) event would result from a procedure call (for example, to rdt_rcv()) from the lower-layer protocol.
In this simple protocol, there is no difference between a unit of data and a packet. Also, all packet flow is from the sender to receiver; with a perfectly reliable channel there is no need for the receiver side to provide any feedback to the sender since nothing can go wrong! Note that we have also assumed that the receiver is able to receive data as fast as the sender happens to send data. Thus, there is no need for the receiver to ask the sender to slow down!
Reliable Data Transfer over a Channel with Bit Errors: rdt2.0
A more realistic model of the underlying channel is one in which bits in a packet may be corrupted. Such bit errors typically occur in the physical components of a network as a packet is transmitted, propagates, or is buffered. We’ll continue to assume for the moment that all transmitted packets are received (although their bits may be corrupted) in the order in which they were sent.
Before developing a protocol for reliably communicating over such a channel, first consider how people might deal with such a situation. Consider how you your-self might dictate a long message over the phone. In a typical scenario, the message taker might say “OK” after each sentence has been heard, understood, and recorded. If the message taker hears a garbled sentence, you’re asked to repeat the garbled sentence. This message-dictation protocol uses both positive acknowledgments (“OK”) and negative acknowledgments (“Please repeat that.”). These control mes-sages allow the receiver to let the sender know what has been received correctly, and what has been received in error and thus requires repeating. In a computer network setting, reliable data transfer protocols based on such retransmission are known as ARQ (Automatic Repeat reQuest) protocols.
Fundamentally, three additional protocol capabilities are required in ARQ protocols to handle the presence of bit errors:
Error detection. First, a mechanism is needed to allow the receiver to detect when bit errors have occurred. Recall from the previous section that UDP uses the Internet checksum field for exactly this purpose. In Chapter 5 we’ll exam- ine error-detection and -correction techniques in greater detail; these tech-niques allow the receiver to detect and possibly correct packet bit errors. For now, we need only know that these techniques require that extra bits (beyond the bits of original data to be transferred) be sent from the sender to the receiver; these bits will be gathered into the packet checksum field of the rdt2.0 data packet.

Kết quả (Việt) 1:

3.4 các nguyên tắc của truyền dữ liệu đáng tin cậyTrong phần này, chúng tôi xem xét vấn đề đáng tin cậy dữ liệu truyền trong một con chung, văn bản. Điều này là thích hợp vì vấn đề của việc thực hiện truyền dữ liệu đáng tin cậy xảy ra không chỉ ở tầng giao vận, nhưng cũng tại tầng liên kết và các lớp ứng dụng. Vấn đề chung như vậy là trung tâm quan trọng với mạng. Thật vậy, nếu một trong những phải xác định một danh sách "top 10" của các vấn đề quan trọng về cơ bản trong tất cả các mạng, điều này sẽ là một ứng cử viên dẫn đầu danh sách. Trong phần tiếp theo, chúng ta sẽ xem xét TCP và hiển thị, đặc biệt, TCP khai thác nhiều người trong số các nguyên tắc mà chúng tôi đang về để mô tả. 3.8 hình minh hoạ nền tảng để chúng tôi nghiên cứu về truyền dữ liệu đáng tin cậy. Trừu tượng dịch vụ cung cấp cho các thực thể trên lớp là một kênh đáng tin cậy qua dữ liệu có thể được chuyển giao. Với một kênh đáng tin cậy, không có bit dữ liệu chuyển giao đang bị hỏng (lộn từ 0 tới 1, hoặc ngược lại) hoặc bị mất, và tất cả được gửi theo thứ tự chúng đã được gửi. Điều này là chính xác có mô hình dịch vụ được cung cấp bởi TCP đến các ứng dụng Internet gọi nó. Nó là trách nhiệm của một giao thức truyền dữ liệu đáng tin cậy để thực hiện điều này trừu tượng dịch vụ. Nhiệm vụ này được thực hiện khó khăn bởi thực tế rằng các lớp dưới đây giao thức truyền dữ liệu đáng tin cậy có thể không đáng tin cậy. Ví dụ, TCP là một giao thức truyền dữ liệu đáng tin cậy được thực hiện trên đầu trang của một không đáng tin cậy (IP) end-to-end net-làm việc lớp. Nói chung, các lớp bên dưới hai điểm cuối đáng tin cậy giao tiếp có thể bao gồm một liên kết duy nhất vật lý (như trong trường hợp của một giao thức truyền dữ liệu liên kết cấp) hoặc một internetwork toàn cầu (như trong trường hợp của một vận chuyển cấp proto-col). Cho các mục đích của chúng tôi, Tuy nhiên, chúng tôi có thể xem lớp thấp này đơn giản là một kênh thể unreli điểm. Trong phần này, chúng tôi sẽ từng bước phát triển ở hai bên người gửi và người nhận của một giao thức truyền dữ liệu đáng tin cậy, xem xét các mô hình ngày càng phức tạp của các kênh nằm dưới. Ví dụ, chúng tôi sẽ xem xét những gì cơ chế giao thức là cần thiết khi các kênh nằm bên dưới có thể tham nhũng bit hoặc mất toàn bộ gói. Một trong những giả định chúng tôi sẽ áp dụng trong suốt cuộc thảo luận của chúng tôi ở đây là gói tin sẽ được gửi theo thứ tự mà trong đó họ đã được gửi, với một số gói có thể bị mất; có nghĩa là, các kênh cơ bản sẽ không sắp xếp lại gói. Tìm 3.8(b) minh họa các giao diện cho giao thức truyền dữ liệu của chúng tôi. Bên giao thức truyền dữ liệu, gửi sẽ được kích hoạt từ phía trên bằng một cuộc gọi đến rdt_send(). Nó sẽ vượt qua các dữ liệu sẽ được chuyển giao cho lớp trên ở phía bên nhận. (Ở đây rdt là viết tắt của giao thức truyền dữ liệu đáng tin cậy và _send chỉ ra rằng bên gửi của rdt được gọi là. Bước đầu tiên trong việc phát triển bất kỳ giao thức là để chọn một tên tốt!) Về phía nhận, rdt_rcv() sẽ được gọi là khi một gói tin đến từ phía nhận của các kênh. Khi giao thức rdt muốn cung cấp dữ liệu cho lớp trên, nó sẽ làm như vậy bằng cách gọi điện thoại deliver_data(). Ở đây chúng tôi sử dụng thuật ngữ "gói" thay vì tầng giao vận "phân đoạn". Bởi vì lý thuyết được phát triển trong phần này áp dụng cho mạng máy tính nói chung và không chỉ để Internet cho tầng giao vận, thuật ngữ chung "gói" có lẽ thêm thích hợp ở đây.Trong phần này chúng tôi xem xét trường hợp của truyền dữ liệu unidirectional, có nghĩa là, truyền dữ liệu gửi đến phía bên nhận. Trường hợp của hai chiều đáng tin cậy (có nghĩa là, đầy đủ-kép) truyền dữ liệu là khái niệm không khó khăn nhưng đáng kể hơn tẻ nhạt để giải thích. Mặc dù chúng tôi xem xét chỉ unidirectional dữ liệu chuyển giao, nó là quan trọng cần lưu ý rằng ở hai bên gửi và nhận của chúng tôi giao thức sẽ Tuy nhiên cần phải truyền tải gói dữ liệu trong cả hai chiều, như được chỉ ra ở hình 3.8. Chúng ta sẽ thấy ngay rằng, ngoài việc trao đổi các gói dữ liệu có chứa dữ liệu được chuyển giao, gửi và nhận tin nhắn bên rdt cũng sẽ cần phải trao đổi gói dữ liệu kiểm soát lại. Cả hai gửi và nhận được bên rdt gửi gói để phía bên kia của một cuộc gọi đến udt_send() (nơi udt tượng trưng cho truyền dữ liệu không đáng tin cậy).3.4.1 xây dựng một giao thức truyền dữ liệu đáng tin cậyChúng tôi bây giờ bước thông qua một loạt các giao thức, mỗi một ngày càng trở nên phức tạp hơn, chóng-ing tại một giao thức truyền dữ liệu hoàn hảo, đáng tin cậy.Đáng tin cậy dữ liệu chuyển trong một hoàn toàn đáng tin cậy kênh: rdt1.0Chúng tôi đầu tiên xem xét trường hợp đơn giản nhất, trong đó các kênh nằm bên dưới là hoàn toàn đáng tin cậy. Giao thức chính nó, mà chúng tôi sẽ gọi là rdt1.0, là tầm thường. Các định nghĩa hữu hạn trạng thái máy (FSM) cho rdt1.0 người gửi và người nhận được hiển thị trong hình 3.9. FSM ở con số 3.9(a) xác định các hoạt động của người gửi, trong khi FSM ở con số 3.9(b) xác định hoạt động của người nhận. Nó là quan trọng cần lưu ý rằng không có riêng biệt FSMs cho người gửi và người nhận. Người gửi và người nhận FSMs trong hình 3.9 mỗi có chỉ là một nhà nước. Các mũi tên trong các mô tả FSM cho thấy sự chuyển đổi của các giao thức từ một tiểu bang khác. (Kể từ khi mỗi FSM trong hình 3.9 đã chỉ là một nhà nước, một quá trình chuyển đổi là nhất thiết phải từ một tiểu bang quay lại chính nó; chúng ta sẽ thấy phức tạp hơn bang sơ đồ ngay.) Các sự kiện gây ra quá trình chuyển đổi được hiển thị ở trên đường ngang ghi nhãn quá trình chuyển đổi, và hành động thực hiện khi xảy ra các sự kiện được hiển thị dưới mức ngang. Khi không có hành động được thực hiện trên một sự kiện, hoặc không có sự kiện xảy ra và một hành động được lấy, chúng tôi sẽ sử dụng biểu tượng dưới hoặc trên ngang, tương ứng, để biểu thị một cách rõ ràng thiếu một hành động hoặc sự kiện. Bang FSM, ban đầu được chỉ định bởi tiêu tan mũi tên. Mặc dù FSMs trong hình 3.9 có nhưng một tiểu bang, FSMs chúng ta sẽ thấy ngay có nhiều kỳ, do đó, nó sẽ là quan trọng để xác định các bang mỗi FSM, ban đầu.The sending side of rdt simply accepts data from the upper layer via the rdt_send(data) event, creates a packet containing the data (via the action make_pkt(data)) and sends the packet into the channel. In practice, the rdt_send(data) event would result from a procedure call (for example, to rdt_send()) by the upper-layer application.On the receiving side, rdt receives a packet from the underlying channel via the rdt_rcv(packet) event, removes the data from the packet (via the action extract (packet, data)) and passes the data up to the upper layer (via the action deliver_data(data)). In practice, the rdt_rcv(packet) event would result from a procedure call (for example, to rdt_rcv()) from the lower-layer protocol.In this simple protocol, there is no difference between a unit of data and a packet. Also, all packet flow is from the sender to receiver; with a perfectly reliable channel there is no need for the receiver side to provide any feedback to the sender since nothing can go wrong! Note that we have also assumed that the receiver is able to receive data as fast as the sender happens to send data. Thus, there is no need for the receiver to ask the sender to slow down!Reliable Data Transfer over a Channel with Bit Errors: rdt2.0A more realistic model of the underlying channel is one in which bits in a packet may be corrupted. Such bit errors typically occur in the physical components of a network as a packet is transmitted, propagates, or is buffered. We’ll continue to assume for the moment that all transmitted packets are received (although their bits may be corrupted) in the order in which they were sent.Before developing a protocol for reliably communicating over such a channel, first consider how people might deal with such a situation. Consider how you your-self might dictate a long message over the phone. In a typical scenario, the message taker might say “OK” after each sentence has been heard, understood, and recorded. If the message taker hears a garbled sentence, you’re asked to repeat the garbled sentence. This message-dictation protocol uses both positive acknowledgments (“OK”) and negative acknowledgments (“Please repeat that.”). These control mes-sages allow the receiver to let the sender know what has been received correctly, and what has been received in error and thus requires repeating. In a computer network setting, reliable data transfer protocols based on such retransmission are known as ARQ (Automatic Repeat reQuest) protocols.Fundamentally, three additional protocol capabilities are required in ARQ protocols to handle the presence of bit errors:Error detection. First, a mechanism is needed to allow the receiver to detect when bit errors have occurred. Recall from the previous section that UDP uses the Internet checksum field for exactly this purpose. In Chapter 5 we’ll exam- ine error-detection and -correction techniques in greater detail; these tech-niques allow the receiver to detect and possibly correct packet bit errors. For now, we need only know that these techniques require that extra bits (beyond the bits of original data to be transferred) be sent from the sender to the receiver; these bits will be gathered into the packet checksum field of the rdt2.0 data packet.

Kết quả (Việt) 2:

3.4 Nguyên tắc đáng tin cậy chuyển giao dữ liệu
Trong phần này, chúng ta xem xét các vấn đề về truyền dữ liệu đáng tin cậy trong một con-văn bản nói chung. Điều này là phù hợp vì các vấn đề thực hiện truyền dữ liệu đáng tin cậy xảy ra không chỉ ở lớp vận chuyển, mà còn ở các lớp liên kết và lớp ứng dụng là tốt. Các vấn đề chung là như vậy, tầm quan trọng của trung tâm để kết nối mạng. Thật vậy, nếu một người đã phải xác định một "top-ten" danh sách các vấn đề cơ bản quan trọng trong tất cả các mạng, điều này sẽ là một ứng cử viên dẫn đầu danh sách. Trong phần tiếp theo, chúng tôi sẽ kiểm tra TCP và chương trình, đặc biệt, đó TCP khai thác nhiều nguyên tắc mà chúng tôi về để mô tả.
Hình 3.8 minh họa khuôn khổ cho việc học tập của chúng ta về truyền dữ liệu đáng tin cậy. Sự trừu tượng hóa dịch vụ cung cấp cho các đối tượng lớp trên là của một kênh đáng tin cậy thông qua đó dữ liệu có thể được chuyển giao. Với một kênh đáng tin cậy, không có bit dữ liệu được chuyển bị hỏng (lộn 0-1, hoặc ngược lại) hay thua, và tất cả được giao theo thứ tự mà chúng được gửi. Đây chính là mô hình dịch vụ được cung cấp bởi TCP đến các ứng dụng Internet mà gọi nó.
Đó là trách nhiệm của một giao thức truyền dữ liệu đáng tin cậy để thực hiện trừu tượng dịch vụ này. Nhiệm vụ này được thực hiện khó khăn bởi thực tế là các lớp dưới các giao thức truyền dữ liệu đáng tin cậy có thể không đáng tin cậy. Ví dụ, TCP là một giao thức truyền dữ liệu đáng tin cậy đó được thực hiện trên đầu trang của một lớp lưới làm việc không đáng tin cậy (IP) end-to-end. Tổng quát hơn, các lớp bên dưới hai điểm cuối giao tiếp đáng tin cậy có thể bao gồm một liên kết duy nhất vật lý (như trong trường hợp của một giao thức truyền dữ liệu mức liên kết) hoặc một liên mạng toàn cầu (như trong trường hợp của một vận tải cấp proto-col ). Đối với mục đích của chúng tôi, tuy nhiên, chúng ta có thể xem lớp thấp này chỉ đơn giản là một kênh unreli-thể point-to-point.
Trong phần này, chúng ta sẽ từng bước phát triển các bên gửi và người nhận của một giao thức truyền dữ liệu đáng tin cậy, xem xét các mô hình ngày càng phức tạp của các kênh dưới, vùng xa. Ví dụ, chúng ta sẽ xem xét những gì cơ chế giao thức cần thiết khi các kênh cơ bản có thể bit hỏng hoặc mất toàn bộ gói. Một giả thiết chúng tôi sẽ áp dụng suốt cuộc thảo luận của chúng tôi ở đây là các gói tin sẽ được giao theo thứ tự mà chúng được gửi đi, với một số gói có thể bị mất; đó là, kênh cơ bản sẽ không sắp xếp lại các gói tin. Hình 3.8 (b) minh họa các giao diện cho các giao thức truyền dữ liệu của chúng tôi. Phía gửi của các giao thức truyền dữ liệu sẽ được gọi từ phía trên của một cuộc gọi đến rdt_send (). Nó sẽ vượt qua các dữ liệu sẽ được chuyển giao cho các lớp trên ở phía bên nhận. (RDT đây là viết tắt của giao thức truyền dữ liệu đáng tin cậy và _send chỉ ra rằng phía gửi của RDT đang được gọi. Bước đầu tiên trong việc phát triển bất kỳ giao thức là chọn một tên tốt!) Về phía nhận, rdt_rcv () sẽ được gọi khi một gói tin đến từ bên nhận của kênh. Khi giao thức RDT muốn cung cấp dữ liệu cho các lớp trên, nó sẽ làm như vậy bằng cách gọi deliver_data (). Trong phần tiếp theo chúng ta sử dụng thuật ngữ "gói" chứ không đưa lớp "phân khúc." Bởi vì các lý thuyết phát triển trong phần này áp dụng cho các mạng máy tính nói chung và không chỉ để các lớp truyền tải Internet, các generic hạn "gói" là có lẽ nhiều hơn thích hợp ở đây.
Trong phần này chúng ta chỉ xem xét các trường hợp chuyển dữ liệu theo một hướng, đó là, chuyển dữ liệu từ việc gửi tới bên nhận. Các trường hợp hai chiều đáng tin cậy (có nghĩa là, full-duplex) truyền dữ liệu là khái niệm không có nhiều khó khăn nhưng đáng kể hơn nữa tẻ nhạt để giải thích. Mặc dù chúng ta xem xét chuyển giao dữ liệu chỉ có một chiều, điều quan trọng là cần lưu ý rằng việc gửi và nhận hai mặt của giao thức của chúng ta dù sao cũng sẽ cần để truyền tải các gói dữ liệu theo cả hai hướng, như được chỉ ra trong hình 3.8. Chúng ta sẽ thấy ngay rằng, ngoài việc trao đổi các gói tin có chứa các dữ liệu được chuyển giao, việc gửi và nhận hai mặt của RDT cũng sẽ cần phải trao đổi các gói điều khiển qua lại. Cả hai gửi và nhận hai mặt của RDT gửi gói tin đến phía bên kia bằng một cuộc gọi đến udt_send () (nơi UDT là viết tắt của truyền dữ liệu không đáng tin cậy).
3.4.1 Xây dựng một đáng tin cậy giao thức chuyển giao dữ liệu
Bây giờ chúng ta bước qua một loạt các giao thức, mỗi một trở nên phức tạp hơn, arriv-ing ở một hoàn hảo, đáng tin cậy giao thức truyền dữ liệu.
Truyền dữ liệu đáng tin cậy trên một kênh hoàn hảo đáng tin cậy: rdt1.0
Chúng tôi đầu tiên xem xét các trường hợp đơn giản nhất, trong đó các kênh cơ bản là hoàn toàn đáng tin cậy. Các giao thức riêng của mình, mà chúng tôi sẽ gọi rdt1.0, là tầm thường. Các máy hữu hạn trạng thái (FSM) định nghĩa cho người gửi và người nhận được rdt1.0 thể hiện trong hình 3.9. Các FSM trong hình 3.9 (a) xác định các hoạt động của người gửi, trong khi các FSM trong hình 3.9 (b) xác định các hoạt động của người nhận. Điều quan trọng là phải lưu ý rằng có những FSMs riêng cho người gửi và cho người nhận. Người gửi và người nhận FSMs trong hình 3.9 từng có chỉ là một trạng thái. Các mũi tên trong bản mô tả FSM chỉ ra quá trình chuyển đổi của các giao thức từ một tiểu bang khác. (Vì mỗi FSM trong hình 3.9 chỉ có một nhà nước, một quá trình chuyển đổi là cần thiết từ một nhà nước lại cho chính nó;. Chúng ta sẽ thấy sơ đồ trạng thái phức tạp hơn trong thời gian ngắn) Sự kiện này gây ra quá trình chuyển đổi được thể hiện trên các đường ngang gán cho quá trình chuyển đổi, và những hành động thực hiện khi sự kiện xảy ra được hiển thị bên dưới các đường ngang. Khi không có hành động trên một sự kiện, hoặc không có sự kiện xảy ra và một hành động được thực hiện, chúng tôi sẽ sử dụng các biểu tượng bên dưới hoặc phía trên ngang, tương ứng, để biểu thị một cách rõ ràng thiếu một hành động hoặc sự kiện. Các trạng thái ban đầu của FSM được chỉ bởi mũi tên đứt nét. Mặc dù FSMs trong hình 3.9 có nhưng một nhà nước, các FSMs chúng ta sẽ thấy ngay có nhiều quốc gia, do đó, nó sẽ rất quan trọng để xác định tình trạng ban đầu của mỗi FSM.
Phía gửi RDT đơn giản chấp nhận dữ liệu từ các lớp trên qua rdt_send (dữ liệu) sự kiện, tạo ra một gói tin có chứa dữ liệu (thông qua các hành động make_pkt (dữ liệu)) và gửi gói vào kênh. Trong thực tế, các rdt_send (dữ liệu) sự kiện sẽ là kết quả của một cuộc gọi thủ tục (ví dụ, để rdt_send ()) bởi các ứng dụng lớp trên.
Về phía nhận, RDT nhận được một gói tin từ các kênh cơ bản thông qua các rdt_rcv (packet) sự kiện, loại bỏ các dữ liệu từ các gói tin (thông qua các trích hành động (gói tin, dữ liệu)) và chuyển dữ liệu lên đến lớp trên (thông qua các hành động deliver_data (dữ liệu)). Trong thực tế, các rdt_rcv (packet) sự kiện sẽ là kết quả của một cuộc gọi thủ tục (ví dụ, để rdt_rcv ()) từ các giao thức lớp thấp hơn.
Trong giao thức này đơn giản, không có sự khác biệt giữa một đơn vị dữ liệu và một gói. Ngoài ra, tất cả các lưu lượng gói tin là từ người gửi đến người nhận; với một kênh hoàn toàn đáng tin cậy không có nhu cầu cho các bên nhận để cung cấp bất kỳ thông tin phản hồi cho người gửi vì không có gì có thể đi sai! Lưu ý rằng chúng tôi cũng đã giả định rằng người nhận có thể nhận được dữ liệu nhanh như người gửi sẽ xảy ra để gửi dữ liệu. Vì vậy, không có nhu cầu cho người nhận để yêu cầu người gửi chậm!
Chuyển dữ liệu đáng tin cậy trên một kênh với lỗi Bit: rdt2.0
Một mô hình thực tế hơn về các kênh cơ bản là một trong đó bit trong một gói tin có thể bị hỏng. Bit lỗi này thường xảy ra trong các thành phần vật lý của một mạng lưới như một gói tin được truyền đi, lan truyền, hoặc là đệm. Chúng tôi sẽ tiếp tục giả định cho thời điểm đó tất cả các gói dữ liệu truyền nhận được (mặc dù bit của họ có thể bị hỏng) trong thứ tự mà chúng được gửi.
Trước khi phát triển một giao thức đáng tin cậy cho giao tiếp qua một kênh như vậy, đầu tiên xem xét làm thế nào mọi người có thể đối phó với một tình huống như vậy. Hãy cân nhắc xem bạn của bạn-tự có thể ra lệnh một tin nhắn dài qua điện thoại. Trong một kịch bản điển hình, người lấy tin có thể nói "OK" sau mỗi câu đã được nghe, hiểu, và ghi lại. Nếu người lấy tin nghe một câu bị cắt xén, bạn được yêu cầu lặp lại câu bị cắt xén. Giao thức thông điệp chính tả này sử dụng cả hai thừa nhận tích cực ("OK") và nhận phủ định ("Hãy lặp lại điều đó."). Những kiểm soát mes-hiền cho phép người nhận để cho người gửi biết những gì đã được nhận được một cách chính xác, và những gì đã được nhận lỗi và do đó đòi hỏi lặp đi lặp lại. Trong một thiết lập mạng máy tính, các giao thức truyền dữ liệu đáng tin cậy dựa trên truyền lại như vậy được gọi là ARQ (Automatic Repeat Request) giao thức.
Về cơ bản, ba khả năng giao thức bổ sung cần thiết trong các giao thức ARQ để xử lý sự hiện diện của các lỗi bit:
Phát hiện lỗi. Đầu tiên, một cơ chế là cần thiết để cho phép các máy thu phát hiện khi bit lỗi đã xảy ra. Nhớ lại từ các phần trước rằng UDP sử dụng các lĩnh vực kiểm tra Internet cho chính xác mục đích này. Trong chương 5 chúng tôi sẽ dụ ine lỗi phát hiện và -correction kỹ thuật chi tiết hơn; các công nghệ-kỹ cho phép người nhận để phát hiện và có thể lỗi bit chính xác gói tin. Để bây giờ, chúng ta chỉ cần biết rằng những kỹ thuật này đòi hỏi rằng bit thêm (ngoài các bit dữ liệu ban đầu được chuyển giao) được gửi từ người gửi đến người nhận; các bit này sẽ được tập hợp thành các lĩnh vực kiểm tra gói tin của các gói dữ liệu rdt2.0.