Publish/Subscribe Pattern for WCF TCP Duplex Binding Configuration

Question

I have a WCF configuration dilemma when using WCF TCP Binding for Duplex Callbacks as part of a Publish/Subscribe design pattern.

The requirement is for the Client to receive notifications from the Server using one-way callbacks. It is unknown when the notifications will be received therefore the aim is to keep the connection open indefinitely. If an exception is received by either the Client or Server then the cleanup process is initiated to correctly Close, Abort and cleanup the CommunicationObject and then issue a new connection to continue receiving notifications.

I have explicit access to configure both the Client and Server WCF endpoints. My dilemma is whether I should:

A. Keep the sendTimeout and receiveTimeout configuration properties set to infinite to keep the connections open as long as possible whilst still handling exceptions to reopen the connection.

Or

B. Keep the sendTimeout and receiveTimeout to a lower time span, for example 1 hour. The timeouts would be received by the client or server, cleaned up, and then a new connection established.

Would there be an advantage of using one over the other or is WCF not a viable solution for my problem?

My aim is to maintain the highest availability possible.

EDIT:

The reason why I was concerned about the timeouts was that the server is unexpectedly closing or timing-out the connection without the client receiving any notifications of this through either the Faulted and Closing events, but I can confirm that both the client and server are both using infinite timeouts for sendTimeout and receiveTimeout . This normally happens within a 24 hour time scope.

Researching the MSDN documentation for a WCF Duplex model I read the following statement:

The duplex model does not automatically detect when a service or client closes its channel. So if a client unexpectedly terminates, by default the service will not be notified, or if a client unexpectedly terminates, the service will not be notified. Clients and services can implement their own protocol to notify each other if they so choose.

Which brings me on to ask whether anyone has a solution for implementing their own protocol for keeping a session alive as this is the problem I have?

Do I need to simply have a client thread which sends a "heartbeat" to the server on a regular time interval? Obviously I don't want to spam the network with heartbeats, but at the same time keep the session alive as much as possible.

I believe a ReliableSession would provide no real benefit to this problem.

Answer 1

I think you should just keep receiveTimeout as infinite and that's it. There is no bonus of recreating a channel every hour.

You do not need to set sendTimeout to infinite because this is a timeout that defines for how long WCF infrastructure waits before claims that it cannot send a message.

PS In our application we use similar technique and channel is kept opened for weeks without any problems.