Java TCP/IP 服务器不正确地关闭连接

发布于 2024-10-06 02:33:32 字数 1246 浏览 0 评论 0原文

我为 Android 手机创建了一个 MMO,并使用带有 TCP/IP 套接字的 Java 服务器。一般来说,一切都工作正常,但在客户端登录和注销大约一天之后,我的网络变得非常滞后——即使没有客户端连接。 NETSTAT 显示没有延迟连接,但显然出现了严重错误。

如果我完全重新启动,一切都会神奇地再次正常,但这不是长期可行的解决方案。这就是我的断开连接方法的样子(在两端):

    public final void disconnect()
{
    Alive = false;
    Log.write("Disconnecting " + _socket.getRemoteSocketAddress());
    try
    {
        _socket.shutdownInput();
    }
    catch (final Exception e)
    {
        Log.write(e);
    }
    try
    {
        _socket.shutdownOutput();
    }
    catch (final Exception e)
    {
        Log.write(e);
    }
    try
    {
        _input.close();
    }
    catch (final Exception e)
    {
        Log.write(e);
    }
    try
    {
        _output.close();
    }
    catch (final Exception e)
    {
        Log.write(e);
    }
    try
    {
        _socket.close();
    }
    catch (final Exception e)
    {
        Log.write(e);
    }
}

_input 和 _output 是从套接字生成的 BufferedInputStream 和 BufferedOutputStream。根据文档,调用 shutdownInput() 和 shutdownOutput() 不是必要的,但我会尽我所能。

我使用默认设置实例化套接字——我没有接触 soLinger、KeepAlive、noDelay 或类似的东西。我没有为发送/接收设置任何超时。我尝试过使用 WireShark,但它没有显示任何异常,就像 NETSTAT 一样。

我非常渴望得到这个问题的答案。我在这个项目上投入了大量的精力,但对 Java 默认 TCP 实现中看似严重的隐藏缺陷感到沮丧。

I've created an MMO for the Android phone and use a Java server with TCP/IP sockets. Everything generally works fine, but after about a day of clients logging on and off my network becomes extremely laggy -- even if there aren't clients connected. NETSTAT shows no lingering connections, but there is obviously something terribly wrong going on.

If I do a full reboot everything magically is fine again, but this isn't a tenable solution for the long-term. This is what my disconnect method looks like (on both ends):

    public final void disconnect()
{
    Alive = false;
    Log.write("Disconnecting " + _socket.getRemoteSocketAddress());
    try
    {
        _socket.shutdownInput();
    }
    catch (final Exception e)
    {
        Log.write(e);
    }
    try
    {
        _socket.shutdownOutput();
    }
    catch (final Exception e)
    {
        Log.write(e);
    }
    try
    {
        _input.close();
    }
    catch (final Exception e)
    {
        Log.write(e);
    }
    try
    {
        _output.close();
    }
    catch (final Exception e)
    {
        Log.write(e);
    }
    try
    {
        _socket.close();
    }
    catch (final Exception e)
    {
        Log.write(e);
    }
}

_input and _output are BufferedInputStream and BufferedOutputStream spawned from the socket. According to documentation calling shutdownInput() and shutdownOutput() shouldn't be necessary, but I'm throwing everything I possibly can at this.

I instantiate the sockets with default settings -- I'm not touching soLinger, KeepAlive, noDelay or anything like that. I do not have any timeouts set on send/receive. I've tried using WireShark but it reveals nothing unusual, just like NETSTAT.

I'm pretty desperate for answers on this. I've put a lot of effort into this project and am frustrated with what appears to be a serious hidden flaw in Java's default TCP implementation.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

迷爱 2024-10-13 02:33:32

摆脱 shutdownInput() 和 shutdownOutput() 以及除 BufferedOutputStream 的关闭之外的所有关闭,以及在finally 块中作为 Belt & 的套接字本身的后续关闭。大括号。您将关闭并关闭输出流之前的所有其他内容,这会阻止其刷新。关闭输出流会刷新它并关闭套接字。这就是你所需要的。

Get rid of shutdownInput() and shutdownOutput() and all the closes except the close for the BufferedOutputStream, and a subsequent close on the socket itself in a finally block as a belt & braces. You are shutting down and closing everything else before the output stream, which prevents it from flushing. Closing the output stream flushes it and closes the socket. That's all you need.

如痴如狂 2024-10-13 02:33:32

OP在这里,无法对原始帖子发表评论。

  • 重新启动服务器进程似乎无法解决该问题。即使完全关闭服务器几分钟后,网络仍然非常“滞后”。

  • 我所说的“滞后”是指无论是上行还是下行流量,连接都会变得非常慢。尝试加载网站或上传到我的 FTP 的速度非常慢,就像我使用 14.4k 调制解调器(我使用 15mbs 光纤)一样。处于这种状态时,互联网速度测试甚至无法工作 - 当网站最终加载时,我收到一条关于找不到文件的错误。

  • 所有这些都会在重新启动后立即清除,并且只有在重新启动后才会清除。

  • 我按照 EJP 建议修改了断开连接方法,但问题仍然存在。

  • 服务器在 Windows 7 安装上运行,最新版本的 Java / Java SDK。服务器有 16GB RAM,尽管我可能没有正确分配它以供 JVM 充分使用。似乎不存在任何杂散线程或进程。我看看 JVISUALVM 怎么说。 – jysend 13 分钟前

  • JVISUALVM 中没有任何异常 - 10mb 堆,50% CPU 使用率,3160 个对象(预期),启动了 437 个活动线程中的 27 个。服务器已运行约18小时;加载 CNN 的首页大约需要一分钟,而我使用的正常速度测试(首先点击谷歌搜索速度测试)甚至无法加载该页面。 NETSTAT 显示没有延迟连接。运行所有最新的防病毒软件。服务器过去一直 24/7 运行,没有任何问题 —— 只是当我开始在其上运行这个 Java 服务器时,这种情况才开始发生。

OP here, unable to comment on original post.

  • Restarting the server process does not appear to resolve the issue. The network remains very "laggy" even several minutes after shutting down the server entirely.

  • By "laggy" I mean the connection becomes extremely slow with both up and down traffic. Trying to load websites, or upload to my FTP, is painfully slow like I'm on a 14.4k modem (I'm on a 15mbs fiber). Internet Speed Tests don't even work when it is in this state -- I get an error about not finding the file, when the websites eventually load up.

  • All of this instantly clears up after a reboot, and only after a reboot.

  • I modified my disconnect method as EJP suggested, but the problem persists.

  • Server runs on a Windows 7 installation, latest version of Java / Java SDK. The server has 16gb of RAM, although it's possible I'm not allocating it properly for the JVM to use fully. No stray threads or processes appear to be present. I'll see what JVISUALVM says. – jysend 13 mins ago

  • Nothing unusual in JVISUALVM -- 10mb heap, 50% CPU use, 3160 objects (expected), 27 live threads out of 437 started. Server has been running for about 18 hours; loading up CNN's front page takes about a minute, and the normal speed test I use (first hit googling Speed Test) won't even load the page. NETSTAT shows no lingering connections. Ran all up to date antivirus. Server has run 24/7 in the past without any issues -- it is only when I started running this Java server on it that this started to happen.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文