Giao thức GBN khắc phục được hiệu suất thấp của giao thức stop and wait. Tuy nhiên trong một vài tình huống, chính hiệu suất của giao thức GBN cũng rất thấp. Ví dụ khi kích thước cửa sổ và thời gian truyền một đoạn tin lớn, có thể có nhiều đoạn tin ở trên đường truyền, một đoạn tin bị lỗi có thể khiến GBN phải truyền lại nhiều đoạn tin.
Giao thức lặp lại có lựa chọn (SR - Selective Repeat) tránh việc truyền lại không cần thiết bằng cách bên gửi chỉ gửi lại các đoạn tin mà nó cho là có lỗi (hoặc mất). Để truyền lại từng đoạn tin khi cần thiết, bên nhận cần biên nhận cho từng đoạn tin nhận đúng. Vẫn sử dụng lại kích thước cửa sổ là N để giới hạn tổng số đoạn tin chưa được biên nhận trên đường truyền. Tuy nhiên khác
với GBN, bên gửi sẽ nhận được biên nhận ACK cho một số đoạn tin trong cửa sổ.
Hình 4.16 Khoảng số thứ tự của bên gửi và bên nhận
Bên nhận Selective Repeat sẽ biên nhận cho bất kỳ đoạn tin nhận đúng, cho dù không theo đúng thứ tự. Đoạn tin không đúng thứ tự vẫn được lưu giữ lại cho đến khi tất cả các đoạn tin còn thiếu (đoạn tin có số thứ tự nhỏ hơn) được chuyển đến, khi đó tất cả các đoạn tin sẽ được chuyển lên tầng trên theo đúng thứ tự.
Sự kiện và phản ứng của bên gửi
- Dữ liệu nhận được từ phía trên: Khi nhận được dữ liệu từ phía trên, bên gửi SR kiểm tra số thứ tự sẽ gửi. Nếu số thứ tự sẽ gửi nằm trong cửa sổ gửi, dữ liệu được đóng gói và gửi đi, ngược lại thì dữ liệu được lưu giữ trong bộ đệm hoặc gửi trả lên tầng trên để gửi sau, giống GBN.
- Hết thời gian đợi – Timeout: Timer lại được sử dụng để phát hiện mất gói tin. Tuy nhiên, mỗi gói tin gửi đi có một timer riêng, bởi vì chỉ có duy nhất một gói tin được gửi lại khi hết thời gian đợi. Có thể sử dụng đồng hồ hệ thống giữ vai trò đồng bộ cho các timer.
- Nhận được ACK: Nếu nhận được ACK, bên gửi đánh dấu gói tin đã được chuyển đúng. Nếu số thứ tự của gói tin vừa được biên nhận bằng send_base, cánh cửa sổ sẽ trượt tới gói tin có số thứ tự nhỏ nhất chưa được biên nhận. Nếu cửa sổ di chuyển và còn các gói tin chưa được truyền thì các gói tin đó sẽ được gửi.
Hình 4.17 SR trong quá trình hoạt động
Sự kiện và phản ứng của bên nhận
- Nhận đúng gói tin với số thứ tự trong khoảng [rcv_base,rcv_base+N-1. Trong trường hợp này, gói tin nhận được nằm trong cửa sổ nhận. Bên nhận gửi biên nhận cho gói tin này. Nếu gói tin đó chưa được nhận từ trước, nó sẽ được ghi lại trong bộ đệm. Nếu gói tin đó có số thứ tự bằng với cận dưới của cửa sổ nhận (rcv_base trong hình 4.16) thì nó cùng các gói tin có số thứ tự liên tiếp đã lưu giữ từ trước (bắt đầu tớ rcv_base) được chuyển lên tầng trên. Cửa sổ nhận sẽ trượt về phía trước một khoảng bằng với khoảng số gói tin đã chuyển lên tầng trên. với ví dụ trên hình 4.17 khi nhận được gói tin có số thứ tự rcv_base 2 thì gói tin này cùng với gói tin rcv_base+1 và gói tin rcv_base+2 được chuyển lên tầng trên.
- Nhận được gói tin với số thứ tự trong [rcv_base-N,rcv_base-1].Trong trường hợp này, gửi biên nhận lại cho gói tin (mặc dù đã biên nhận từ trước). - Các trường hợp khác. Bỏ qua gói tin đó đi.
Hình 4.18 Truyền lại hay gói mới
Trong bước hai, bên nhận phải biên nhận lại (chứ không được bỏ qua) cho gói tin đến với số thứ tự nhỏ hơn giá trị biên của cửa sổ hiện thời. Điều này hết sức cần thiết. Ví dụ với không gian số thứ tự của bên gửi và bên nhận trong hình 4.16, nếu không nhận được ACK từ bên nhận xác nhận gói tin send_base đã được nhận, bên gửi sẽ gửi lại gói tin send_base, Pһc dù rõ ràng rằng (với chúng ta, chứ không phải bên gửi) bên nhận đã nhận được gói tin đó. Nếu bên nhận không biên nhận gói tin này, cửa sổ bên gửi có thể sẽ không bao giờ trượt tới phía trước. Ví dụ này minh họa một đặc điểm quan trọng của giao thức SR (và nhiều giao thức tương tự khác). sự xác định của bên gửi và bên nhận về cái gì đã được nhận, cái gì chưa được nhận không phải luôn luôn giống nhau. với giao thức SR, điều này có nghĩa là cửa sổ bên gửi và bên nhận không bao giờ trùng khớp nhau.
Thiếu sự đồng bộ giữa cửa sổ bên gửi và bên nhận có thể gây hậu quả nghiêm trọng khi khoảng số thứ tự nhỏ. Ví dụ điều gì có thể xảy ra với khoảng số thứ tự là 4, các gói tin được đánh số là 0, 1, 2 và 3 , độ lớn cửa sổ là 3. Giả sử các gói tin từ 0, 1 , 2 được truyền đi và nhận chính xác tại phía bên nhận. Bên nhận gửi biên nhận cho 3 gói tin này. Khi đó, cửa sổ bên nhận tiến lên các gói tin thứ 4,5 và 6 với số thứ tự tương ứng là 3, 0, 1. Bây giờ xem xét hai trường
hợp. Trường hợp đầu tiên, hình 3.26(a), ACK của 3 gói tin đầu tiên bị mất, bên gửi truyền lại các gói tin đó. Khi đó bên nhận nhận được tiếp theo gói tin có số thứ tự 0 - lại chính là gói tin 0 đầu tiên được gửi ban đầu.
Trong trường hợp thứ hai, hình 4.18(b), ACK cho ba gói tin được chuyển đi thành công. Như vậy cửa sổ bên gửi sẽ trượt về phía trước và gửi đi các gói tin 4, 5, và 6 với số thứ tự tương ứng là 3, 0, 1. Nếu gói tin với số thứ tự 3 bị mất, lúc ấy gói tin có số thứ tự 0 đến, gói tin này chứa dữ liệu mới (không phải gói tin 0 truyền lại). Rõ ràng có một bức “màn chắn” giữa bên gửi và bên nhận vì bên nhận không thể “nhìn” thấy hành động từ bên gửi. Bên nhận chỉ quan sát được gói tin nào nó nhận được hay gửi đi. Hai trường hợp trong là tương tự nhau. Không có phương pháp nào phân biệt được gói 0 được truyền lại hay gói 5 được truyền lần đầu tiên. Rõ ràng nếu kích thước cửa sổ nhỏ hơn khoảng số thứ tự một đơn vị thì hệ thống không còn làm việc đúng đắn. Nhưng độ lớn cửa sổ nên là bao nhiêu? Người ta chứng minh được rằng độ lớn cửa sổ phải bé hơn hoặc bằng một nửa khoảng số thứ tự với giao thức SR.
Chúng ta giả thiết môi trường truyền không tin cậy ở dưới dẫn đến việc các gói tin có thể bị giữ lại trên đường truyền. Đây là việc ít khi xảy ra khi kênh truyền giữa phía gửi và phía nhận là một môi trường vật lý thực sự. Tuy nhiên khi kênh truyền này lại là một mạng máy tính thì việc một gói tin bị giữ lại trên kênh truyền hoàn toàn có thể xảy ra. Hệ quả của nó là xuất hiện một gói tin với số thứ tự hay số biên nhận là x trong khi cả cửa sổ nhận và gửi đều không chứa x. Trong trường hợp này, kênh truyền bị coi là một bộ đệm, có thể tuỳ ý phát mại gói tin ở bất cứ thời điểm nào. Vì số thứ tự có thể được sử dụng lại nên trong một số trường hợp sẽ xảy ra hiện tượng trùng lặp gói tin. Giải pháp trong thực tế là bảo đảm số thứ tự không được sử dụng lại cho đến khi bên gửi có thể tương đối chắc chắn về gói tin với số thứ tự x được gửi trước đây không còn tồn tại trong mạng. Điều này được thực hiện với giả thiết một gói tin không thể “Tồn tại” trong mạng trong một khoảng thời gian lớn hơn một khoảng thời gian cố định nào đấy. Thời gian “sống” lớn nhất của gói tin xấp xỉ là 3 phút với mạng TCP cao tốc [RFC 1323].
CHƯƠNG 5: LẬP TRÌNH SOCKET
Socket là một phương pháp để thiết lập kết nối truyền tin giữa một chương trình yêu cầu dịch vụ và một chương trình cung cấp dịch trên mạng và đôi khi trong máy tính. Theo định nghĩa các chức năng mỗi tầng trong mô hình OSI, tầng mạng đảm nhiệm liên kết giữa đầu cuối với đầu cuối thì tầng vận tải đảm nhiệm liên kết giữa hai tiến trình. Mỗi socket là một điểm cuối trong một kết nối và có thể được xem như kết hợp của tầng mạng và tầng vận tải, do đó nó phải bao gồm một cặp địa chỉ logic của tầng mạng và số hiệu cổng của tầng vận tải. Một socket trên máy yêu cầu dịch vụ có địa chỉ mạng được cấp sẵn để gọi một socket trên máy cung cấp dịch vụ. Một khi socket đã được thiết lập phù hợp, hai máy tính có thể trao đổi dịch vụ và dữ liệu.
Khái niệm lập trình socket do trường đại học Berkeley để xuất vào những năm 1980, xuất hiện lần đầu tiên trong hệ điều hành Unix là Berkeley Sockets Interface, một chương trình thiết bị được thiết kế để giúp máy tính nối mạng có thể trao đổi thông tin với nhau. Giữa những năm 1990, Microsoft đã tạo riêng socket của họ là Windows Sockets (còn gọi là WinSock), nhờ vậy các ứng dụng Windows có thể trao đổi thông tin với nhau qua mạng máy tính.