Indy OnExecute 先读慢答案

【问题标题】：Indy OnExecute first Read slowIndy OnExecute 先读慢
【发布时间】：2011-02-16 01:57:14
【问题描述】：

我在 C++ Builder XE 中的 OnExecute 中有以下代码：

void __fastcall Test::TestExecute( TIdContext* AContext )
{
   try
   {
      // get the command directive
      DWORD startTime = timeGetTime( );
      UnicodeString DBCommand = AContext->Connection->IOHandler->ReadChar();
      DWORD endTime = timeGetTime();
      UnicodeString log;
      log.printf( L"getting command %d ms", endTime - startTime );
      Log( log );
      ...

日志从获取命令 100 毫秒开始，然后爬到 300 毫秒，等待应用程序的其余部分运行。我认为一旦数据进入缓冲区就会调用OnExecute，那么为什么第一次读取成功需要 100 到 300 毫秒？

在第一次读取同一OnExecute 之后，所有其他数据都被非常快速地读取（毫秒到亚毫秒）。

可能出了什么问题？

编辑：

在方法启动时：AContext->Connection->IOHandler->InputBuffer->Size 为 0。第一次读取返回后，AContext->Connection->IOHandler->InputBuffer->Size 包含读取后缓冲区中剩余的内容。所以这意味着OnExecute 在调用者实际可用任何数据之前被调用。所以 100-300 毫秒是 Indy 从套接字获取数据并在收到数据到达通知后将其放入缓冲区所花费的时间。这似乎太长了。

编辑：

删除了do{，因为它暗示了一个不存在的循环。

【问题讨论】：

标签： delphi c++builder indy indy10

【解决方案1】：

OnExecute 事件根本没有绑定到套接字缓冲区。 TIdTCPServer 在调用OnConnect 事件后立即开始调用OnExecute，并在无限循环中继续调用OnExecute，直到客户端断开连接（换句话说，您不应该在OnExecute 处理程序中循环自己. 读取数据包，处理，退出，等待下一个事件，重复）。

您是正确的，InputBuffer 可以比您在代码中要求的更大。所有IOHandler 的读取方法仅从InputBuffer 获取数据，而不是直接从套接字获取数据。如果InputBuffer 没有足够的缓存字节来满足读取请求，则IOHandler 将等待套接字上可用的字节，然后将所有字节读入InputBuffer 以供以后使用。这将需要访问套接字的频率降到最低，并有助于保持套接字对新数据的响应。

【讨论】：

抱歉，do{ 暗示了一个不存在的循环。我不循环进入OnExecute，我使用do{}while(false); 提前退出。 OnExecute is called when data arrives, is that correct? But it still takes 100 to 300 ms to get the first data after OnExecute 被调用。我不记得这发生在 C++ Builder 2010 中。
不，OnExecute 在数据到达时不会被调用。正如我所说，它在OnConnect 退出后立即调用，并且在连接的生命周期内无限循环调用，而不管任何数据。 OnExecute 处理程序负责根据需要管理数据操作。当OnExecute 被调用时，TIdTCPServer 期望处理程序在需要时阻塞调用线程，在需要时让步，但TIdTCPServer 本身除此之外什么也不做。至于 2010 年和 XE 之间的任何差异，Indy 在这方面没有任何变化。它一直都是这样工作的。
对，我误解了你的第一篇文章。 “不考虑任何数据”为我解决了问题。