我有一个提供商 (A)，它想通过传入 TCP 连接向我们发送数据。不幸的是，消费服务 (B) 无法接收传入 TCP 连接。此外，它没有静态 IP，这是另一个要求。
解决这个问题的一种方法是将传入的 TCP A 端口连接到另一个 TCP 端口 B 的服务，以便消费者可以建立到 B 的出站连接。
这不是一个独特的问题[1] [2]使用 socat 我可以做出一些非常接近我想要的东西：
socat -d -d -d -u TCP4-LISTEN:PORT-A,reuseaddr TCP4-LISTEN:PORT-B,reuseaddr
然而，这存在以下问题：
- 如果 B 断开连接，则无法重新连接。使用
TCP4-LISTEN:PORT-B,reuseaddr,fork，它可以连接但不会接收数据。 - 在 A 建立连接之前 B 无法连接（可克服）
- 只能建立一个连接
PORT-B（可克服）
有没有办法调整命令，使其变得“永久”并且能够抵抗失败？
答案1
重要的问题是，A 将如何应对连接丢失或连接被拒绝的情况？任何假设单个 TCP 连接将永远保持连接的做法都是脆弱的；这就是互联网的本质。
如何将其设置socat为[x]inetd服务？
您将设置在 PORT-B 中监听，并在 B 侧连接时立即xinetd启动。socat -u TCP4-LISTEN:PORT-A,reuseaddr STDIO
xinetd将会把来自 B 端的传入流量传递到 的标准输入socat，并捕获 的标准输出socat并将其传递给 B 端。
如果 B 断开连接，则socat可以允许该进程结束；xinetd一旦 B 再次连接，将立即启动一个新进程。当 B 断开连接时，A 将收到“连接被拒绝”错误。
我曾经在旧的 HP-UX 系统上做过类似的事情。
答案2
现实世界是混乱的。
在现实世界中，有时 TCP 连接会中断，例如，如果状态防火墙或 NAT 重新启动，如果连接长时间没有流量，如果底层连接中断时间过长，就会发生这种情况。
此外，有时连接中断时，它们并不是对称中断的。如果承载大量数据的连接中断，那么发送方很可能会比接收方更早注意到该连接中断。这会带来一些副作用。
- 如果连接是由发送方向接收方发起的，那么当旧连接显然仍处于活动状态时，可能会出现新的连接。
- 如果连接是从接收者发起到发送者的，那么在发送者检测到连接中断和接收者检测到该事实并触发重新连接之间可能会有相当大的延迟。
此外，TCP 连接是字节流，而不是消息流，因此当您的连接中断时，您可能会收到部分消息。
最终结果使我得出结论：一个强大的解决方案需要了解应用程序协议，以便您的解决方案能够理解。
- 当有新连接接入时如何拼接流。
- 当数据源被数据接收者连接时，是否应该存储消息则不是。
- 端到端确认机制是否适合防止消息丢失。
- 是否需要某种应用程序级“ping”机制来加快对死连接的检测。