WCF 发布/订阅：如何处理客户端超时以免错过信息？答案

【问题标题】：WCF Publish / Subscribe: How to handle client side timeout so as not to miss information?WCF 发布/订阅：如何处理客户端超时以免错过信息？
【发布时间】：2011-09-03 05:10:44
【问题描述】：

我有一个简单的 WCF 发布/订阅启动并运行，based on this example。我正在使用启用了可靠会话的 netTcpBinding。该功能一切正常（订阅的客户端按预期接收发布的数据），但如果连接空闲一段时间，连接会超时。我可以设置发布者在超时时重新连接，但订阅的客户端将会丢失。有没有办法让他们回来？我不希望仅仅增加超时，因为这可能会导致其他问题。

【问题讨论】：

标签： wcf timeout publish-subscribe reconnect

【解决方案1】：

我最终想出的解决方案是为每条发布的消息分配一个唯一标识符，并将发布的消息缓存在服务适配器中（在我将回调存储到订阅客户端的同一个地方。每当我发布消息后，订阅者将收到消息和相应的唯一 ID。然后订阅者可以使用 channel.Faulted 事件重新连接并使用特殊方法重新订阅服务，该方法将最后收到的消息 ID 作为一个参数。

服务代码：

    /// <summary>
    /// Operation used by the subscriber to subscribe to events published.
    /// </summary>
    public void Resubscribe(int lastReceivedMessageId)
    {
        // Get callback contract
        IPubSubCallback callback = OperationContext.Current.GetCallbackChannel<IPubSubCallback>();
        ThreadPool.QueueUserWorkItem(delegate(object state)
        {
            adapter.Resubscribe(lastReceivedMessageId, callback);
        }); 
    }

适配器代码：

/// <summary>
    /// Operation used by the subscriber to resubscribe to events published.
    /// </summary>
    public void Resubscribe(int lastReceivedMessageId, IPubSubCallback callback)
    {
        try
        {
            // Send the subscriber any missed messages
            foreach (KeyValuePair<int, string> missedMessage in publishedMessages.Where(x => x.Key > lastReceivedMessageId))
            {
                callback.MessagePublished(missedMessage.Value, missedMessage.Key);
            }

            // Add the subscriber callback to the list of active subscribers
            if (!callbacks.Contains(callback))
            {
                callbacks.Add(callback);
            }
        }
        catch
        {
            // ignore subscription, callbacks failed again
        }
    }

然后该服务可以计算出客户端错过了什么，并以正确的顺序重新发送这些消息。

这个解决方案似乎对我很有效，但我觉得必须有更好的方法来做到这一点。非常欢迎评论/补充答案！ :)

【讨论】：

如果“客户端”不是最终用户机器而是数量有限的服务器，您可以尝试使用 WCF 的MSMQ based Pub/Sub。从某种意义上说，它是“更好的”，可以保证消息被传递并且这是异步发生的。不利的一面是，只有在设置和配置自动化的情况下，才能在每台机器上配置 MSMQ。
谢谢！这种方法可能对我未来的一些发布-订阅需求有用。我将研究如何设置它:)