Giao thức hiệu quả nhất để phát đa hướng đáng tin cậy là gì?

Question

Khi người gửi cần phát đa hướng một khối lượng dữ liệu tương đối lớn (nói vài megabyte/giây) một cách đáng tin cậy qua Ethernet với số lượng người nhận khiêm tốn (nói dưới một chục) trên cùng một mạng con, hiệu quả nhất giao thức? Bởi đáng tin cậy Tôi có nghĩa là nếu một gói bị mất, giao thức đảm bảo rằng nó được gửi lại như vậy mà không có mất dữ liệu trong bất kỳ người nhận. Thuật ngữ hiệu quả khó xác định hơn nhiều, nhưng giả sử chúng tôi muốn tối đa hóa thông lượng và giảm thiểu băng thông mạng với mức sử dụng CPU khiêm tốn ở cả hai đầu. Đó vẫn chưa phải là một định nghĩa rõ ràng nhưng đó là điều tốt nhất tôi có thể nghĩ ra. Giao thức hướng luồng hoặc giao thức hướng thư sẽ được chấp nhận.

Tôi đánh giá cao các ví dụ trong thế giới thực và tôi sẵn sàng chấp nhận câu trả lời chủ quan, tức là giao thức multicast yêu thích của bạn, nếu bạn có thể giải thích các ưu và nhược điểm của nó.

Answer 1

BitTorrent!

Không, nghiêm túc. Bạn có thể muốn read up on it.

UDP rất hữu ích cho phát đa hướng nhưng không cung cấp sự đảm bảo mà bạn đang tìm kiếm - BitTorrent sẽ yêu cầu bạn truyền nhiều hơn một bản sao đầy đủ từ nguồn gốc, nhưng nó vẫn khá hiệu quả và cung cấp các đảm bảo hữu ích, đặc biệt xem xét bao nhiêu checksumming được thực hiện trên mỗi "chunk" của dữ liệu thông qua cùng.

Answer 2

Ví dụ thực tế: TIBCO Rendezvous.

Dữ liệu được gửi qua multicast với số thứ tự. Một khách hàng phát hiện một số thứ tự thiếu sẽ gửi ra một messge trên nhóm multicast "hey, tôi bị mất gói 12345". Máy chủ sẽ phát lại dữ liệu đó. Máy chủ có một lượng dữ liệu có thể cấu hình để đệm trong trường hợp máy khách yêu cầu.

Vấn đề:

Hãy tưởng tượng có một khách hàng duy nhất giảm một nửa trong số các gói tin của mình, và 100 khách hàng khỏe mạnh. Máy khách này gửi yêu cầu truyền lại cho mọi gói khác. Máy chủ bắt đầu gây ra đủ tải trên một trong những máy khách khỏe mạnh như vậy mà nó bắt đầu thả các gói và yêu cầu truyền lại. Tải bổ sung từ đó làm cho một ứng dụng khách khỏe mạnh khác bắt đầu yêu cầu truyền lại. Và cứ thế. Một kết quả thu hẹp tắc nghẽn.

Tibco cung cấp cách giải quyết, cắt đứt người đăng ký gửi quá nhiều yêu cầu truyền lại. Điều này làm cho nó khó khăn hơn cho một thuê bao duy nhất gây ra một sự sụp đổ tắc nghẽn.

Cách giải quyết khác để hạn chế nguy cơ tắc nghẽn sụp đổ là để giới hạn số lượng dữ liệu mà một máy chủ sẵn sàng truyền lại.

Tibco cũng nên cung cấp chẩn đoán trong client và server là liệu multicast hoặc unicast yêu cầu truyền lại, và truyền lại chính nó. Họ không. (Đối với máy chủ, bạn có thể unicast truyền lại nếu chỉ có một khách hàng yêu cầu nó trong một cửa sổ thời gian nhất định, cho khách hàng mà bạn có thể unicast yêu cầu truyền lại nếu máy chủ đã nói với bạn - trong gói truyền lại - rằng bạn là người duy nhất yêu cầu truyền lại và xin vui lòng unicast các yêu cầu trong tương lai)

