在 Mac 上的浏览​​器 Silverlight 客户端中轮询双工服务失败

Question

我们有一个 Silverlight 客户端，它在 Mac 上运行“浏览器外”。此客户端通过轮询双工绑定使用 WCF 服务。

在客户端中，我正在监听 System.ServiceModel.DuplexClientBase 派生的“InnerChannel”属性公开的“Faulted”事件，它代表客户端中的服务。

恰好一分钟后，触发了“Faulted”事件，之后通道不再工作，即当服务器尝试通过回调通道发送消息时，它会收到超时异常。

这是我的一个理论：我怀疑客户端中的底层轮询操作有 1 分钟的超时。在服务器端，pollingDuplexHttpBinding 部分的 serverPollTimeout 属性设置为超过一分钟。这意味着如果服务器在此期间没有任何信息可告诉客户端，则服务器会持有一个轮询请求超过一分钟。我怀疑这揭示了客户端轮询消息中的超时。为了验证我的理论，我将 serverPollTimeout 设置减少到不到一分钟，而且确实 - 没有显示问题。

在客户端，有PollingDuplexBindingElement.ClientPollTimeout属性，根据this博客的设置，应该告诉客户端等待一分钟以上。此设置的默认值为 5 分钟，我什至已明确设置 - 但问题仍然存在（没有上述解决方法）。

请注意，此问题仅在浏览器客户端之外的 Mac 上发生。

总而言之，这是我的问题：

• 我如何/在哪里可以看到描述性错误消息，它准确地说明了这里的问题是什么？
• 为什么它只发生在 Mac 浏览器客户端之外？
• 谁能证实我的理论？
• 如果我的理论是正确的 - 我如何才能真正为客户端中的轮询请求设置超时？

Answer 1

在 Microsoft 支持下就此问题进行了长时间讨论，以下是有关此问题的结论：

• 此问题也与“常规”WCF 调用有关。如果我们从 SL Mac OOB 调用常规 WCF 操作，它会在整整一分钟后超时，即使超时设置得更高
• Microsoft 确认 60 秒是 Mac OS 上的默认超时，并且 SL 运行时不会调用所需的 Mac OS API 将其设置为更高的值，即使 SL 客户端代码使用记录在案的 SL API 来更改暂停。他们说这是“设计使然”，因为他们不知道在任何情况下即使在长时间轮询中服务器也可能需要这么长时间