可靠組播庫C++

Question

我知道，回答已知的方法來實現「可靠組播」不過關，晚了，我所遇到的一些網站，其中提到甚至路由器也應編程爲this和this計算器問題處理通過UDP設計的自定義協議，這是否正確？

基本上我想爲我的應用程序使用多播，我想不想強制更改路由器配置自定義協議以可靠的方式處理UDP的任何限制，例如我正在考慮實施/使用PGM協議UDP來處理組播，但有人說路由器也應該支持PGM，這就限制了我提供解決方案，因爲客戶應該改變我的解決方案的基礎設施，這是沒有根據的。

請讓我知道是否有任何解決方案可以實現以可靠的方式處理UDP數據包，而不會對網絡基礎架構進行任何更改。

在此先感謝。

編輯：

我的意思並不是說我不想啓用路由器組播，我肯定會啓用路由器組播路由。當我讀到關於PGM實現的時候，有人說甚至路由器應該是PGM能力，我認爲這是路由器與商店中的商用路由器不同。我的理解錯了嗎？

Answer 1

如果您不能或不想配置路由器來轉發多播流量或以其他方式處理第三方協議，則需要在單播鏈路上傳送多播流量。 UFTP能夠通過使用UFTP代理服務器進行組播隧道。

從手冊頁：服務器代理，客戶代理 ，或響應代理：

代理可以在三種模式中運行。

服務器代理通常是服務器本地的，並且充當多播隧道的上游端 。它偵聽公共多播地址 （以及指定時的私有多播地址）並將下行數據包 轉發到下游的特定地址。上傳數據包 轉發回來的通告發源於。

客戶端代理通常位於一個或多個客戶端本地，並形成多播隧道的下游端。它從一個或多個服務器代理接收來自 的單播數據，並將下行流量轉發到在數據包報頭中指定的組播地址 。來自客戶端的上游流量 被收集並且在公告 來自聚合響應的情況下被轉發回去。

下面是其中一個服務器發送的多播消息到本地網絡的典型配置的示圖，以及一個或多個服務器代理單播消息發送到對應的客戶端代理，而這又多播的消息發送到其本地網絡。

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
x            Network A x 
x ----------            x 
x | Server |            x 
x ----------            x 
x  |             x 
x  | multicast          x 
x  |             x 
x  |-----------------------------------------  x 
x  |     |     |  x 
x  v     v     v  x 
x ---------------- ----------------  ---------- x 
x | Server Proxy | | Server Proxy |  | Client | x 
x ---------------- ----------------  ---------- x 
x  |     |        x 
x  | unicast   | unicast     x 
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
     |     | 
     |     ------------ 
     |        | 
xxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxx 
x  |  Network B x x  |  Network C x 
x  v     x x  v     x 
x ----------------   x x ----------------  x 
x | Client Proxy |   x x | Client Proxy |  x 
x ----------------   x x ----------------  x 
x  |     x x  |     x 
x  | multicast  x x  | multicast  x 
x  |     x x  |     x 
x  |-------------  x x  |------------  x 
x  |   |  x x  |   |  x 
x  v   v  x x  v   v  x 
x ---------- ---------- x x ---------- ---------- x 
x | Client | | Client | x x | Client | | Client | x 
x ---------- ---------- x x ---------- ---------- x 
x       x x       x 
xxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxx 

這些代理還能夠在NAT的環境中工作的：

如果客戶端代理位於防火牆後面，代理可以發送心跳 消息發送到上游代理使針孔在 上游服務器代理可以連接到的防火牆中。如果客戶端代理也是 NAT，則上游服務器代理可能不知道客戶端代理的IP /端口，因此服務器代理可以配置爲等待心跳消息，並使用IP /端口發送心跳從它的 下游地址。如果服務器代理也位於防火牆或NAT後面，則可以在第一個服務器代理和客戶端代理之間插入具有可公開訪問的IP 的計算機上的第二個服務器代理。 在這種情況下，第一個服務器代理設置爲使用第二個服務器代理作爲其下游地址，第二個服務器代理使用 作爲其下游 地址，將其從客戶端代理接收到的第一個心跳使用到 。

我是這個軟件的作者，所以如果你需要關於如何設置此指針，通過鏈接給我發送電子郵件在UFTP頁面底部，我們將看看我們能做些什麼。

更新：

在PGM的情況下，它可以被配置爲在任一應用層上運行（即，在UDP上）或在傳輸層（即直接在IP的頂部）。如果PGM運行在傳輸層，那麼您可能需要擔心路由器對它有特殊的支持。相反，UFTP嚴格在應用層運行。

Answer 2

如果您使用多播，則需要向網絡基礎架構添加多播支持要求。除非在網絡設備（多播路由器）上啓用多播路由，否則多播將僅在一個LAN內可用。

通過互聯網基礎設施的唯一可靠途徑是單播。

更新：組播路由在網絡層上執行，組播路由器不需要知道有關傳輸/應用層的任何信息。在某些情況下，網絡層需要關於應用層的知識，但幾乎所有情況都與NAT ALG（應用層網關）有關。

順便說一下，通過互聯網傳遞多播的可能解決方案之一是隧道協議（GRE，IP over IP等）。