0

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.

Community
  • 1
  • 1
user978139
  • 579
  • 4
  • 16

1 Answers1

0

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.

Igor Labutin
  • 1,406
  • 10
  • 10
  • Thanks for your reply - I have extended my question based upon some research I have found todo with the duplex model. Your experience on this topic would be much appreciated. – user978139 Jan 18 '16 at 08:41
  • Yes, we do implement heartbeat on some of our connections. Like calling a `Ping()` method every minutes or so. This does not provide immediate feedback for faulted connection, but was enough in our business. I must also say that our client maintain about 8 connections on different endpoints to the server and all of them are 'permanent'. But only one of them (special, dedicated) is used for heartbeat. We haven't seen any cases with one connection closing while others were alive. – Igor Labutin Jan 20 '16 at 23:25