java.net.SocketException: Connection reset

我在尝试从套接字读取时收到以下错误。我正在做一个,我得到这个错误。仔细阅读文档,这表明连接的客户端部分关闭了连接。在这种情况下,我是服务器。readInt()InputStream

我有权访问客户端日志文件,但它没有关闭连接,实际上它的日志文件表明我正在关闭连接。那么有没有人知道为什么会发生这种情况呢?还需要检查什么?当有本地资源可能达到阈值时,是否会出现这种情况?


我确实注意到我有以下行:

socket.setSoTimeout(10000);

就在 .这是有原因的(长篇大论),但只是好奇,在这种情况下,这是否可能导致指示的错误?我在IDE中运行服务器,我碰巧将IDE卡在断点上,然后我注意到完全相同的错误开始出现在IDE的我自己的日志中。readInt()

无论如何,只是提到它,希望不是红鲱鱼。:-(


答案 1

有几种可能的原因。

  1. 另一端故意重置了连接,我不会在这里记录。应用软件这样做是罕见的,通常是不正确的,但对于商业软件来说,这并不是未知的。

  2. 更常见的是,这是由于写入另一端已正常关闭的连接引起的。换句话说,应用程序协议错误。

  3. 它也可能是由在套接字接收缓冲区中存在未读数据时关闭套接字引起的。

  4. 在Windows中,“软件导致连接中止”与“连接重置”不同,是由从您的终端发送的网络问题引起的。有一篇关于此内容的 Microsoft 知识库文章。


答案 2

连接重置仅表示已收到 TCP RST。当您的对等体收到无法处理的数据时,就会发生这种情况,并且可能有多种原因。

最简单的方法是关闭套接字,然后在输出流上写入更多数据。通过关闭套接字,您告诉对等方您已完成通话,它可能会忘记您的连接。当您在该流上发送更多数据时,对等方会使用 RST 拒绝它,以告知它没有侦听。

在其他情况下,干预防火墙甚至远程主机本身可能会“忘记”您的TCP连接。如果长时间不发送任何数据(2 小时是常见的超时),或者因为对等体已重新启动并丢失了有关活动连接的信息,则可能会发生这种情况。在其中一个已失效的连接上发送数据也会导致 RST。


根据其他信息进行更新:

仔细看看您对 .如果在套接字操作上被阻止时超过配置的超时,则会引发此异常。引发此异常时,套接字本身的状态不会更改,但如果异常处理程序关闭套接字,然后尝试写入该套接字,则将处于连接重置状态。 旨在为您提供一种干净的方式来中断可能永远阻塞的操作,而无需执行诸如从另一个线程关闭套接字之类的脏事情。SocketTimeoutExceptionsetSoTimeout()read()


推荐