正确关闭tcp连接抛出java

我正在使用，但有一个严重的问题- 当SMSC向ESME发送[FIN，ACK]时，ESME的回答不正确

这里是TCP转储：

2751.016216 ESME -> SMSC         SMPP SMPP Submit_sm 
2751.019818         SMSC -> ESME SMPP SMPP Submit_sm - resp: "Throttling error (ESME exceeded allowed message limits)" 
2751.136172 ESME -> SMSC         TCP 42265 > 5001 [ACK] Seq=1651885221 Ack=3959508692 Win=123 Len=0 
2774.588453         SMSC -> ESME TCP 5001 > 42265 [FIN, ACK] Seq=3959508692 Ack=1651885221 Win=32768 Len=0 
2774.741502 ESME -> SMSC         TCP 42265 > 5001 [ACK] Seq=1651885221 Ack=3959508693 Win=123 Len=0 
2821.032427 ESME -> SMSC         SMPP SMPP Submit_sm 
2821.033502         SMSC -> ESME TCP 5001 > 42265 [RST] Seq=3959508693 Ack=0 Win=32768 Len=22 

如何解决这个问题？可以处理此数据包吗？

在类TCPIPConnection，方法-public ByteBuffer receive中，您应该执行以下操作：

                    bytesRead = inputStream.read(receiveBuffer, 0, bytesToRead);
                    if (bytesRead == -1){
                        //close connection here
                    }

---

使用像Logica lib这样的框架/库的全部目的应该是将您与低级API/TCP FIN级别的详细信息隔离开来，否则使用该框架没有任何附加值。我们已经走过了这条路，除非你有才华的TCP程序员，否则在TCP级别工作的这条路不会有成效

---

我见过Twitter开发的开源SMPP lib Cloudhopper，几年来在一个非常大的平台上使用开源SMPP lib Cloudhopper。它是强大的，并在许多领先的电信公司得到了生产验证。它有一些示例客户端，您可以使用它们进行自定义。连接管理：在每个会话第一次有SMPP连接时缓存连接。在执行submitSM PDUsend SMS时，检查异常的类型，它是连接异常，只需重新绑定并重新插入SMPP会话/连接即可。如果您的活动时间很长，比如超过40秒，则其一端的SMPP服务器/SMSC可能会断开连接。要重新连接，您有两个选项：a下次执行submitSM PDU时检测陈旧的连接，重新连接，更新缓存，然后发送submitSM PDU或b这是首选选项。有一个单独的线程定期执行InquireLink pDU，比如说每45秒，这将确保连接保持活动状态。假设InquireLink和submitSM pDU使用相同的缓存SMPP会话/连接。当然，如果InquireLink PDU检测到断开的连接，它应该重新绑定并更新公共SMPP会话/连接。多年来，我看到这种方法在多个应用程序中都能很好地工作。

opensmpp有一些严重的问题，我不记得我们测试时这种特殊的行为是否是其中之一，但还有其他的showtupper，比如对文本编码的正确处理。我们最终从头开始重新实现smpp协议