您的位置: 首页  >  技术问答  >  在套接字上实现时间限制等待（TCP）

在套接字上实现时间限制等待（TCP）

分类: 技术问答 • 2022-06-03 09:06:53
问题描述：

问题：


我向应用程序发送了很多请求（当然是在不同的

框上运行），我收到回复的回复从应用程序。

下面：套接字对应于套接字套接字=新

套接字（AddressFamily.InterNetwork，SocketType.Stream，

ProtocolType.Tcp ）;


在我的Wait方法中我有以下

public void Wait（uint milliseconds）

{

while（/ *保持空闲，传递的数量为毫秒* /）{

if（socket.Poll（1，SelectMode.SelectRead））

{

ProcessSocket（套接字）; //读取缓冲区的信息

并为客户调用已注册的回调

}

else

返回; //在Poll过期后返回

}

}

}


因此当客户端时呼叫等待，他得到所有的回调，然后

等待几毫秒，然后再假设没有别的东西是来自电线的
。我无法实现最后一点。

Problem:

I send a lot of requests to the application (running on a different
box, of course), and I receive back responses from the app .
Below: socket corresponds to Socket socket=new
Socket(AddressFamily.InterNetwork, SocketType.Stream,
ProtocolType.Tcp);

in my Wait method I have the following
public void Wait (uint milliseconds)
{
while(/*Remain idle for passed number of "milliseconds"*/){
if (socket.Poll(1, SelectMode.SelectRead))
{
ProcessSocket(socket);// read info of the buffer
and calls registered callbacks for the client
}
else
return; //returns after Poll has expired
}
}
}

Hence when a client calls Wait, he get all the callbacks, and then
Wait blocks for milliseconds before assuming that nothing else is
coming from the wire. I have trouble implementing the last point.

答

2008年10月20日星期一12:10:51 -0700，puzzlecracker< ir*********@gmail.com>

写道：
On Mon, 20 Oct 2008 12:10:51 -0700, puzzlecracker <ir*********@gmail.com>
wrote:

[...]

因此，当一个客户端调用Wait时，他得到所有的回调，然后

等待块几毫秒，然后再假设没有其他东西是来自电线的
。我无法实现最后一点。
[...]
Hence when a client calls Wait, he get all the callbacks, and then
Wait blocks for milliseconds before assuming that nothing else is
coming from the wire. I have trouble implementing the last point.



不要调用Socket.Poll（）。永远。这不是实施

事情的正确方法。问题包括你不必要地使用CPU和

Poll（）方法是不可靠的（Socket可能变得不合理，因为Poll（）说它的时间是
这是可读的，你实际上是时候试图读取它的时间。


纠正问题的方法涉及保持一个单独的计时器（用于

示例，使用System.Threading.Timer类）执行一些

的相应操作。如果您正在寻找自上次读取任何

数据后等待，则每次实际成功读取数据时都需要重置计时器。一个适当的动作可能是关闭

套接字，但如果不知道你的具体目标，肯定不能说

。
>
此外，假设假设没有其他东西来自

电线是一种有效的方法。如果你无法控制应用程序

协议，也许这是正确的。但总的来说，处理网络i / o是一种糟糕的方式

。通讯应该有明确的结束，

所以根本不需要超时。


Pete

Don''t call Socket.Poll(). Ever. It''s just not the right way to implement
things. Problems include that you are unnecessarily using the CPU and the
Poll() method isn''t reliable (the Socket may become unreasonable between
the time Poll() says it''s readable and the time you get around to actually
trying to read it).

Correct approaches to the problem involve keeping a separate timer (for
example, using the System.Threading.Timer class) that performs some
appropriate action. If you are looking for a "wait since last read any
data", then you need to reset the timer each time you actually
successfully read data. An appropriate action might be to close the
socket, but without knowing your specific goals, it''s impossible to say
for sure.

Also, that assumes that "assuming that nothing else is coming from the
wire" is a valid approach. If you have no control over the application
protocol, maybe that''s correct. But generally speaking, it''s a poor way
to deal with network i/o. Communications should have a well-defined end,
so that timeouts aren''t required at all.

Pete



不要调用Socket.Poll（）。 *如初。 *这不是实施*

事情的正确方法。 *问题包括您不必要地使用CPU和*

Poll（）方法是不可靠的（Socket可能在*

之间变得不合理Poll（ ）说它是可读的，你实际上是时间*

试图阅读它的时间。
Don''t call Socket.Poll(). *Ever. *It''s just not the right way to implement *
things. *Problems include that you are unnecessarily using the CPU and the *
Poll() method isn''t reliable (the Socket may become unreasonable between *
the time Poll() says it''s readable and the time you get around to actually *
trying to read it).



好​​吧，我继承了以前开发人员使用民意调查的项目，

等等。客户端的持续设计不是最好的状态，而是我试图解决它

Well, I inherited the project from the previous developer used poll,
among other things. The ongoing design on the client side is not in
the best state, and I am trying to sort it out


正确的方法问题涉及保持一个单独的计时器（对于*

示例，使用System.Threading.Timer类）执行一些*

相应的操作。 *如果您正在寻找自上次读取任何*

数据后等待，那么每次实际上*

成功读取数据时，您需要重置计时器。 *一个适当的动作可能是关闭*

套接字，但如果不知道你的具体目标，肯定不能说*

