In any case your post put me on the right path where I found that I had my service time-outs incorrectly configured. I was also unaware of the full implications of the new multiple message per poll. I also had concurrency issues in my logger causing some of the channel failures that I was complaining about in my post above. (Which means what I said there was wrong) And the biggest mistake I made, which you highlighted, is I never really coded the service to handle random DCs from either side. Once I started thinking about how the system would handle those, it forced me to design my approach better which eventually led me to (what I believe is) a working version.

My usage scenario is slightly different that yours though. I need clients to subscribe to each other, where yours only caters for the server to subscribe to a client. Ugly hacks were needed in the callbackmanager to make this work, but in essence the key to making it work was your original findings and implementation above which I am very grateful for. Thanks for that.

Of course, you should always be prepared that if you’re using a long-lived client proxy, there’s always the possibility that your proxy could be faulted at any point, so you should be prepared to recreate it if necessary.

If a client makes a call to the server that causes a duplex call to a dead client, that timeout exception causes the entire service to break. Subsequent calls from the client to the server fail because the client state is faulted. How can I get around this problem?