我有一个 Scala 应用程序，它一次维护（或尝试）与各种服务器的 TCP 连接数小时（可能 > 24）。每台服务器大约每秒发送两次约 30 个字符的短消息。这些消息被送入一个迭代器，在那里它们被解析并最终对数据库进行状态更改。
如果这些连接中的任何一个由于任何原因失败，我的应用程序需要不断尝试重新连接，直到我另行指定。任何丢失的消息都是不好的。我无法控制我连接的服务器或使用的协议。
可以想象一次会有多达 300 个这样的连接。不完全是高负载场景，所以我认为不需要 NIO，尽管拥有它可能会很好？该应用程序的其他部分是高负载的。
我正在寻找某种可以使这些连接尽可能可靠的套接字控制器/管理器。我现在正在运行自己的阻塞控制器，但由于我对套接字编码（以及所有各种设置、选项、超时等）缺乏经验，我怀疑它能否实现最佳的正常运行时间。另外，我可能在某些时候需要 SSL 支持。
NIO 会提供任何真正的优势吗？
Netty 会是这里的最佳选择吗？我在这里看到了 Uptime 示例，并且正在考虑简单地复制它，但是对于较低级别的网络来说，我不确定是否有更好的选择。
However I'm uncertain of the best strategies for ensuring as few packets are lost as possible, and assumed this would be a "solved" problem in one library or another.
Yup. JMS is an example.
I suppose a lot of it would come down to a timeout guessing strategy? Close and re-open a socket too early and you've lost whatever packets were en-route.
That is correct. That approach is not going to be reliable, especially if connections go up and down regularly.
A real solution involves having the other end keep track of what it has received, and letting the sender know when then connection is re-established. If that can't be done, you have no real way of controlling how much gets lost. (This is what the reliable messaging services do ...)
I have no control over the servers I connect to. So unless there's another way to adapt JMS to a generic TCP stream I don't think it will work.
Yup. And the same applies if you try to implement this by hand. The other end has to cooperate.
I guess you could construct something where you run (say) a JMS end point on each of the remote servers, and have the endpoint use UNIX domain sockets or loopback (i.e. 127.0.0.1) to talk to the server. But you still have potential for message loss.