使用 Silverlight 4 轮询双工的 StreamedResponse 不发送更新
我正在尝试使用 Silverlight 4 和轮询双工启用流式响应，但当向客户端发送更新的速率大于 maxOutputDelay 时，我会出现奇怪的行为，这会导致不发送任何更新。
例如，如果 maxOutputDelay 为 7 秒，并且每 10 秒发送 1 次更新，则一切正常。但是，如果我的 maxOutputDelay 为 1 秒，并且每 500 毫秒发送一次更新，则更新只会位于服务器端，不会发送到客户端。
据我了解，设置transferMode =“StreamedResponse”应该立即将更新发送到客户端，但这似乎不起作用。
以下是我的 Web.config 中针对 Web 服务的绑定：
此配置基于本文中的信息：http://blogs.msdn.com/b/silverlightws/archive/2010/06/25/http-duplex-improvements-silverlight-4.aspx
谢谢。
I'm trying to enable a streamed response using Silverlight 4 and polling duplex, but I'm getting strange behaviour when the rate at which updates are sent to the client is greater than the maxOutputDelay, which results in no updates being sent.
For example, with a maxOutputDelay of 7 seconds, and 1 update sent every 10 seconds, everything works fine. But if I have a maxOutputDelay of 1 second, and an update sent every 500 milliseconds, the updates just sit on the server side and don't get sent to the client.
It's my understanding that setting transferMode="StreamedResponse" should send the updates immediately to the client, but this doesn't seem to be working.
Here's the binding in my Web.config for the web service:
This config is based on the information from this article: http://blogs.msdn.com/b/silverlightws/archive/2010/06/25/http-duplex-improvements-silverlight-4.aspx
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您不完全专注于使用双工通道（除了单主机场景之外，在任何情况下配置双工通道都很痛苦），那么可能值得检查用于实现服务器回调的替代解决方案 - 即使这意味着您必须维护两种不同的类型与您的后端的连接。
双通道替代方案：
If you are not totally focussed on using Duplex Channels (which are a pain to configure in anything but a single host scenario) it might be worth checking out alternative solutions for implementing Server Callbacks - even if that means that you have to maintain two different types of connection to your backend.
Duplex Channel Alternatives:
我认为这篇文章回答了这个问题：
http://blogs.msdn.com/b/silverlightws/archive/2010/07/16/pollingduplex-multiple-mode-timeouts-demystified.aspx
maxOutputDelay 更像是消息内计时器。因此，如果您的消息速率超过此延迟，您将永远不会触发刷新，直到缓冲区填满。它会在添加到队列中的每条新消息时重置。所以我想我们必须调整队列大小以及计时器才能实现最大实际延迟。
我不确定为什么流式响应仍然缓冲，但我也看到了。有谁知道如何调整缓冲区大小？
[编辑]
好吧，这篇文章说我们无法控制流响应中的缓冲（自托管中为 16k，IIS 中为 32k）。因此，鉴于此，以大于 maxoutputdelay 的速率传入的小消息似乎是一种病态情况。也许我必须用数据填充它们...
http://blogs.msdn.com/b/silverlightws/archive/2010/06/25/http-duplex-improvements-silverlight-4.aspx
I think this article answers the question:
http://blogs.msdn.com/b/silverlightws/archive/2010/07/16/pollingduplex-multiple-mode-timeouts-demystified.aspx
The maxOutputDelay is more like an intra-message timer. So if your message rate exceeds this delay you will never trigger a flush until the buffer fills. It gets reset on each new message added to the queue. So I guess we have to tune the queue size as well as this timer to achieve a maximum actual latency.
I'm not sure why the streamed response still buffers but I see it too. Does anyone know how to tune that buffer size?
[Edited]
Ok, this article says that we cannot control the buffering int he streamed response (it is 16k in self-hosted and 32k in IIS). So, given that, it seems like small messages coming in at a rate greater than your maxoutputdelay are a pathological case. Maybe I have to pad them with data...
http://blogs.msdn.com/b/silverlightws/archive/2010/06/25/http-duplex-improvements-silverlight-4.aspx