triển khai ack qua UDP?

Question

Chúng tôi có một hệ thống (được xây dựng trong C) tại chỗ thực hiện truyền thông qua UDP. Gần đây chúng tôi đã tìm thấy một điều cần thiết để đảm bảo việc phân phối các gói tin. Câu hỏi của tôi là: những gì sẽ là bổ sung tối thiểu cho một hệ thống dựa trên UDP để đảm bảo giao hàng bằng cách sử dụng gói ack? Ngoài ra, lý tưởng mà không cần phải thao tác các tiêu đề gói. Chúng tôi có quyền kiểm soát mức ứng dụng trên các gói bao gồm số thứ tự và cờ ack/nack. Tôi tự hỏi nếu đây là một nguyên nhân bị mất và bất cứ điều gì chúng tôi cố gắng làm về cơ bản sẽ là một phiên bản lỗi và hỏng của TCP. Về cơ bản, có một cải tiến nhỏ gọn mà chúng tôi có thể thực hiện để đạt được phân phối được đảm bảo (chúng tôi không cần nhiều tính năng của TCP như kiểm soát tắc nghẽn, vv). Cảm ơn!

Answer 1

Sự cố khó khăn. Tôi sẽ nói, bạn sẽ không thể đạt được độ tin cậy của TCP. Tuy nhiên, tôi hiểu rằng đôi khi, bạn cần phải có UDP đáng tin cậy.

Gamedev forum

RUDP (một chút Hardcore)

Old Thread about reliable UDP

Answer 2

Hãy xem Chương 8 và Chương 20 của Steven UNIX Network Programming, volume 1. Ông bao gồm một số cách tiếp cận khác nhau. Phần 20.5 "Thêm độ tin cậy cho một ứng dụng UDP" có lẽ là thú vị nhất đối với bạn.

Answer 3

Tôi có câu hỏi đang chạy here đang thu thập câu trả lời cho "Những gì bạn sử dụng khi bạn cần UDP đáng tin cậy". Câu trả lời có thể nhiều hơn bạn muốn hoặc cần nhưng bạn có thể xem xét một số giao thức đã được xây dựng trên UDP và chỉ lấy phần ACK mà bạn cần. Từ công việc của tôi với giao thức ENet (một giao thức UDP đáng tin cậy), tôi mong rằng bạn cần một số thứ tự trong mỗi gói dữ liệu UDP, một cách để gửi ACK cho các gói dữ liệu mà bạn đã nhận, một cách giữ datagrams mà bạn đã gửi cho đến khi bạn nhận được ACK cho chúng hoặc chúng hết thời gian và cách định thời gian gửi lại datagram mà bạn chưa nhận được ACK ... Tôi cũng sẽ thêm thời gian chờ khi bạn quyết định rằng bạn sẽ không bao giờ cung cấp một gói dữ liệu cụ thể, và, tôi đoán, một cuộc gọi lại đến lớp ứng dụng của bạn để thông báo cho nó về sự thất bại này ...

Answer 4

TCP xen lẫn 3 dịch vụ có thể có liên quan (okay TCP thực hiện nhiều hơn, nhưng tôi sẽ chỉ nói về 3.)

1. In-lệnh giao hàng
2. giao hàng đáng tin cậy
3. kiểm soát dòng chảy

Bạn chỉ cần nói rằng bạn không cần phải kiểm soát dòng chảy, vì vậy tôi thậm chí sẽ không giải quyết đó (làm thế nào bạn sẽ quảng cáo kích thước cửa sổ, v.v., ngoại trừ việc bạn có thể sẽ cần một cửa sổ. tôi sẽ nhận được nó.)

Bạn đã nói rằng bạn cần giao hàng đáng tin cậy. Điều đó không quá khó - bạn sử dụng ACK để cho thấy rằng người gửi đã nhận được một gói. Basic giao hàng đáng tin cậy trông giống như:

