中断后重新连接TCPClient

发布于 2024-11-05 18:46:05 字数 502 浏览 0 评论 0原文

我有一个客户端应用程序的多个实例,通过 TcpClient 通过互联网连接到主应用程序。 (都是我编码的)。因此,连接的方式如下:

TcpClient.Connect(ip, port)

我现在希望它能够处理各种类型的断开连接事件:

  1. 主应用程序(服务器)或客户端应用程序计算机失去互联网连接。

    • 恢复连接时,通信似乎丢失,但当我尝试重新连接时,我收到消息: “在已连接的套接字上发出连接请求”
    • 所以我需要关闭并重新启动客户端应用程序。
  2. 主应用程序(服务器)关闭并重新启动。

    • 重新启动主应用程序,然后尝试重新连接客户端应用程序,会导致与上述相同的错误。

那么,我需要做什么?每当发生此类中断时,我是否需要在客户端应用程序中实例化新的 TcpClient?我没有尝试过,所以不知道这是否是一个糟糕的解决方案?

I have multiple instances of a client application, connecting to a main application over internet by TcpClient. (Both coded by me). So the connection is made like:

TcpClient.Connect(ip, port)

I now want this to handle various type of disconnect events:

  1. Main App (server) or a client app computer lose internet connection.

    • On resume of connection, the communication seems lost, but when I try to reconnect, I get message:
      "A connection request was made on an already connected socket"
    • So I need to close and restart the client app.
  2. Main App (server) is closed, and restarted.

    • Restarting the Main App, and then trying to reconnect the client app, results in same error as above.

So, what do I need to do? Do I need to instantiate a New TcpClient in the Client Apps, whenever such interruption occur? I haven't tried that, so don't know if that's a poor solution?

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

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

发布评论

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

评论(2

黒涩兲箜 2024-11-12 18:46:05

每当发生此类中断时,我是否需要在客户端应用程序中实例化新的 TcpClient?

是的。如果 TcpClient 表示的连接断开,则无法使用该对象进行进一步通信,也无法再次连接它。创建一个新的 TcpClient 对象。

你的问题很可能是NAT网关超时了你的TCP连接,所以你的服务器<->客户端之间没有任何东西可以通过,如果你的客户端所做的一切都是从连接中读取,它不会发现这种情况,并且它认为连接仍然打开。

do I need to instantiate a New TcpClient in the Client Apps, whenever such interruption occur?

Yes. If the connection represented by the TcpClient is broken, you can't use that object for further communicating, nor can you connect it again. Create a new TcpClient object.

Your problem is likely that a NAT gateway times out your TCP connection, so nothing can get through between your server<->client, if all your client does is read from the connection, it will not discover this case, and it thinks the connection is still open.

暖伴 2024-11-12 18:46:05

我过去通常通过使用线程来解决这个问题。我创建了一个控制线程,它循环执行并执行管理操作,例如检查连接、检查最新的用户输入、检查服务器关闭请求等。完成后,它会休眠半秒钟,然后重新执行一遍。

然后,我创建了一个单独的 Socket 线程,并简单地维护了一个网络套接字。一旦启动,它就会打开连接,并反复循环查找来自连接者的传入消息。如果它发现一条消息,它将对其进行处理并将其存储在易失性对象集合中,以供控制线程使用。如果连接发生问题,它会自动尝试解决,如果无法解决,它将进入“死亡”状态。控制线程在下一次迭代时将清理死套接字线程并根据需要创建新线程。

调试是一场噩梦,但一旦解决了错误,它就出奇地稳定。在一个实例中,它成功运行了一年多,有数万个连接和数百个并发连接,无需重新启动或任何维护。

I have typically solved this problem before in the past by using threads. I created a control thread that loops through and does administrative things like, check the connection, check the latest user input, check a server shutdown request, etc. When it is done it slept for half a second and did it all over again.

I then had a seperate Socket thread that was created and simply maintained a network socket. It would open the connection once started and loop repeatedly looking for incoming messages from whoever it was connected to. If it found a message it would process it and store it in a volatile object collection for consumption by the control thread. If something happened to the connection it would automatically try to resolve and if it couldn't it would go into a 'dead' state. The control thread at its next iteration would clean up the dead socket threads and create new ones as necessary.

Debugging was a nightmare but it was surprisingly stable once the bugs were worked out. On one instance it ran successfully for over a year with tens of thousands of connections and hundreds of concurrent connections with no need for restarts or any maintenance whatsoever.

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