delphi - 为什么当客户端连接到 Indy 中的服务器时 IOHandler.ReadStream 会阻塞线程？

Question

今天我在使用 Indy 10(Delphi 2010 附带)时遇到了奇怪的行为。问题是这样的:

假设我们的客户端中有一个 IdTcpClient，服务器应用程序中有一个 IdTcpServer，并且 IdTcpServer 的 OnExecute 事件处理程序中的代码如下:

procedure TForm1.IdTCPServer1Execute(AContext: TIdContext);
var
  AStream: TStringStream;
  S: string;
begin
  AStream := TStringStream.Create;
  try
    AContext.Connection.IOHandler.ReadStream(AStream);
    S := AStream.DataString;
  finally
    AStream.Free;
  end;
end;

现在，当客户端尝试连接到服务器时，使用 TIdTcpClient.Connect；在服务器上，调用 TIdTcpServer.OnExecute，并且当执行到达 AContext.Connection.IOHandler.ReadStream(AStream) 行时，在 OnExecute 事件处理程序内运行的线程将被阻止!

当我跟踪代码时，问题是在 ReadStream 内部调用 ReadLongInt 来获取字节数时引起的。 ReadLongInt 调用 ReadBytes。在 ReadBytes 内部，FInputBuffer.Size 为零。在那里，循环调用 ReadFromSource，最终执行到 TIdSocketListWindows.FDSelect，它从 WinSock2 调用“select”函数，执行在此停止，并且不会从该客户端连接接收任何内容。我也尝试为 AByteCount 和 AReadUntilDisconnect 参数赋值，但它并没有改变行为。

如果我将ReadStream替换为ReadLn，那么连接到服务器不会阻止代码执行，并且服务器会读取客户端发送的数据。

代码有问题吗？或者这是一个错误？

问候

Answer 1

问题出在您的代码中，而不是在 ReadStream() 中。它按照设计运行。

它接受 3 个参数输入:

procedure ReadStream(AStream: TStream; AByteCount: TIdStreamSize = -1; AReadUntilDisconnect: Boolean = False); virtual;

您只为第一个参数提供值，因此其他两个参数使用默认值。

当 AByteCount参数设置为 -1 且 AReadUntilDisconnect参数设置为 False，ReadStream()旨在假设接收到的前 4 个字节(或 8 个字节，如果 IOHandler.LargeStream 属性设置为 True)是正在发送的数据的长度，后面是实际数据。这就是为什么ReadStream()正在调用ReadLongInt() 。这不仅告诉 ReadStream()何时停止阅读，但它也允许ReadStream()在接收数据之前预先调整目标 TStream 的大小以实现更好的内存管理。

如果客户端实际上并未在其数据之前发送 4 字节(或 8 字节)长度值，则 ReadStream()仍会将实际数据的起始字节解释为长度。这通常(但并非总是如此，具体取决于数据)结果为 ReadLongInt() (或 ReadInt64() )返回一个大整数值，这将导致 ReadStream()预期永远不会真正到达的大量数据，从而无限期地阻止读取(或者直到发生超时，如果 IOHandler.ReadTimeout 属性设置为非无限超时)。

为了使用ReadStream()实际上，它需要知道何时停止读取，要么通过提前告知预计有多少数据(即: AByteCount >= 0 )，要么要求发送者在发送数据后断开连接(即: AReadUtilDisconnect = True )。 AByteCount = -1的组合和AReadUtilDisconnect = False是一种特殊情况，当长度直接在流中编码时。这主要用于(但不限于)当发件人调用 IOHandler.Write(TStream) 时。及其AWriteByteCount参数设置为True(默认为False)。

处理非文本数据时，尽可能在实际数据之前发送数据长度始终是一个好主意。它优化了读取操作。

ReadStream() 的不同参数组合可得出以下逻辑:

1. AByteCount = -1，AReadUtilDisconnect = False:读取 4/8 字节，解释为长度，然后继续读取，直到收到该长度。

2. AByteCount < -1, AReadUtilDisconnect = False:假设 AReadUntilDisconnect 为 True 并继续读取，直到断开连接。

3. AByteCount > -1, AReadUtilDisconnect = False:预先调整目标 TStream 的大小并继续读取，直到收到 AByteCount 字节数。

4. AByteCount <= -1，AReadUtilDisconnect = True:继续读取直到断开连接。

5. AByteCount > -1, AReadUtilDisconnect = True:预先调整目标 TStream 的大小并继续读取，直到断开连接。

根据客户端首先实际发送到服务器的数据类型，可能是 ReadStream()可能不是读取该数据的最佳选择。 IOHandler 有许多不同类型的可用读取方法。例如，如果客户端发送分隔文本(特别是使用 IOHandler.WriteLn() 发送)，则 ReadLn()是一个更好的选择。