1. Sender gửi các gói tin
2. Receiver nhận gói tin, và sau đó gửi một ack
3. Nếu người gửi không nhận được một ack (bằng cách của một bộ đếm thời gian), ông sẽ gửi lại cái túi.

Ba bước này không giải quyết những vấn đề này:

1. gì nếu ACK bị mất?
2. Điều gì xảy ra nếu các gói dữ liệu hết hàng?

Vì vậy, đối với ứng dụng của bạn, bạn cho biết bạn chỉ cần giao hàng đáng tin cậy - nhưng không nói bất cứ điều gì về việc cần chúng theo thứ tự. Điều này sẽ ảnh hưởng đến cách bạn triển khai giao thức của mình.

(ví dụ nơi trong trật tự không quan trọng:.. Bạn đang sao chép hồ sơ nhân viên từ máy này sang máy khác không quan trọng nếu kỷ lục của Alice được nhận trước khi Bob, miễn là cả hai đạt được điều đó)

Vì vậy, đi trên giả định rằng bạn chỉ cần đáng tin cậy (vì đó là những gì bạn nói trong bài viết của bạn), bạn có thể đạt được điều này một số cách.

Người gửi của bạn có thể theo dõi các gói chưa được trả lời. Vì vậy, nếu nó gửi # 3, 4, 5, và 6, và không nhận được một ACK cho 3 và 4, sau đó người gửi biết rằng nó cần phải truyền lại. (Mặc dù người gửi không biết liệu các gói 3 và 4 có nhiều hay không, hoặc nếu các ACK của chúng bị mất. Dù sao thì chúng ta cũng phải truyền lại.)

Nhưng sau đó người gửi của bạn có thể thực hiện các ACK tích lũy - như trong ví dụ trên , nó sẽ chỉ ack # 6 nếu nó đã nhận được 3, 4, và 5. Điều này có nghĩa rằng người nhận sẽ thả gói 6 nếu nó chưa nhận được trước đó. Nếu mạng của bạn là rất đáng tin cậy, thì đây có thể không phải là một lựa chọn tồi.

Các giao thức được mô tả ở trên, tuy nhiên, có cửa sổ - nghĩa là, người gửi gửi bao nhiêu gói cùng một lúc? Điều đó có nghĩa rằng bạn cần một số loại cửa sổ, nhưng không phải cho mục đích kiểm soát dòng chảy. Làm thế nào bạn sẽ truyền tải kích thước cửa sổ?

Bạn có thể làm điều đó mà không cần cửa sổ bằng cách có hằng số kích thước cửa sổ hoặc bằng cách thực hiện một việc như dừng và đợi. Các cựu có thể là một lựa chọn tốt hơn.

Dù sao, tôi đã không trực tiếp trả lời câu hỏi của bạn, nhưng tôi hy vọng tôi đã chỉ ra một số điều đáng xem xét khi kiến ​​trúc này. Nhiệm vụ có "chuyển đáng tin cậy" mà không có bộ phận kiểm soát dòng chảy (như cửa sổ) và không liên quan đến trật tự là khó! (Hãy cho tôi biết nếu tôi nên cung cấp thêm chi tiết về một số nội dung này!)

Chúc may mắn!

Answer 5

Cách tốt nhất để triển khai ack là thực hiện nó trong lớp ứng dụng. CoAP là một ví dụ về một giao thức ứng dụng chạy trên udp nhưng cung cấp truyền dữ liệu đáng tin cậy. Nó giữ một id tin nhắn cho tất cả các tin nhắn xác nhận (CON) và gửi một người nhận gửi một gói ack với cùng một id tin nhắn. Tất cả các trường id và id tin nhắn được lưu giữ ở phần lớp ứng dụng. Vì vậy, nếu người gửi không nhận được một gói Ack với id tin nhắn gửi bởi anh ta, nó lại truyền gói đó. Nhà phát triển ứng dụng có thể sửa đổi giao thức cho phù hợp với nhu cầu cần thiết để truyền dữ liệu đáng tin cậy.