Question

我无法将故障通道的概念映射回某些绑定的手动实现。我认为这个WCF功能很烦人，我想知道是否有任何方法可以禁用它。

以TCP为例。大多数TCP通信都是断开连接的。那么，为什么地球上的一个连接会对通道造成故障并破坏以下所有连接呢？

并命名管道？

也许我错了。所以请解释为什么它是一个功能，而不是一个错误。

Answer 1

我认为它是JuvalLöwy（WCF架构师之一）WCF整体理念的产物。引用他的书编程WCF服务：

这个[异常系统和使用它的常规方式]是.NET作为平台的根本缺陷。 [...] [在抛出异常之后]，发生了一些完全出乎意料和可怕的事情。客户怎么可能假装不是呢？该对象可能无可救药地被破坏，但客户端仍在继续使用它。

这个想法是，毕竟，您正在与正在使用的传输通道的另一端的对象进行通信，并且如果对象抛出异常，它可能无法使用任何更多。这是一个有趣的观点，但我不确定我是否完全同意（因为，正如你所说，在实践中它可能非常烦人）。

Answer 2

Faulted是CommunicationObject状态机的状态之一，它被用于许多WCF抽象的实现。它本质上意味着该对象的“游戏结束”，所以你不会找到任何方法来禁用它。

这当然不是一个错误：所有这些文物底层的CommunicationObject状态机是一个有意识的设计选择。虽然WCF架构师对设计决策进行辩论可能会引起人们的兴趣，但如果您想使用WCF，最终您只需要接受事情的发展方向并继续前进。

您应该将通道视为不仅仅是正在使用的传输的适配器：它是更高级别的抽象，它包含通信堆栈中的许多不同层（传输，编码，安全性，会话管理，交易流程，双工等）。

即使查看特定绑定的详细信息，您也会发现堆栈中很少的元素具有容错性，以至于您可以在先前的通信尝试失败后安全地重用它们（例如，可能是HTTP协议）。即使你提到的那些（TCP，命名管道）也不像你建议的那样具有容错能力。

我认为CommunicationObject状态机，或类似的东西，或多或少是必不可少的，以便有一个通道抽象，它的工作水平高于其所有组成层/元素的细节。。它启用了简单的规则：如果它是Faulted，则抛弃它并创建一个新规则。是的，在某些情况下，您可能会错过优化，这可以通过保留一些可以安全重用的资源来实现;但这是你用更简单的通信抽象支付的（小）成本。

Answer 3

这就是WCF的作用：

Proxy a = new Proxy();
a.SomeOp() -> threw exception
a.SomeOtherOp() -> faulted

这里'SomeOp'失败了，而不是'a'，为什么SomeOtherOp必须失败？

如果

，这是有道理的

Proxy a = new Proxy(); -> threw exception
a.SomeOp() -> faulted

WCF Channel Faulted状态是否有帮助？

3 个答案: