Question

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

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

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

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

    [OperationContract]
    ServerResponse SendChunk (Chunk chunk);

其中ServerResponse将保存一些枚举或bool标志，以告诉客户端SendChunk操作是否正常。但是，我将不得不在客户端和服务器端保留某种数组，以跟踪所有块状态。我只是不确定在那里使用的最佳模式是什么。任何建议都将受到高度赞赏。

Answer 1

我们的应用程序中存在类似的问题 - 低带宽和多次断开连接/超时。我们有较小的消息，所以我们没有拆分它们，但解决方案也应该适用于块。我们在客户端创建了Repeater。这被证明是可靠的解决方案 - 它适用于连接缓慢，连接不良的客户端（如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

服务器：

接受请求



重复Chunk

2A。是：



是最后一块：

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

3B。不 - 发送确认回复


2B。号：



在某处保存请求（列表，字典等）



这是最后一块：

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

5B。否 - 发送确认消息

WCF：WS-Dual绑定或basichttp绑定到块文件中的流文件

1 个答案: