Two way communication with WCF - Should I use callbacks, or simply use two channels?

Question

Hi,

I'm trying to decide what is the most most appropriate way of handling full duplex communication between two .Net processes running on the same server or on a LAN. We have two processes that need to be able to invoke methods on each-other.

Currently, we are using WCF with NamedPipe or Tcp channels, and have ProcessA register with ProcessB. Our WCF Contract specifies a Callback interface, so ProcessB can then invoke methods on ProcessA.

My question is which of the following make more sense, is more simple, and more robust?

1. Have ProcessB use the Callback interface (supported by WCF) to invoke methods in ProcessA.
2. During registration have ProcessA pass ProcessB the required information for ProcessB to register with ProcessA using a new channel?

I don't fully understand the lifetime of the callback proxy and threading issues. I've seen various posts about callback methods blocking.

Answer 1

Your option 2 is basically just a description of what WCF does for you in option 1.

When your client opens a connection, it registers the callback channel with the service. This channel stays open until you close it - either by explicitly calling Close on it, or by disposing it.

So in the scenario that you have described, it sounds like you should just continue with callback contracts. That's what they are for.

Answer 2

Option 2 does describe what option 1 does but it implements its ways that you could not do yourself. For example if you use TCP channels it will use the Socket that the client opens to the server to send data back.

This means it will work behind a firewall and a NAT.

Checkout

http://diagonaltechblog.blogspot.com/2009/12/wcf-duplex-channels-firewalls-and-nats.html

its does not go into to much details about how to create a duplex channel but it sounds like you have managed that much.

Cheers