【问题标题】:TCP connection between client and server gone wrong客户端和服务器之间的 TCP 连接出错
【发布时间】:2015-04-07 18:34:43
【问题描述】:

我在我的服务器和运行在同一主机上的客户端之间建立了一个 TCP 连接。在我们的案例中,我们不断地从服务器收集和读取或说出源。 我们在 3 个不同的端口上读取数据。

一旦源停止发布数据或重新启动,服务器/源无法在同一端口上再次发布数据,说明端口已绑定。给出的原因是客户端仍然在这些端口上建立了连接。

我想知道这可能是什么原因?由于客户端已经在侦听这些端口并尝试一次又一次地重新连接,因此是否会出现问题,因为我们尝试了这种重新连接机制。当源和客户端位于不同的主机上并且不同的主机对我们来说工作得很好时,我更多地在源端寻找原因,因为客户端中的相同代码。

编辑:- 我在阅读各种文章时发现了这一点。

关于使用 SO_LINGER 在关闭时发送 RST 以避免 TIME_WAIT 状态的问题:我在处理背靠背问题的路由器访问服务器(保留名称以保护有罪者)方面遇到了一些问题专用于特定频道的调制解调器上的连接。他们所做的是放开连接,接受另一个调用,尝试连接到主机上的知名套接字,但主机拒绝连接,因为存在涉及知名套接字的处于 TIME_WAIT 状态的连接。 (Stevens 的书TCP Illustrated, Vol 1 更详细地讨论了这个问题。)为了避免连接拒绝问题,我不得不安装一个选项来执行 reset-on-close服务器发起断开连接时的服务器。

来源链接:-http://developerweb.net/viewtopic.php?id=2941

我想我也面临同样的问题:'尝试连接到主机上的知名套接字,但主机拒绝连接'。可能的修复提及是“当服务器启动断开连接时在服务器中执行重置时关闭的选项”。现在我该怎么做?

【问题讨论】:

  • 不要对非代码文本使用代码格式。
  • 请不要对非代码文本使用代码格式。

标签: sockets unix tcp


【解决方案1】:

在绑定之前在服务器套接字上设置SO_REUSEADDR选项并调用listen().

编辑 摆弄SO_LINGER 选项的建议是毫无价值的,并且对您正在传输的数据是危险的。只需使用SO_RESUSEADDR.

【讨论】:

  • 编辑了我的问题,给出了我面临的确切情况。你的答案仍然适用吗?
【解决方案2】:

在重启/关闭服务器之前,您需要关闭绑定到该端口的套接字!

http://www.gnu.org/software/libc/manual/html_node/Closing-a-Socket.html

另外,还有一个超时时间,我认为是 4 分钟,所以如果你创建了一个 TCP 套接字并关闭它,你可能仍然需要等待 4 分钟直到它关闭。

您可以使用 netstat 查看系统上的所有绑定端口。如果您关闭服务器,或在 fork 连接后关闭服务器,您可能有绑定到某些端口的僵尸进程,这些端口不会关闭并保持活动状态,因此您无法重新绑定到同一端口。显示一些代码。

【讨论】:

  • netstat 显示客户端连接仍然存在,但我不确定它是来自客户端的连接,还是由于服务器在没有关闭套接字的情况下关闭的不正确方式。问题是当客户端进程关闭时,服务器能够再次在这些端口上发布。
  • 如何关闭服务器上的套接字?发生了什么,我相信服务器套接字没有发送 TCP 连接的关闭握手,并且您的客户端仍在使用该套接字,或者,由于您没有在服务器上关闭它(及其卡在僵尸进程中)。确保在 how 而不是 close 中调用 shutdown 值 2 以确保套接字完全关闭(不等待传输)。 gnu.org/software/libc/manual/html_node/Closing-a-Socket.html
  • 您不需要在退出拥有它的进程之前关闭一个套接字。 Linux 会为你做这件事,包括亲密的握手。添加关闭不会改变行为。您的链接没有另外说明。
  • -在退出拥有它的进程之前,您不需要关闭套接字。如果你分叉,你会这样做。
猜你喜欢
  • 2015-01-19
  • 2016-04-10
  • 2021-08-12
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-02-16
  • 1970-01-01
  • 2016-09-03
相关资源
最近更新 更多