WCF net.tcp 连接在 9 小时 1 分钟后断开答案

【问题标题】：WCF net.tcp connection dies after 9 hours, 1 minuteWCF net.tcp 连接在 9 小时 1 分钟后断开
【发布时间】：2010-11-19 10:02:35
【问题描述】：

我有一个 WCF 客户端与 WCF 服务器（在同一台机器上）通信。我们使用带有消息级安全性的 netTcpBinding（使用自定义 principalPermissionMode 和 serviceCredentials 的自定义实现）。该服务标有InstanceContextMode.PerSession。

WCF 服务自托管在 Windows 服务中（不在 IIS 中）。

为了伪造keep-alive，我们有一个Ping 方法，客户端每15 秒调用一次。我们在客户端程序的整个生命周期内保持客户端代理处于打开状态（因为在我们的例子中初始化会话是昂贵的）。

尽管如此，连接在 9 小时 1 分钟后断开（在 10 次测试运行中，其中 7 次在 9h1m6s 后死亡）。

WCF 日志中唯一的后果是“SocketConnection aborted”消息，随后是一组不同的异常，但通常包括“connection was in the faulted state”异常。

WCF 或 TCP/IP 中是否有一些超时导致了这种情况？因为我被难住了。

【问题讨论】：

10 次测试运行，每次运行超过 9 小时？我很佩服你的耐心。
老实说，这是 4 个客户端的 2 次测试运行，1 个客户端同时运行 2 次。所以只有 18 小时，而且还是一夜之间离开。
如果你再仔细想想，9x3600+60+6<32768，是 15 的 2 次方
是的，但不完全是，即便如此，这是从哪里来的？

标签： wcf

【解决方案1】：

经过大量繁琐的调查：大约 9 小时后，WCF 客户端重新对服务进行身份验证。我在身份验证步骤中正在执行的操作是终止现有会话。

【讨论】：

+1 - 我遇到了这个问题并独立得出了相同的结论。希望我首先从您的研究中受益，但我不知道要搜索什么。我很好奇身份验证出了什么问题？在我们的案例中，我们正在执行自定义身份验证，并且故意不允许同一个客户端连接两次，这在验证中进行了检查。所以，重新验证总是失败。
@JoelLee：确实如此，但更靠后。重新身份验证正在杀死之前的后端会话，该会话触发了 Kicked 事件，这导致我拆除了 WCF 会话，从而杀死了客户端。

【解决方案2】：

从上面的 cmets 中，您同时运行测试。

它们是否也在同一台服务器上，使用同一个应用程序池？

如果是这样，应用程序池的回收可能会导致所有测试同时停止。

【讨论】：

是的，同一台服务器。不使用 IIS，所以没有应用程序池。让我的 QA 人员让客户交错开始，看看他们是同时死去，还是在同样的延迟之后死去。