Về cơ bản bạn sẽ phải quyết định giữa mức độ mạnh mẽ bạn muốn đảm bảo rằng khách hàng nhận được dữ liệu so với nguy cơ sụp đổ tắc nghẽn. Bạn sẽ phải đoán trước xem gói tin bị bỏ đi ở đâu và việc truyền lại có được gửi đi một cách hiệu quả nhất hay không.Nếu máy chủ hiểu dữ liệu và có thể quyết định không gửi lại dữ liệu nếu có dữ liệu cập nhật được gửi đi (điều đó làm cho việc truyền lại không liên quan), bạn ở vị trí tốt hơn nhiều so với khung công tác như Tibco RV.

Đôi khi việc hiểu dữ liệu có thể dẫn đến giả định sai. Ví dụ, dữ liệu thị trường - nó có vẻ lúc đầu OK để không truyền lại một báo giá khi có một báo giá cập nhật. Nhưng sau đó, bạn có thể thấy rằng một thuê bao đã giữ một lịch sử báo giá, không chỉ cố gắng theo dõi các báo giá hiện tại. Có lẽ bạn có thể có các yêu cầu khác nhau tùy thuộc vào thuê bao, và một số khách hàng sẽ thích unicast TCP vs multicast.

Tại một thời điểm nào đó, bạn sẽ cần đưa ra quyết định tùy ý trên máy chủ về số lượng dữ liệu cần đệm trong trường hợp truyền lại hoặc khách hàng chậm.

Answer 3

Đây là câu hỏi nghiên cứu mở; có các giải pháp thương mại có sẵn nhưng có giá cực kỳ đắt đỏ. Chúc may mắn.

Answer 4

Tôi nghĩ có lẽ bạn nên xem Stream Control Transmission Protocol làm phương án thay thế cho UDP/multicasting nếu bạn thực sự muốn truyền đồng thời đáng tin cậy cho nhiều khách hàng.

Answer 5

Tiếp theo từ TIBCO, giao thức PGM là một multicast đáng tin cậy mở tiêu chuẩn với nhiều tối ưu hóa hiệu quả làm việc ở quy mô rất lớn với gia tốc phần tử mạng. PGM được phát triển bởi TIBCO và CISCO và là một giao thức tùy chọn bên dưới TIBCO Rendezvous, giao thức mặc định là TRDP rất giống với thiết kế.

Bạn có thể tính toán hiệu quả lý thuyết như được liệt kê vào đây để PGM,

http://code.google.com/p/openpgm/wiki/PgmPerformance

Đáng tiếc là phần tử mạng thế giới thực, NIC và kiến ​​trúc máy tính nói chung thực hiện ít hơn rất nhiều so với mức tối đa lý thuyết.

Answer 6

http://www.jgroups.org/

Answer 7

Tôi có thể đề xuất UFTP. Nó sử dụng một cơ chế NAK dựa trên để xác định các gói tin để truyền lại và có một tùy chọn cho một tỷ lệ truyền cố định hoặc kiểm soát tắc nghẽn sử dụng TFMCC.

Mỗi tệp được gửi đi, trong đó thẻ đầu tiên truyền toàn bộ tệp, trong khi các lần truy cập tiếp theo chỉ gửi truyền lại. Mỗi khách hàng theo dõi các gói tin mà nó nhận được và những gói dữ liệu nào bị bỏ sót. Tại các trạm kiểm soát cụ thể (và ở cuối của một pass), nếu người nhận bỏ lỡ bất kỳ gói nào từ trạm kiểm soát cuối cùng, nó sẽ gửi một NAK liệt kê các gói bị bỏ qua. Điều này có lợi thế là người nhận tổn thất thấp sẽ kết thúc trước khi người nhận tổn thất cao. UFTP cũng có thể được cấu hình để giảm người nhận có phần trăm NAK vượt quá ngưỡng nhất định.

Bằng cách giới hạn NAK chỉ đối với những người nhận có sự mất mát, nó làm giảm nguy cơ sụp đổ tắc nghẽn, đó là người gửi bị choáng ngợp bởi phản hồi của người nhận.

Tiết lộ: tác giả của UFTP.