在 TCP/IP 套接字中，服务器如何知道客户端正忙且未接收数据？
在 TCP/IP 套接字中，服务器如何知道客户端正忙且未接收数据？
我的解决方案：
使用 connect()，
我不确定。
谢谢
In TCP/IP sockets, how would the server know that a client is busy and not receiving data ?
My solution:
Use connect(),
I am not sure.
thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果 TCP 不断推送对方未确认的数据，最终发送窗口将被填满。此时 TCP 将缓冲数据以“稍后发送”。最终将达到缓冲区大小，
send(2)将挂起（通常不会这样做）。如果
send(2)开始挂起，则意味着对等 TCP 未确认数据。显然，即使对等 TCP 接受数据，也不意味着对等应用程序实际使用它。您可以在
TCP之上实现自己的ACK机制，这并不像听起来那么不合理。这需要让客户偶尔发送一条“给我发送更多”消息。If a TCP is constantly pushing data that the peer doesn't acknowledge, eventually the send window will fill up. At that point the TCP is going to buffer data to "send later". Eventually the buffer size will be reached and
send(2)will hang (something it doesn't usually do).If
send(2)starts hanging it means the peer TCP isn't acknowledging data.Obviously, even if the peer TCP accepts data it doesn't mean the peer application actually uses it. You could implement your own
ACKmechanism on top ofTCP, and it's not as unreasonable as it sounds. It would involve having the client send a "send me more" message once in a while.客户端几乎总是会收到您的数据，我的意思是操作系统将接受数据包并将它们排队等待读取。如果该队列已满，则发送方将阻塞（无论如何，TCP）。您实际上无法了解客户端代码的活动。几乎你唯一的选择就是使用超时。
A client will almost always receive your data, by which I mean the OS will accept the packets and queue them up for reading. If that queue fills up, then the sender will block (TCP, anyways). You can't actually know the activity of the client code. Pretty much your only option is to use timeouts.