在 NAT 后面工作 - 一种设备通信方案

Working behind the NATs - a scheme for device communication

我正在尝试提出一种解决方案,使嵌入式设备(基于 xMega128(C))和 Android 应用程序之间能够进行数据交换。问题是数据交换必须通过互联网进行,嵌入式设备和移动设备都可以 运行 应用程序可以位于不同的 NAT 之后,使用不同的 ISP、3G、LTE 等进行连接

我试过 UDP 打洞,但它不适用于对称 NAT。带预测的多孔冲孔也不能保证 100% 的可靠性。我也考虑过使用 ICE,但是 ICE C 库(pjnath、libnice)与硬件 chosen 不兼容(libs 需要 os)。现在我正在考虑实施或使用(如果存在)流量中继服务器,但这对我来说似乎是一个黑客。

还有其他我没有考虑过的选择吗?任何帮助将不胜感激。

理想情况下,通信方案为:

此外,如果这有帮助,设备和应用程序之间的数据交换不是非常高强度——大约每小时 1 个会话,每个会话约 50 条消息,它们之间有 10-20 秒,每条消息大约100 个字节。

只要两个端点都位于您无法控制的不同 NAT 之后,它就无法可靠地工作。决不。你需要一个继电器。

您所描述的是有效的点对点或其子集,要使其可靠地工作需要大量工作。如果点对点失败,您通常会回退到中继服务器。可以做到,但是工作量很大。您的要求清单也很陡峭...

100% reliable

没有所谓的可靠连接。您需要为应用程序构建容错功能以使其可靠。

relatively low-latency (3 seconds absolute max)

很多时候你会受到物理学的限制,即光速。低延迟很难。

scalable (say up to 500k devices in the future)

我不知道这是什么意思,即这是并发连接数吗?

来自 NAT 穿越的维基百科

Many techniques exist, but no single method works in every situation since NAT behavior is not standardized. Many NAT traversal techniques require assistance from a server at a publicly routable IP address. Some methods use the server only when establishing the connection, while others are based on relaying all data through it, which adds bandwidth costs and increases latency, detrimental to real-time voice and video communications.

它有时会起作用,即它不可靠,因此您需要使用多种方法使其可靠。