3

我正在尝试建立一个 P2P 即时消息系统，虽然我还没有遇到问题，但我预计如果客户端在本地 LAN 上的 NAT 后面我会遇到一些问题（阅读：每个人。）

让我解释一下算法，你就会明白我的意思。共有三个组件： 一个服务器和两个客户端 - 客户端 Alice 想要发起与客户端 Bob 的聊天。服务器只跟踪谁在线，但实际对话不会通过服务器（为了客户的隐私）

因此，Alice 和 Bob 都登录到服务器 - 从临时端口连接到服务器的静态侦听端口。他们告诉服务器他们正在侦听传入聊天请求的静态端口。Alice 询问服务器她如何联系 Bob。服务器使用 ipaddress 和侦听端口等进行响应。Alice 在该 IP 地址和端口上向 Bob 发送请求以建立连接。希望这是有道理的。

如果 Bob 在 NAT 之后，那么肯定他可以与服务器通信，因为他是开始通信的人。但是 Alice 的请求不会发送给他，因为尚未为他正在侦听来自 Alice 的 IP 地址的聊天请求的端口设置 NAT 关系。

是否有人知道某种黑魔法可以使这项工作发挥作用？会不会是个问题？开发还没有那么远，我还没有真正遇到这个问题。

显而易见，我不想让最终用户为他们的监听端口配置端口转发。

对于前面提到的黑魔法，客户端和服务器都在java中，但我通常只是在算法之后（如果可能的话）

4

2 回答 2

1

检查冰。

大多数 P2P 框架，如 Java 中的 JXTA，都使用中继服务器的原理。

假设 A 想连接到 B 并且 B 在防火墙后面。

- both A and B establish ** outbound ** synchronous (or full duplex/websockets) connections to Relay Server R
- A signals to R that it wants to transmit data to B
- R 'binds' the inbound connection from A to the outbound connection to B (the synchronous HTTP response to B for instance)
- A sends data to R which is relayed to B

这里的关键是所有连接都是出站建立的（通常在众所周知的端口上使用友好的防火墙协议，如 HTTP）

当你有分布式中继时，事情显然会更复杂一些。然后，您需要通过依赖分布式哈希图 (DHT) 来维护信息的中继来维护到各个对等点的路由的“路由器”。

于 2012-10-02T07:55:18.093 回答
0

没有黑魔法。如果两个客户端都在 NAT 之后，则消息必须通过第三方（服务器）。如果只是关于短信，我会考虑将这种架构用于所有通信（如果隐私是一个问题，你可以考虑某种加密）。服务器（或服务器）将负载更多，但您会获得更简单（在某些情况下更可靠）的架构。例如，如果 Alice 向 Bob 发送消息，并且 Bob 有一些网络问题，服务器可以将消息排队并保留一段时间，然后再传递（即使 Alice 离线）。另一件事是会议（群）聊天。仅使用 P2P 处理它更具挑战性（但可能非常有趣）。但是如果所有客户端都在 NAT 之后，您会遇到同样的问题。我还强烈建议为所有传输和接收的消息（来自客户端和服务器）实现应用程序级确认机制。TCP/IP 等协议不够可靠。

于 2012-10-02T07:50:33.207 回答