可靠的多播库C ++

Question

我知道this和this stackoverflow问题，它们回答了已知的方法来实现＆＃34; Reliable Multicast＆＃34;但是我已经遇到一些网站提到甚至路由器也应该被编程来处理通过UDP设计的自定义协议，这是真的吗？

基本上我想在我的应用程序中使用Multicast，我希望不要对更改路由器施加任何限制，以便以可靠的方式配置自定义协议来处理UDP，例如我正在考虑实现/使用PGM协议通过UDP来处理多播，但是有人说路由器也应该支持PGM，这限制了我提供解决方案，因为客户应该更改我的解决方案的基础设施，这是没有根据的。

如果有任何解决方案我可以实现以可靠的方式处理UDP数据包而不对网络基础设施进行任何更改，请告诉我。

提前致谢。

编辑：

我并不是说我不想在路由器中启用多播，我肯定会在路由器中启用多播路由。当我读到关于PGM实现时，有人说甚至路由器应该是支持PGM的，我认为它与商店中的商用路由器不同。我的理解错了吗？

Answer 1

如果使用多播，则需要向网络基础架构添加多播支持要求。除非在网络设备（组播路由器）上启用了组播路由，否则组播只能在一个LAN内使用。

通过互联网基础设施的唯一可靠方式是单播。

更新：在网络层上执行多播路由，并且多播路由器不需要了解有关传输/应用层的任何信息。在某些情况下，网络层需要有关应用层的知识，但几乎所有这些情况都与NAT ALG（应用级网关）有关。

顺便说一下，通过Internet传递组播的可能方法之一是隧道协议（GRE，IP over IP等）。

Answer 2

如果您不能或不想配置路由器转发组播流量或以其他方式处理第三方协议，则需要通过单播链路隧道传输组播流量。 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

这些代理也能够在NATed环境中工作：

  

如果客户端代理位于防火墙后面，则代理可以发送心跳   消息到上游代理在防火墙上做一个针孔   上游服务器代理可以连接到。如果客户端代理也是   NATed，上游服务器代理可能不知道的IP /端口   客户端代理，因此服务器代理可以配置为等待   心跳消息，并使用心跳来自的IP /端口   下游地址。如果服务器代理也在防火墙后面或   NAT，具有可公开访问的IP的计算机上的第二个服务器代理   可以插入第一个服务器代理和客户端代理之间。   在这种情况下，第一个服务器代理被设置为使用第二个作为   其下游地址，第二个服务器代理设置为使用   它从客户端代理接收的第一个心跳作为其下游   地址。

我是这个软件的作者，所以如果您需要有关如何进行设置的指示，请通过UFTP页面底部的链接向我发送电子邮件，我们将看到我们能做些什么。

更新

在PGM的情况下，它可以配置为在应用层（即UDP之上）或传输层（即直接在IP之上）运行。如果PGM在传输层运行，那么您可能需要担心路由器对其有特殊支持。相反，UFTP严格在应用层运行。