Seeking WCF Duplex "TwoWay" Subscribe+Callback Example

Question

Renewing the bounty AGAIN because I really need to know how to get this to work, or a definitive answer about why it won't.

I've added an alternative explanation of the problem here.

Having a hell of a time getting a two-way (IsOneWay = false) WCF client-server to work in .Net 3/3.5.

After the client successfully enrolls with the service, the service's periodic Announcement() calls-back to the enrolled clients. It is now that either the client or the server hangs until the server's SendTimeout, adjusted to 2 seconds, elapses. Then the server side has a timeout exception as follows. Only then does the client user code immediately RECEIVE THE METHOD CALL and attempt to return a value. By then the client's socket is aborted and the WCF stuff fails.

It seems to me that something on the client is hanging it's local WCF queue from processing until the socket times out, but not quite early enough to cancel the local method call. But if the exception below is to be believed, the server is attempting to send an operation to http://schemas.microsoft.com/2005/12/ServiceModel/Addressing/Anonymous (inappropriate!) and is timing out. Maybe that URI is just the "Name" of the remotely connected client as WCF knows to refer to it for the purposes of the error message and it just appears to mean that it's failing to load a URI. I can't tell if the server fails first or the client fails first.

I've tried adding WCF tracing but I'm not getting much more information.

Similar sample code is here, but it must have been too much to digest. I've experimented with varations of that code.

TimeoutException 'This request operation sent to http://schemas.microsoft.com/2005/12/ServiceModel/Addressing/Anonymous did not receive a reply within the configured timeout (00:00:00).  The time allotted to this operation may have been a portion of a longer timeout.  This may be because the service is still processing the operation or because the service was unable to send a reply message.  Please consider increasing the operation timeout (by casting the channel/proxy to IContextChannel and setting the OperationTimeout property) and ensure that the service is able to connect to the client.'

Server stack trace: 
   at System.ServiceModel.Dispatcher.DuplexChannelBinder.SyncDuplexRequest.WaitForReply(TimeSpan timeout)
   at System.ServiceModel.Dispatcher.DuplexChannelBinder.Request(Message message, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
   at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Solution 1

Firstly get yourself a copy of Programming WCF Services, if you don't already have one.

If the client is WinForm or WPF, you need to use [CallbackBehavior(UseSynchronizationContext = false)] as otherwise the client will not process the incoming message until the UI thread enters the message loop.

Firstly a “Duplex” channel in WCF is not truly Duplex! A message from

• Client to server
• Can block a message the server is waiting for from the client
• (or the other way round)

As messages are only dispatched in order on a single WCF channel. A Duplex WCF channel does NOT give you two incoming message queues. The results coming back from a “TwoWay” call are just the same as the “call” as this level of the WCF stack. Once you get your head round this a lot of the problems become clearer to understand.

If the client is WinForm or WPF, you may need to use [CallbackBehavior(UseSynchronizationContext = false)] as otherwise the client will not process the incoming message until the UI thread enters the message loop.

Some rules I found to help avoid deadlocks. (Look at my WCF questions to see the pain I had!)

The sever must never call out to a client on the same connection as a call from the same client is in process on.

And/or

The client must never call back to the server on the same connection as is used for the “callbacks” while processing a call-back.

The next time I think I will just use two contracts (and hence TCP connections) one for the callback and other for all client->server requests. Or use my own polling system, as this gave me so much pain.

Sorry I don’t have time today to write an example. Anyway most examples work for what the example is trying to do, but break down in real life for some reason to do with your application.

The best web site I know for WCF examples is Juval Lowy’s web site.

Your may also find the questions I asked about WCF on Stack Overflow useful, as I was having the same kind of problems as you.

Also spending a day or two reading all the WCF questions and answers on Stack Overflow will give a good idea of the problems to avoid.

Solution 2

Assuming the client is a WinForms application, you should make the handling of the callback independent from the rest of the application by using Ian's suggestion plus delegating the work to be done on the UI thread if needed. For example, if the server wants to notify the client of something, such as change the text of a label, you could do the following:

[CallbackBehavior(UseSynchronizationContext = false)]
internal class ServiceCallback : IServiceCallback
{
    ChangeMainFormLabel(string text)
    {
        frmMain.Instance.BeginInvoke(new Action()(() => frmMain.Instance.lblSomething.Text = text));
    }
}

(Instance is a static property that returns the single instance of frmMain and lblSomething is some Label that the server would like to change.) This method will return immediately and free the server from waiting for the client's UI, and the UI will be updated as soon as it's free to do so. And best of all, no deadlocks since no one is waiting for anyone.

Solution 3

http://www.codeproject.com/KB/WCF/WCF_Duplex_UI_Threads.aspx