。
Correct approaches to the problem involve keeping a separate timer (for *
example, using the System.Threading.Timer class) that performs some *
appropriate action. *If you are looking for a "wait since last read any*
data", then you need to reset the timer each time you actually *
successfully read data. *An appropriate action might be to close the *
socket, but without knowing your specific goals, it''s impossible to say *
for sure.



协议的简单版本：您通过

套接字向远程应用程序发送请求，并且立即 '在一个字节缓冲区中响应

a响应（

应用程序端没有故意延迟）。缓冲区包含各种标题，子标题，

和消息。解析之后，我通过

订阅的事件向客户转发回复。因此客户端发送了许多请求，然后等待

响应。我希望客户能够在发送额外的

请求或关闭连接之前指定为[post]响应分配多少时间。

The simplistic version of the protocol: you send a request, via
socket, to the remote application, and it ''immediately'' response with
a response in a byte buffer (there are no intentional delays on the
application side). The buffer contains various headers, sub-headers,
and the message. After parsing it, I forward a response to clients via
subscribed events. So client sends many requests, then waits for
responses. I want client to be able to specify how much time to
allocate for the [post] responses before sending additional set of
requests or close the connection.


此外，假设假设没有其他东西来自*

线是一种有效的方法。 *如果您无法控制应用程序*

协议，也许这是正确的。 *但总的来说，处理网络i / o是一种糟糕的方式*

。 *通信应有明确的结束，*

，因此根本不需要超时。
Also, that assumes that "assuming that nothing else is coming from the *
wire" is a valid approach. *If you have no control over the application*
protocol, maybe that''s correct. *But generally speaking, it''s a poor way *
to deal with network i/o. *Communications should have a well-defined end, *
so that timeouts aren''t required at all.



你可以推荐设计这种

申请的任何好的参考资料吗？


谢谢...

Any good references you may recommend to design this sort of
applications?

Thanks...


2008年10月20日星期一13:43:46 -0700，puzzlecracker< ir ********* @ gmail.com>

写道：
On Mon, 20 Oct 2008 13:43:46 -0700, puzzlecracker <ir*********@gmail.com>
wrote:

>不要调用Socket.Poll（） 。 ？*如初。 [...]
>Don''t call Socket.Poll(). ?*Ever. [...]



好​​吧，我继承了之前开发人员使用民意调查的项目，

等等。客户端正在进行的设计不是最好的状态，我试图将它排序为


Well, I inherited the project from the previous developer used poll,
among other things. The ongoing design on the client side is not in
the best state, and I am trying to sort it out



无论你是否编写它或者你继承了它，调用Poll（）仍然很糟糕。

你不需要为我辩护代码;我只是分享我所知道的关于网络编程的知识

。

Whether you wrote it or you inherited it, calling Poll() is still bad.
You don''t need to defend the code to me; I''m just sharing what I know
about network programming.


协议的简单版本：你发送请求，通过

套接字，远程应用程序，并且它立即响应

a响应在字节缓冲区中（
$没有故意延迟） b $ b申请方）。缓冲区包含各种标题，子标题，

和消息。解析之后，我通过

订阅的事件向客户转发回复。因此客户端发送了许多请求，然后等待

响应。我希望客户能够在发送额外的

请求或关闭连接之前指定为[post]响应分配多少时间。
The simplistic version of the protocol: you send a request, via
socket, to the remote application, and it ''immediately'' response with
a response in a byte buffer (there are no intentional delays on the
application side). The buffer contains various headers, sub-headers,
and the message. After parsing it, I forward a response to clients via
subscribed events. So client sends many requests, then waits for
responses. I want client to be able to specify how much time to
allocate for the [post] responses before sending additional set of
requests or close the connection.



我对这种设计持怀疑态度。使用它需要您自担风险。

I am skeptical of that design. Use it at your own risk.


您可能建议设计此类

应用程序的任何好参考？
Any good references you may recommend to design this sort of
applications?



Winsock FAQ实际上是一个很好的起点，即使它不是特定于.NET的

。无论您使用什么API，大多数网络编程问题都是相同的

。另一个必读的是Windows

Sockets Lame List。 （对不起，如果你熟悉那么标题会更有趣

与旧的西雅图电视节目Almost Live）。


常见问题： http://tangentsoft.net/wskfaq/

Lame List： http://tangentsoft.net/wskfaq/articles /lame-list.html


在Lame列表中，请参阅有关使用

MSG_PEEK调用recv（）的特定注释以及使用与FNIOREAD的ioctlsocket（）。调用民意调查（）是基本相同的事情，同样的问题（请注意，Lame List

并没有描述_all_问题，这正是作者所感受到的是

最严重的一个。）


Pete

The Winsock FAQ is actually a good place to start, even though it''s not at
all specific to .NET. Most of the network programming issues are the same
regardless of what API you''re using. The other must-read is the "Windows
Sockets Lame List" (sorry, the title is much funnier if you''re familiar
with the old Seattle-based TV show "Almost Live").

The FAQ: http://tangentsoft.net/wskfaq/
The Lame List: http://tangentsoft.net/wskfaq/articles/lame-list.html

In the Lame List, see in particular comments regarding calling recv() with
MSG_PEEK and the use of ioctlsocket() with FNIOREAD. Calling Poll() is
basically the same thing, with the same problems (note that the Lame List
doesn''t describe _all_ the problems, just what the author felt was the
most serious one(s)).

Pete


相关推荐