Does WCF Channel Faulted state help at all?

I can't map the concept of a faulted channel back to the manual implementation of some bindings. I think this WCF feature is annoying and I wonder if is there any way to disable it.

Take TCP for example. Most of the TCP communication is disconnected. So why on earth would one connection fault the channel and break all the following connections?

And named pipes?

Maybe I'm wrong about it. So please explain 开发者_开发问答why it is a feature, and not a bug.

I think it's a product of Juval Löwy's (one of the WCF architects) overall philosophy of WCF. Quoting his book Programming WCF Services:

This [the exception system and the normal way of using it] is a fundamental flaw of .NET as a platform. [...] Here [after an exception is thrown], something totally unexpected and horrible has happened. How could the client possibly pretend otherwise? The object may be hopelessly broken, and yet the client keeps using it.

The idea is that you are, after all, communicating with an object on the other side of whichever transport channel you are using, and if the object throws an exception, it might not be usable any more. It's an interesting point, but I'm not sure I agree completely (since, as you say, it can be quite annoying in practice).

Faulted is one of the states of the CommunicationObject state machine which is baked into the implementation of many WCF abstractions. It essentially means "game over" for that object, so you are not going to find any way to disable it.

It certainly isn't a bug: the CommunicationObject state machine underlying all these artefacts was a conscious design choice. Whilst it may be of passing interest to debate the design decisions made by the WCF architects, ultimately you just need to accept that's how things are and move on, if you want to use WCF.

You should think of a channel as being more than just an adapter for the transport being used: it is a higher level abstraction which wraps up a number of different layers in the communication stack (transport, encoding, security, session management, transaction flow, duplexing, etc).

Even looking at the details of specific bindings you will find very few elements of the stack which are fault tolerant to the extent that you could safely reuse them after a previous communication attempt has failed (e.g. HTTP protocol, perhaps). Even the ones you mention (TCP, Named Pipes) are not as fault-tolerant as you suggest.

I think the CommunicationObject state machine, or something like it, is more or less essential in order to have a channel abstraction which works at a higher level than the nitty-gritty detail of all its constituent layers/elements. It enables the simple rule: if it's Faulted, throw it away and make a new one. Yes, there may be a few cases where in doing so you miss an optimisation which would have been possible by keeping some resource which could be safely reused; but this is the (small) cost you pay for working with a much simpler abstraction of your communications.

This is what WCF does:

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

Here 'SomeOp' failed, not 'a', so why does SomeOtherOp have to fail?

This makes sense if

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