Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

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...

like image 572
Jacob Avatar asked Oct 15 '08 11:10

Jacob


2 Answers

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.

like image 197
Jimmy McNulty Avatar answered Sep 19 '22 18:09

Jimmy McNulty


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.

like image 1
jezell Avatar answered Sep 21 '22 18:09

jezell