How do I automatically re-establish a duplex channel if it gets faulted?

Question

Hi,

I'm developing a client/server application in .Net 3.5 using WCF. Basically, a long running client service (on several machines) establish a duplex connection to the server over a netTcpBinding. The server then uses the callback contract of the client to perform certain on-demand oparations, to which the client responds in an asynchronous fashion (fairly standard stuff I think). I subclass the DuplexClientBase class to handle most of the communication.

Unfortunately, when something goes wrong on either end (such as a network failure, unexpected exception, etc), the channel gets faulted/aborted and all subsequent operations fail. I've gotten around this limitation in non-duplex channels by creating a RecoveringClientBase class that automatically picks up when the client has faulted and retries the operation.

So my question is, is there an established way of determining when a duplex channel has faulted? Where should I check this, on the server or the client? Failing that, what options do I have to ensure that the connection gets re-established?

Update: I'm looking for some advice specific to duplex channels, where the server might try to use a callback channel that was faulted. Thus, I need something that will immediately reconnect/resubscribe when something happens to the channel. At the moment I'm listening to the channel's Closing event and recreating it if the state is anything but Closed. It sort of works, but it feels hacky...

Answer 1

Nicolas Allen, from the WCF team has suggestions for this:

http://blogs.msdn.com/drnick/archive/2007/11/05/custom-transport-retry-logic.aspx

His suggestion is to handle this at the channel level. The channel level is a bit nicer, since you can plug it into any binding's stack via behaviors instead of requiring a custom client base class.

Answer 2

I've had some similar problems, and to me it seems that these long-running calls are more or less unsupported.

WCF seems to be designed to be used for short running calls. Services, which get called, do some small stuff, and be finished.

I refactored my applications into smaller items of work. So instead of one big long running item I now got a lot of smaller items. Of course, sometimes this is not possible to achieve. Then I got to pray for stable network connections (exceptions can be caught, so faulting is not really a problem I think).

Answer 3

I have experienced flakiness in long running sessions (minutes-hours). I can't be sure that it's WCF, I'm pretty sure its network level.

I am thinking of doing away with duplex altogether. It is a real nuisance trying to manage the state of the connection.

I am thinking of hosting a service endpoint on the client for operations that are currently part of the callback contract. The client would contact the server with the endpoint details, the server can store these somewhere (persisted or wherever). When the server needs to contact the client, it opens a connect to the client via the stashed endpoint details. Basically, turning the duplex connection into 2 client-server connections.

Doesn't answer your question, but I feel your pain.