廣播像TCP與TCP的可靠性

Question

我正在處理完全在單個網絡內運行的.net解決方案。當用戶對系統進行更改時，我想發佈一條通知並讓其他人都能聽到並據此採取行動。有沒有一種方法可以像這樣廣播消息（就像UDP可以讓你這樣做），同時保證交付（如TCP）？

這是在一個小網絡（30個客戶端）上，如果這樣做會有所作爲。

Answer 1

幾乎所有的遊戲都需要UDP的快速反應屬性（以及較小程度的無連接屬性）和TCP的可靠性。他們所做的是在UDP之上建立自己的可靠協議。這使得他們可以將數據包分組發送到任何地方，並可選地使數據包可靠。

可靠的數據包系統通常是一個簡單的重試直到確認系統比TCP更簡單，但有協議超出TCP可以提供的。

你的情況聽起來很簡單。你可能會自己做出最乾淨的解決方案 - 讓每個客戶都回復一個「我聽到你」的迴應，並讓服務器繼續嘗試，直到它得到它（或放棄）。

如果你想要更多的東西，大多數自定義協議庫都是用C++編寫的，所以我不確定它們對你有多大的用處。但是，我的知識已經有幾年了 - 現在可能已經有一些協議被移植了。嗯...... RakNet和enet是想到的兩個C/C++庫。

Answer 2

做一個RDP多播。

Answer 3

你可以做的是，廣播後有客戶端發起tcp連接。否則，您只需保留所有客戶端的列表，並自行啓動與每個客戶端的連接。

Answer 4

我認爲有三個選項，從廣義上說：

1. 相反廣播UDP的，你可以創建一個實體（線程，進程，服務器，服務，或任何事情是在你的解決方案存在），它保存訂戶列表並向它們發送單播UDP消息。
2. 使用UDP多點傳送，但是你必須編寫某種機制來爲你提供可靠的傳送（即重試，超時等）。這也意味着你必須得到你的客戶的答覆。
3. 如果你不害怕的實驗傳輸協議，你可能看here的建議，

Answer 5

你可以使用Spread做羣組通信。

Answer 6

您可以在應用程序層實現您自己的TCP類行爲。

因此，例如，你會發送UDP廣播，但期待每個主機的回覆響應。如果您在X秒內沒有收到回覆，則發送另一個等等，直到達到某種閾值。如果達到閾值（即主機完全沒有響應），則報告錯誤。

要做到這一點，你需要一個預先定義的主機列表，以期望得到迴應。

Answer 7

看看sctp具有TCP和UDP功能的組合。有一個窗口implementation可用。

Answer 8

同比應該看一看的標準（面向NACK的可靠組播）規範。你可以找到information about Norm here。

的NORM協議被設計爲提供 批量數據對象的端至端可靠傳輸 或流過 通用IP組播路由和 轉接服務。 NORM使用 選擇性的，否定確認 （NACK），用於傳輸 可靠性機制，並提供額外的 協議機制 發送者和接收者

它稍微間與 有限的「先驗」協調進行 可靠多播會話在軍事世界中非常知名。

Norm specs.

Norm Source

Answer 9

@epatel - 我的第二個建議，SCTP（我投了，但不能在這裏評論卻又如此額外的東西）。

SCTP具有許多強大功能和靈活性。您可以將您的連接細分爲多個流，並選擇每個流的可靠性以及是否有序。或者，使用Partially Reliability擴展名，您可以根據每條消息控制可靠性。

Answer 10

廣播是不是你想要的。由於可能並可能會連接到此網絡的設備不關心您的消息，因此您應該使用多播。與必須發送給網絡上的每個客戶端並由其處理的廣播消息不同，多播消息僅被傳遞給感興趣的客戶端（即那些有意接收該特定類型的消息並對其執行操作的客戶端）。

如果以後擴展該系統，以便它需要路由在大型網絡中，多播可以擴展到，而廣播也不會，所以你得到你以後可能會欣賞的可擴展性的好處。同時，您可以避免在不需要看到這些「更改內容」消息的交換機和其他設備中消除不必要的開銷。

Answer 11

你可能要考慮RFC 3208「PGM可靠傳輸協議規範」。

這裏是抽象：

實際通用多播（PGM） 是一種可靠的多播傳輸
協議用於需要 有序或無序的應用，
無重複的，多播數據從 輸送多個來源到
多個接收器。 PGM保證 該組中的接收器要麼從 接收來自 傳輸和修復的所有數據分組，要麼是 能夠檢測到不可恢復的數據 分組丟失。PGM具體爲 ，作爲 多播應用的可行解決方案，具有基本的 可靠性要求。其中心 的設計目標是簡單的 操作，適當考慮到 的可擴展性和網絡效率。

Answer 12

爲什麼從頭開始構建一些東西，如果你可以使用庫？特別是對於這樣的小項目？

嘗試使用Emcaster，它本身使用可靠的多播消息傳遞 - PGM，是用.NET編寫的並且具有完整源代碼。你會得到很好的酒吧/子引擎與主題過濾隨時可用。或者您可以從代碼中學習如何做到這一點，並在其上創建自己的擴展。

Answer 13

我認爲TCP在這些場景中最令人煩惱的特性是將傳入數據包按其原始順序排序的能力/方式 - 流的概念。在到達字節之前，您無法讀取一個字節。

如果你沒有它，你有機會擁有你的協議，快速和可靠的，但不是訂購數據包！要管理它們是根本不可能的，因爲在收到丟失數據包的其他副本之前，您無法排序字節，這是主要的折衷。

Answer 14

創建一個TCP服務器。讓每個客戶連接。在與客戶端的TCP協議中，使用以下消息的總大小的2字節前綴創建每個數據包。

客戶端然後在套接字上調用read(max_size=2)來確定下一條消息的大小，然後read(max_size=s)收集消息。

您得到可靠的，有序的消息，很簡單。你不需要這個消息框架。

Answer 15

您可以使用Message Broker，如ActiveMQ。
將您的消息發佈到某個主題並讓客戶端註冊該主題的持久訂閱，這樣即使他們不在線也不會錯過任何消息。

的Apache ActiveMQ是一個完整的 JMS客戶端用Java編寫的一起消息代理 。然而，Apache ActiveMQ是 ，其設計用於通過諸如Stomp和 OpenWire等協議的數字進行通信，並且支持 號碼的不同語言特定的 客戶端。

客戶端平臺支持包括C＃和.NET

Answer 16

你最好肯定想看看Pragmatic General Multicast：發送

雖然TCP使用的ACK確認的數據包組（東西會是，在多播上不經濟），PGM使用否定確認（NAK）的概念。

欲瞭解更多G-diving，您正在尋找的術語是reliable multicast。也看看Multipath TCP。