是否从服务器结束WCF会话？

这可能是在黑暗中拍摄的（我对WCF的内部结构不太了解），但接下来

我目前正在一个客户端站点上使用一个遗留应用程序，我们遇到了一个WCF服务的持久性问题。应用程序正在使用Microsoft Sync Framework 2.0并通过上述服务进行同步。该服务的服务器端实现有许多处于各种“混乱”状态的自定义代码

无论如何，我们在大多数情况下都会在客户端应用程序上看到错误，我们缩小的模式集中在使用同一台机器上的应用程序的不同用户使用相同的服务。在身份验证级别上，服务和客户端似乎在某种程度上失去了同步

在一篇文章中讨论了这个错误，我们目前正在研究从消息层安全性切换到传输层安全性的方法，这有望解决这个问题。然而，如果这个问题有意义的话，我们也许能够以一种侵入性较小的方式解决它

在链接的文章中，其中一条建议是，如果捕获到特定的异常，则强制终止连接，然后重试，如果再次失败，则不是因为这个特定的理论。听起来不错，而且很容易实现。然而，我发现自己无法自信地说连接是否正确终止

该服务通过在服务器端实现的自定义接口进行操作。接口可以结束连接的唯一方法是在代理本身上调用

EndSession（）

，它调用服务器上的

EndSession（）

，这是一种自定义方法

所以

从WCF服务方法来看，是否有一种方法可以以客户机喜欢的方式正确、优雅地终止与客户机的连接

也就是说，在这个自定义的

EndSession（）

中，是否有最后一步可以让服务器完全忘记此连接已打开？因为它看起来像是当同一台机器上的另一个用户试图点击应用程序中的服务时，这就是它失败的时候，链接文章中出现了错误

其思想是，在事物的客户端，调用

EndSession（）

的代码之后会清空代理对象，然后调用工厂方法在下次需要时提供另一个方法。因此，我想知道是否需要在服务器端（如果不是所有这些自定义实现代码，在WCF中默认情况下也是如此）发生一些额外的事情来终止该端的连接

---

就像我说的，黑暗中的一枪。但也许在这里的回答/讨论中，我至少可以进一步诊断问题，因此非常感谢任何帮助。谢谢。

不幸的是，实际上只有三种方式可以终止

客户端关闭代理

已超过服务的receiveTimeout 在客户端发送另一个 请求

该服务抛出了一个错误 将发生故障的非故障异常 通道，从而终止 会议

如果你不想让客户参与进来，那么你只有2个和3个，这两个对客户来说都不好——在下一次尝试与服务对话时，他们在这两种情况下都会出现异常

---

您可以使用并获得该服务来通知客户端其需要终止会话-然后客户端有机会优雅地关闭代理，但这是一种合作策略

很抱歉，花了一段时间才恢复到这一点，这是一个忙碌的周。我想我们将稍微研究一下双工消息传递（尽管这段遗留代码的状态不适合改变），我很欣赏这个建议。但我至少已经测试了你关于终止的观点，对客户来说没有好的结局，你是绝对正确的：）在任何情况下，由于团队不完全了解的原因，系统现在大部分都在工作。我想我们让客户成功地关闭了代理。谢谢你的建议！