我们有一个在Mac上运行"浏览器外"的Silverlight客户端。此客户端通过轮询双工绑定使用 WCF 服务。
在客户端中，我正在侦听由 System.ServiceModel.DuplexClientBase 派生的 "InnerChannel" 属性公开的"错误"事件，该属性表示客户端中的服务。
恰好一分钟后，这个"Faulted"事件被触发，之后通道不再工作，即当服务器尝试通过回调通道发送消息时，它会得到超时异常。
这是我的一个理论：我怀疑客户端中的底层轮询操作超时为 1 分钟。在服务器端，轮询DuplexHttpBinding节的serverPollTimeout属性设置为超过一分钟。这意味着，如果服务器在此期间没有要告诉客户端的内容，则服务器将保留轮询请求超过一分钟。我怀疑这揭示了客户端轮询消息中的超时。为了验证我的理论，我将 serverPollTimeout 设置减少到不到一分钟，事实上 – 问题没有显示出来。
在客户端，有 PollingDuplexBindingElement.ClientPollTimeout 属性，根据此博客，该属性正是应该告诉客户端等待一分钟以上的设置。此设置的默认值为 5 分钟，我什至明确设置了它 - 但问题仍然存在(没有如上所述的解决方法(。
请注意，此问题仅在浏览器客户端之外的Mac上发生。
总而言之，这是我的问题：
- 我如何/在哪里可以看到描述性错误消息，该错误消息确切地说明了这里的问题是什么？
- 为什么它只发生在浏览器客户端之外的 Mac 中？
- 有人可以证实我的理论吗？
- 如果我的理论是正确的 – 我如何才能真正在客户端中设置轮询请求的超时？
在Microsoft的支持下对此进行了长时间的讨论之后，以下是有关此问题的结论：
- 此问题也与"常规"WCF 调用相关。如果我们从SL Mac OOB调用常规WCF操作，它将在正好一分钟后超时，即使超时设置为更高
- Microsoft确认 60 秒是 Mac OS 上的默认超时，并且 SL 运行时不会调用所需的 Mac OS API 将其设置为更高的值，即使 SL 客户端代码使用记录的 SL API 来更改超时。他们说这是"设计使然"，因为他们不知道即使在长时间的民意调查中服务器可能需要那么长时间的任何情况 。