我有一个Scala应用程序，它一次维护（或尝试）到各种服务器的TCP连接数小时（可能> 24）。每个服务器发送一个约30个字符的短消息，大约每秒两次。这些消息被送入迭代器，在那里它们被解析并最终最终对数据库进行状态更改。
如果这些连接中的任何一个因任何原因而失败，我的应用程序需要不断尝试重新连接，直到我另行指定。丢失的任何消息都是Bad。我无法控制我连接的服务器或使用的协议。
可以想象，一次会有多达300个这样的连接。不是一个高负荷的情况，所以我不认为需要NIO，虽然它可能很好吗？该应用程序的其他位是高负载。
我正在寻找某种插座控制器/管理器，它可以尽可能可靠地保持这些连接。我现在正在运行自己的阻塞控制器，但由于我对套接字编码（以及所有各种设置，选项，超时等）缺乏经验，我怀疑它将实现最佳的正常运行时间。此外，我可能需要在某些时候支持SSL。
NIO会提供任何真正的优势吗？
Netty会是最好的选择吗？我已经看过Uptime示例here，并且只是想复制它，但是对于较低级别的网络来说，我不确定是否有更好的选择。
答案 0 :(得分：1)
然而，我不确定确保尽可能少丢失数据包的最佳策略，并假设这将是一个库或另一个库中的“已解决”问题。
烨。 JMS就是一个例子。
我想很多都会归结为超时猜测策略？过早关闭并重新打开一个套接字，你丢失了所有正在路由的数据包。
这是正确的。这种方法并不可靠，特别是如果连接定期上下。
真正的解决方案是让另一端跟踪它收到的内容，并让发送方知道何时重新建立连接。如果无法做到这一点，你就没有真正的方法来控制失去多少。 （这就是可靠的消息传递服务所做的......）
我无法控制我连接的服务器。因此，除非有另一种方法使JMS适应通用TCP流，否则我认为它不会起作用。
烨。如果您尝试手动实现，则同样适用。另一端必须合作。
我猜你可以在每个远程服务器上运行（比如说）JMS端点，并让端点使用UNIX域套接字或环回（即127.0.0.1）与服务器通信。但是你仍然有可能丢失信息。