android - Delphi & Datasnap - 连接超时、通信超时或避免客户端应用程序在没有服务器响应时挂起的方法

Question

我正在尝试使用基于客户端-服务器 Datasnap 的架构。客户端位于一个 Android 应用程序中，该应用程序通过 Wifi 与在 PC 中运行的服务器程序连接。

这是服务器端和客户端的特性:

服务器端:

服务器方法

TSQL连接

• 司机:Firebird。
• 保持连接:真。

服务器容器

TDS服务器

• 队列大小:100
• channel 响应超时:3000

TDSTCPServerTransport

• 缓冲区KBSize:32
• KeepAliveEnablement: kaDisabled
• 最大线程数:30
• 池大小:10
• 端口:211

客户端

主要

TSQL连接

• 司机:Datasnap
• 连接超时:2000
• 通信超时:5000
• DBXConnection 构造函数:

函数:

function TFrm_Principal.GetServerMethods1Client: TServerMethods1Client;
begin
  Conexion.Close;
  Conexion.Open;
  if FServerMethods1Client = nil then
  begin
    FServerMethods1Client := TServerMethods1Client.Create
      (Conexion.DBXConnection, FInstanceOwner);
  end;
  result := FServerMethods1Client;
end;

客户端类

• 命令示例(当然在服务器端有它的等价物)

函数:

function TServerMethods2Client.validaEstado(factura: string): Boolean;
begin
  try
    if FvalidaEstadoCommand = nil then
    begin
      FvalidaEstadoCommand := FDBXConnection.CreateCommand;
      FvalidaEstadoCommand.CommandType := TDBXCommandTypes.DSServerMethod;
      FvalidaEstadoCommand.Text := 'TServerMethods1.validaEstado';
      FvalidaEstadoCommand.Prepare;
    end;
    FvalidaEstadoCommand.CommandTimeout := 3;
    FvalidaEstadoCommand.Parameters[0].Value.SetWideString(factura);
    FvalidaEstadoCommand.ExecuteUpdate;
    Result := FvalidaEstadoCommand.Parameters[1].Value.GetBoolean;
  except
    on e: Exception do
    begin
      controlarError;
    end;
  end;
end;

一切都运行良好且速度很快，但是当平板电脑与服务器断开 Wifi 连接时，它挂起的时间超过了不同属性中分配的超时时间。有时我等了 30 或 40 秒也没有回应。如果我靠近网络路由器，有时它会恢复流量，但如果我远离它，应用程序最终会崩溃。问题是:如果有超时应该使应用程序响应“无法按时连接到网络”或“超时错误”，而不是只是挂起，而不是等待或重新启动，用户没有任何可能性挂起，为什么它会挂起应用程序？

Answer 1

我还没有用过 Firebird，但是用过 TSQLConnection 和 DataSnap。我假设 Firebird 使用与 TSQLConnection 相同的通信库。如果是这样，那么:

底层调用被移交给 Windows(即 WinSock)，并且我没有找到检查连接是否仍然完好无损的方法。

我编写了一个名为 CheckCon() 的简单 DataSnap 服务器端函数，它除了为客户端应用程序提供一些可在服务器上调用以查看通信 channel 是否仍处于连接状态之外什么都不做。我将对 CheckCon() 的客户端调用放在 try...except block 中，这样我就可以捕获错误并在 EIdSocketError< 时自动重新连接 被提出。

用户获得自动重新连接，这很有帮助，但用户仍然需要等待 30 秒，让 Windows WinSock 在返回套接字错误和自动重新连接代码执行之前超时。

This old thread有 Remy Lebeau 关于类似主题的解释，并且由于 DataSnap 使用 Indy，我认为它也适用于此:

You won't be able to [check if the client is still connected to the server] in a timely manner. Indy uses blocking sockets, and blocking sockets simply are not designed to detect abnormal disconnects quickly. When an abnormal disconnect occurs, the underlying socket library (WinSock on Windows, Libc on Linux, etc) will not know that the socket is lost until the library times out internally and then invalidates the socket. Until that happens, there is no way for Indy to know whether the socket is actually connected or not, because the library itself does not know.