需要可靠/持续出站套接字，选项？

Question

我有一个Scala应用程序，它一次维护（或尝试）到各种服务器的TCP连接数小时（可能> 24）。每个服务器都会发送一个短约30个字符的消息，每秒约两次。这些消息被馈送到迭代器中，在这些迭代器中它们被解析并最终最终对数据库进行状态更改。

如果任何这些连接因任何原因失败，我的应用程序需要不断尝试重新连接，直到我指定了其他方式。任何丢失的信息都是坏的。我无法控制连接的服务器或使用的协议。

可以想象一次会有多达300个这样的连接。没有一个高负载的情况，所以我不认为需要NIO，虽然它可能很好吗？该应用的其他位是高负载。

我正在寻找某种可以保持这些连接尽可能可靠的套接字控制器/管理器。我现在正在运行我自己的阻塞控制器，但由于我对套接字编码（以及所有各种设置，选项，超时等等）没有经验，我怀疑它会实现最佳的正常运行时间。另外我可能需要SSL支持。

NIO会提供任何真正的优势吗？

Netty会是最好的选择吗？我已经看到了正常运行时间示例here，并且正在考虑简单地复制它，但对于较低级别的网络来说是新的，我不确定是否有更好的选择。

Answer 1

然而，我不确定最好的策略，以确保尽可能少的数据包丢失，并假定这是一个“解决”的问题，在一个图书馆或另一个。

是。 JMS就是一个例子。

我想它会涉及到一个超时猜测策略？太早关闭并重新打开一个套接字，并且丢失了任何数据包。

这是正确的。这种方法不可靠，特别是如果连接经常发生变化。

真正的解决方案包括让另一端跟踪接收到的内容，并让发送者知道何时重新建立连接。如果做不到这一点，你就没有办法控制丢失的东西。 （这是可靠的消息服务做...）

我有超过我连接到服务器的控制。因此，除非有另一种方法来使JMS适应通用的TCP流，否则我认为它不会起作用。

是。如果你尝试手工实现这一点，情况也是如此。另一端必须合作。

我想你可以在每个远程服务器上运行（比如说）一个JMS端点，并让端点使用UNIX域套接字或环回（即127.0.0.1）与服务器交谈。但是你仍然有可能丢失信息。