0

我目前正在开发服务，其中客户端通过发送带有消息的 xml 文件与服务器进行通信。为了提高消息传递的可靠性（客户端将使用低质量的有限带宽切换移动互联网），我将这些消息分成 64 或 128 Kb 大小的较小部分，并在 BasicHttp 绑定中使用 transfer="streamed" 发送它们。

现在，我有一个问题：服务器应该向客户端报告，如果他成功接收到一个块，那么在 fe 5 个块传输失败后，传输过程将被取消并推迟到稍后尝试，并跟踪哪个收到了块，哪些没有。

我正在考虑使用回调机制与客户端通信，因此服务器将调用回调方法 ChunkReceived 在它的 [OperationContract] 中，当它将块保存到服务器端的文件中，但是，如果我错了，请纠正我，但是回调仅适用于 WS Dual http 绑定，在 basichttp 绑定中不受支持。但 WS Dual 绑定不支持流式传输。

那么我可以切换到 WS Dual 绑定并使用 transfer="buffered" （考虑到块大小相对较小） - 这不会损害传输的可靠性吗？或者也许我可以通过基本的http绑定以某种方式与客户端通信，也许通过返回某种响应消息，即

    [OperationContract]
    ServerResponse SendChunk (Chunk chunk);

ServerResponse 将保存一些枚举或布尔标志来告诉客户端 SendChunk 操作是否正常。但是我将不得不在客户端和服务器端都保留某种数组来跟踪所有块的状态。我只是不确定在那里使用的最佳模式是什么。任何建议将不胜感激。

4

1 回答 1

1

我们在我们的应用程序中遇到了类似的问题 - 低带宽和许多断开/超时。我们有较小的消息，因此我们没有拆分它们，但该解决方案也应该适用于块。我们已经在客户端创建了中继器。这被证明是可靠的解决方案 - 它适用于连接速度慢、连接不良的客户端（如 GPRS - 经常在移动中断开连接）。如果服务器由于高负载而变慢，客户端也不会出现超时错误。这是修改后的版本，带有块

客户：

1. Client sends Chunk#1, with pretty short timeout time

2. Is there OK response:

   2A. Yes - proceed to next chunk

       3. Was that last chunk?

          3A. Yes - process reponse

          3B. No - send next chunk

   2B. No - repeat current chunk

服务器：

  1. 接受请求

  2. 块是否重复

    2A。是的：

    1. 是最终块：

      3A。是 - 检查响应是否准备好，否则等待（这可能会让客户重复）

      3B。否 - 发送 Ok 回复

    2B。不：

    1. 将请求保存在某处（列表、字典等）

    2. 这是最后一块：

      5A。是 - 处理消息，保存响应，并将其发送给客户端

      5B。否 - 发送确定消息

于 2012-08-09T07:37:52.277 回答