Một dạng kênh truyền thực tế hơn là gói dữ liệu trên kênh truyền có thể bị lỗi. Thường bit bị lỗi trên đường truyền vật lý của mạng. Giả sử tất cả các gói dữ liệu truyền đi đều đến được đích và theo đúng thứ tự gửi mặc dù các bit trong
gói dữ liệu có thể bị lỗi. Trong thực tế cuộc sống, khi hai người nói chuyện với nhau, nếu người nghe đã rõ thì xác nhận, ngược lại sẽ yêu cầu người nói nhắc lại. Cơ chế này đã được áp dụng cho rdt 2.0. Trong mạng máy tính, giao thức truyền tin cậy dựa trên cơ chế truyền lại như vậy được gọi là các giao thức ARQ (Automatic Repeat request).
Bên gửi Bên nhận
Hình 4.7 Giao thức cho kênh truyền có lỗi bit
Các giao thức ARQ cần phải có ba khả năng sau để xử lý trong trường hợp có lỗi bit:
- Phát hiện lỗi: là cơ chế cho phép bên nhận phát hiện được khi nào trong gói
dữ liệu có bit bị lỗi, thường sử dụng kỹ thuật CRC để thực hiện công việc này.
- Phản hồi từ phía nhận: Khi phía gửi và phía nhận nằm trên các thiết bị đầu
cuối khác nhau - có thể cách nhau hàng nghìn km, cách duy nhất để phía gửi biết được kết quả gửi là phía nhận gửi thông tin phản hồi thông báo tình trạng nhận cho phía gửi. Báo nhận đúng ACK và báo nhận sai NAK trong ví dụ trên chính là các thông tin phản hồi. Giao thức rdt 2.0 yêu cầu phía nhận gửi phản hồi các bản tin ACK hay NAK cho phía gửi. Đoạn dữ liệu phản hồi chỉ cần sử dụng một bit, ví dụ giá trị 0 ứng với NAK và giá trị 1 ứng với ACK.
- Truyền lại: Đoạn dữ liệu bị lỗi sẽ được bên gửi phát lại.
Trong giao thức rdt 2.0, phía gửi có hai trạng thái. Ở trạng thái thứ nhất, phía gửi đợi dữ liệu từ tầng trên. Trong trạng thái thứ hai, bên gửi đợi phản hồi ACK hoặc NAK từ bên nhận. Nếu nhận được ACK từ rdt_rcv(rcvpkt) && isACK(rcvpkt) tương ứng với sự kiện này, bên gửi biết được đoạn dữ liệu chuyển đến đích an toàn, vì vậy nó trở về trạng thái đợi dữ liệu từ tầng trên để chuyển tiếp. Nếu nhận được NAK, bên gửi gửi lại đoạn dữ liệu rồi quay lại trạng thái đợi phản hồi ACK hoặc NAK cho đoạn dữ liệu vừa gửi lại. Khi bên gửi ở trong trạng thái chờ phản hồi (ACK hoặc NAK), nó không thể nhận thêm dữ liệu từ tầng trên đưa xuống. Nó chỉ chấp nhận dữ liệu khi nhận được ACK và chuyển trạng thái. Bên gửi không gửi dữ liệu cho đến khi nó chắc chắn rằng bên nhận đã
nhận đúng đoạn dữ liệu đã gửi. Giao thức rdt 2.0 với hành vi như vậy thuộc kiểu dừng và chờ (stop and wait).
Hình 4.8 FSM của bên gửi trong rdt 2.1
FSM bên nhận trong giao thức rdt 2.0 chỉ có một trạng thái duy nhất. Khi nhận được đoạn dữ liệu, bên nhận gửi bản tin phản hồi ACK hoặc NAK, phụ thuộc vào đoạn dữ liệu đã nhận có lỗi hay không. Trong hình 4.7, rdt_rcv (rcvpkt) && corrups(rcvpkt) tương ứng với sự kiện đoạn dữ liệu nhận được bị lỗi.
Hình 4.9 FSM của phía nhận trong rdt 2.1
Giao thức rdt 2.0 vẫn còn nhược điểm: chúng ta chưa tính đến khả năng chính đoạn tin ACK hoặc NAK có lỗi. Chính đoạn tin phản hồi (ACK hoặc NAK) cũng cần phải có trường kiểm tra lỗi để bên gửi (lúc này lại là bên nhận) có khả năng phát hiện lỗi trong chính gói phản hồi. Vấn đề ở đây là khi nhận được một gói phản hồi bị lỗi, phía gửi không thể xác định nó là ACK nay NAK, do đó không xác định được đoạn dữ liệu nó gửi từ đích có bị lỗi hay không. Trong trường hợp này, có ba giải pháp xử lý ACK hoặc NAK bị lỗi:
- Giải pháp thứ nhất, dùng xác nhận khác tương tự như ACK, tuy nhiên có thể xảy ra lỗi liên hoàn, do đó giải pháp này khó có thể áp dụng.
- Giải pháp thứ hai là thêm vào trường kiểm tra một số bit để không những cho phép bên nhận phát hiện mà còn sửa được các bit lỗi. Đây hoàn toàn có thể là giải pháp trung gian cho những kênh truyền có lỗi nhưng không xử lý được trường hợp toàn bộ đoạn dữ liệu bị mất.
- Giải pháp thứ ba, phía gửi phát lại gói dữ liệu nếu phát hiện lỗi trong gói phản hồi (ACK hoặc NAK). Tuy nhiên, phương pháp này có thể dẫn đến sự trùng lặp dữ liệu. Bên nhận không biết được ACK/NAK mà nó gửi phản hồi
có bị lỗi trên đường truyền không. Vì thế nó không xác định được gói dữ liệu vừa nhận được là gói dữ liệu mới hay gói cũ.
Giải pháp đơn giản nhất cho vấn đề này (sẽ được áp dụng cho nhiều giao thức, kể cả TCP) là thêm một trường số thứ tự cho đoạn dữ liệu, phía gửi đánh số cho các gói dữ liệu và đặt giá trị này vào trường số thứ tự (sequence number). Bên nhận chỉ cần kiểm tra số thứ tự để xác định đoạn dữ liệu nhận được là đoạn mới hay đoạn truyền lại. Với giao thức stop and wait đơn giản, chỉ cần một bit số thứ tự. Bên nhận có thể xác định bên gửi gửi lại đoạn dữ liệu đã gửi lần trước (số thứ tự của đoạn dữ liệu nhận được trùng với số thứ tự với đoạn dữ liệu nhận được lần trước) hay đoạn dữ liệu mới (có số thứ tự khác nhau, tăng lên theo module 2). Vì chúng ta vẫn giả định toàn bộ đoạn dữ liệu không bị mất trên kênh truyền, nên trong đoạn dữ liệu phản hồi (ACK/NAK) không cần chỉ ra số thứ tự của đoạn dữ liệu mà chúng biên nhận. Bên gửi biết rằng đoạn dữ liệu ACK/NAK (có thể bị lỗi hoặc không) là biên nhận cho đoạn dữ liệu gần nhất nó gửi.
Hình 4.8 và 4.9 là FSM của bên gửi và nhận trong giao thức rdt 2.1. Trong rdt 2.1, FSM của bên gửi và nhận đều có số trạng thái tăng gấp đôi. Đó là vì trạng thái giao thức phải biểu diễn gói dữ liệu được gửi (bởi bên gửi) và gói dữ liệu được đợi (tại bên nhận) có số thứ tự là 0 hay 1. Chú ý rằng các hành động trong trạng thái gói dữ liệu có số thứ tự 0 được gửi (phía gửi) hoặc được mong đợi (phía nhận) ngược với trạng thái gói dữ liệu có số thứ tự 1 được gửi hay được đợi.
Giao thức rdt 2.1 sử dụng cả biên nhận đúng (ACK) và biên nhận sai (NAK). NAK được gửi khi nhận được gói dữ liệu bị lỗi hay không đúng số thứ tự. Chúng ta có thể không cần sử dụng NAK: thay vì việc gửi NAK, chúng ta gửi ACK cho gói dữ liệu cuối cùng đã được nhận đúng. Nếu nhận hai ACK cho cùng một gói dữ liệu (hiện tượng trùng ACK - duplicate ACK) bên gửi xác định được bên nhận không nhận đúng gói dữ liệu sau gói dữ liệu đã biên nhận ACK hai lần. TCP sử dụng sự kiện “3 lần nhận được ACK trùng nhau” (“tripie dupiicate ACKs”) để kích hoạt việc gửi lại rdt 2.2 là giao thức truyền dữ liệu tin cậy trên kênh truyền có bít lỗi không sử dụng NAK.