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...
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With