WCF中的异步流

Question

我正在使用带有WCF的Streaming,我有一个关于" 启用异步流 " 的段落的含义的问题来自MSDN关于WCF中的大数据和流的文章.

要启用异步流,请将DispatcherSynchronizationBehavior端点行为添加 到服务主机并将其AsynchronousSendEnabled属性设置为true.我们还在发送端添加了真正异步流的功能.这提高了服务的可扩展性,在这种情况下,它将消息流式传输到多个客户端,其中一些客户端可能由于网络拥塞或根本不读取而导致读取速度缓慢.在这些场景中,我们现在不会阻止每个客户端的服务上的单个线程.这确保了服务能够处理更多客户端,从而提高了服务的可扩展性.

我明白上面的意思是我补充说

<behaviors>
  <endpointBehaviors>
    <behavior name="AsyncStreaming">
      <dispatcherSynchronization asynchronousSendEnabled="true" />
    </behavior>
  </endpointBehaviors>
  ...

对于我的web.config文件并引用AsyncStreaming我的端点中的行为,但是我不明白为这些步骤完成了什么.我是否需要修改我的代码才能利用这种异步性？

同样在一个类似的主题上(但是如果它太不同了我会把它转移到一个新问题),在WCF中使用Streams使用async/await效果怎么样？我可以Task<Stream> Foo()签订服务合同吗？我做了一些数据库调用,其结果我最终将包装到我将从WCF服务返回的自定义流中.能够使用ExecuteDataReaderAsync()非常有用的东西,在处理流式传输而不是缓冲消息时,我仍然可以使用它吗？

我测试了它,我知道它"工作"使用任务但我不知道是否这样做会导致函数回退到"缓冲"模式,就像你为函数提供多个参数一样(参见第3段) " 流传输的编程模型 "在同一个MSDN页面上),我不知道如何检查是否发生了这种情况.

Answer 1

RequestContext我通过 .NET 参考源追踪到了它。显然，该ChannelHandler.sendAsynchronously字段控制消息回复是异步完成（通过RequestContext.BeginReply/EndReplyAPM 方法）还是通过 同步完成RequestContext.Reply。

据我所知，这一切所做的只是释放一个服务器端线程，该线程返回到池中，否则只要RequestContext.Reply对象Stream还活着，该线程就会忙于将流“泵送”到客户端服务器。

这看起来是完全透明的，所以我认为你可以安全地使用async基于 TAP 的合约方法并返回Task<Stream>。await Stream.WriteAsync例如，在另一种合同方法中，您可以这样做。

当你到达那里时，请分享你的实际经历作为你自己的答案，我对细节非常感兴趣:)