dasBlonde - Callbacks, ConcurrencyMode and Windows Clients

Thursday, August 16, 2007

« System Setup for .NET 3.0 and .NET 3.5 | Main | A comical story about cell phone depende... »

Callbacks, ConcurrencyMode and Windows Clients

Today I completed a webcast as part of a 15 part series - today's subject concurrency, throughput and throttling. I received some questions about callback and Windows client applications that I thought I would elaborate on here. In fact, I went a little overboard and created a bunch of samples that would illustrate the behavior of services and clients when you have a Windows client, a service with a callback contract (thus, two-way communication) and various WCF settings at the client and service that relate to concurrency, multithreading, synchronization with the UI thread, and so on.

The following table summarizes various settings at the client, service and callback and the resulting behavior at runtime. Here's the breakdown for each column:

Callback Sync Context - refers to the UseSynchronizationContext setting for the CallbackBehaviorAttribute on the client callback object.
Callback Concurrency Mode - refers to the ConcurrencyMode setting for the CallbackBehaviorAttribute on the client callback object.
Service Operation - Indicates if the service contract operations are one-way or two-way.
Callback Operation - Indicates if the callback contract operations are one-way or two-way.
Service Concurrency Mode - refers to the ConcurrencyMode setting for the ServiceBehaviorAttribute on the service type.
Resulting Behavior - when the corresponding sample is run, what happens?

I have also uploaded sample code for each of these scenarios, numbered in order of table row description below. Get the code here.

Callback Sync Context	Callback Concurrency Mode	Service Operation	Callback Operation	Service Concurrency Mode	Resulting Behavior
True/ False	Single/ Reentrant/ Multiple	One-way/ Two-way	Two-way	Single	These are defaults. InvalidOperationException at the service. Operation would deadlock calling the client application since the callback is two-way and reentrancy isn’t possible.
True	Single/ Reentrant/ Multiple	Two-way	Two-way	Reentrant/ Multiple	Service able to call client, but client is blocked because of outgoing call.
False	Single/ Reentrant/ Multiple	Two-way	Two-way	Reentrant/ Multiple	Service able to call client, client callback object is not blocked. If client callback object tries to communicate with UI thread (i.e., setting properties of controls) it will block.
False	Single	One-way	Two-way	Reentrant/ Multiple	Service able to call client, client callback object is not blocked. Client callback object can communicate with UI thread using Invoke() from callback thread. Client can issue multiple calls to service but only one callback can be processed at a time.
False	Multiple	One-way	Two-way	Reentrant/ Multiple	Service able to call client, client callback object is not blocked. Client callback object can communicate with UI thread using Invoke() from callback thread. Client can issue multiple calls and multiple callbacks can be processed at a time.
False	Multiple	One-way	One-way	Single/ Reentrant/ Multiple	Service able to call client, client callback object is not blocked. Client callback object can communicate with UI thread using Invoke() from callback thread. Client can issue multiple calls and multiple callbacks can be processed at a time.
False	Multiple	Two-way/ Multi-threaded Client	Two-way	Reentrant/ Multiple	Service able to call client, client callback object is not blocked. Client callback object can communicate with UI thread using Invoke() from callback thread. Multiple calls from client can be processed at the service, and multiple callbacks can be processed at the client.
False	Multiple	Two-way/ Multi-threaded Client	Two-way	Reentrant/ Multiple	Service able to call client, client callback object is not blocked. Client callback can communicate with UI thread using Invoke() from callback thread. Multiple calls from client can be processed at the service, and multiple callbacks can be processed at the client.

Here is a summary of considerations.

Contract design:
- Make callback operations one-way. If this isn’t possible, make the service reentrant. Prefer one-way callbacks since most likely the service doesn’t care about responses.
- If service operations will notify clients with a callback, make them one-way as well.
Exception handling:

Remember that uncaught exceptions invalidate service, client and callback channels where sessions are involved. Two-way communication can only happen over duplex, thus there is a transport session (TCP, named pipes) or HTTP session (using reliable sessions over WSDualHttpBinding).
Throw faults for known exceptions unless you want the client to be forced to recreate the proxy and start a new session. That includes clients – who should not allow exceptions to flow back to the service during a callback unless they intend to destroy the session.
To avoid destroying the session: if callback operations are one-way, swallow the exception after handling it at the client; if callback operations are two-way, report a fault to the service in response.

Windows client issues:
- Always disable synchronization with the UI thread for callback objects, by setting UseSynchronizationContext to false in the CallbackBehaviorAttribute.
- Multithreaded clients should invoke services on another thread (can use asynchronous proxies) when callbacks or long running service operations are involved. This prevents UI thread from blocking during call, allows callbacks to communicate freely with UI.
- Use Invoke() to communicate with UI from the callback thread.
- Don’t forget to protect other client state if the callback object supports multiple concurrent callbacks. That means the ConcurrencyMode setting is Multiple in the CallbackBehaviorAttribute.

Technorati Tags: WCF, Callbacks, Synchronization

8/16/2007 1:20 AM .NET 3.0 | WCF | Comments [5] | View reactions | Trackback

Monday, October 15, 2007 8:06:19 AM (GMT Standard Time, UTC+00:00)

hi

I got some strange exception:
ProtocolException: The one-way operation returned a fault message. The reason for the fault was 'xyz'.

xyz is my text.
i used one-way method that throws some fault, in wsHttpBinding.

what is going on here?

ty.

anonymous

Monday, January 07, 2008 10:12:27 AM (GMT Standard Time, UTC+00:00)

Hi!

I've created a WCF Service using netTcpBinding which exposes a Callback
Contract so clients can get notified about specific events.

It actually worked when the client was a Console Client but as soon as i use
this callback-stuff from within a WinForms client the callback just doesn't
execute and i get a TimeoutException after a while.
Normal service calls where no callback-notifications are involved work fine
from the WinForms-Client from both clients.

I tried your hint disabling synchronization by applying "UseSynchronizationContext=false" but it didn't help eather.

I'm running Windows XP SP2 and using Visual Studio 2005 with WCF Extensions.

Any help would be greatly appreciated.

Thanks a lot in advance!

Markus

Appendix:

serverside app.config
--------------------------------------------------------------------------------------
<?xml version="1.0" encoding="utf-8" ?>

<configuration>

<system.serviceModel>

<bindings>

<netTcpBinding>

<binding name="NetTcpBinding_ITestService" closeTimeout="00:01:00"

openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"

transactionFlow="false" transferMode="Buffered"
transactionProtocol="OleTransactions"

hostNameComparisonMode="StrongWildcard" listenBacklog="10"

maxBufferPoolSize="524288" maxBufferSize="65536" maxConnections="10"

maxReceivedMessageSize="65536">

<readerQuotas maxDepth="32" maxStringContentLength="8192"
maxArrayLength="16384"

maxBytesPerRead="4096" maxNameTableCharCount="16384" />

<reliableSession ordered="true" inactivityTimeout="00:10:00"

enabled="false" />

<security mode="Transport">

<transport clientCredentialType="Windows" protectionLevel="EncryptAndSign"
/>

<message clientCredentialType="Windows" />

</security>

</binding>

</netTcpBinding>

</bindings>

<client>

<endpoint address="net.tcp://localhost:11111/TestCallbackService"

binding="netTcpBinding" bindingConfiguration="NetTcpBinding_ITestService"

contract="WinFormsClient.localhost.ITestService"
name="NetTcpBinding_ITestService">

<identity>

<userPrincipalName value=user@domain.at />

</identity>

</endpoint>

</client>

</system.serviceModel>

</configuration>

client app.config (in the console version the same as in the winforms
version):
--------------------------------------------------------------------------------------

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

<system.serviceModel>

<bindings>

<netTcpBinding>

<binding name="NetTcpBinding_ITestService" closeTimeout="00:01:00"

openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"

transactionFlow="false" transferMode="Buffered"
transactionProtocol="OleTransactions"

hostNameComparisonMode="StrongWildcard" listenBacklog="10"

maxBufferPoolSize="524288" maxBufferSize="65536" maxConnections="10"

maxReceivedMessageSize="65536">

<readerQuotas maxDepth="32" maxStringContentLength="8192"
maxArrayLength="16384"

maxBytesPerRead="4096" maxNameTableCharCount="16384" />

<reliableSession ordered="true" inactivityTimeout="00:10:00"

enabled="false" />

<security mode="Transport">

<transport clientCredentialType="Windows" protectionLevel="EncryptAndSign"
/>

<message clientCredentialType="Windows" />

</security>

</binding>

</netTcpBinding>

</bindings>

<client>

<endpoint address="net.tcp://localhost:11111/TestCallbackService"

binding="netTcpBinding" bindingConfiguration="NetTcpBinding_ITestService"

contract="ConsoleClient.localhost.ITestService"
name="NetTcpBinding_ITestService">

<identity>

<userPrincipalName value=user@domain.at />

</identity>

</endpoint>

</client>

</system.serviceModel>

</configuration>

Code for WCF-Service-Library

--------------------------------------------------------------------------------------

public interface ICallbackInterface

{

[OperationContract(IsOneWay=true)]

void OnCallback(string message);

}

[ServiceContract(CallbackContract=typeof(ICallbackInterface))]

public interface ITestService

{

[OperationContract]

string DoIt(string name);

}

[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single)]

public class TestService : ITestService

{

#region ITestService Members

public string DoIt(string name)

{

string ret = "Hello " + name;

ICallbackInterface callback =
OperationContext.Current.GetCallbackChannel<ICallbackInterface>();

if (callback != null)

{

if(((ICommunicationObject)callback).State == CommunicationState.Opened)

callback.OnCallback("Message received from " + name);

}

return ret;

}

#endregion

}

Markus

Monday, January 07, 2008 10:13:20 AM (GMT Standard Time, UTC+00:00)

Markus

Monday, January 07, 2008 10:28:10 AM (GMT Standard Time, UTC+00:00)

ok so sorry for spamming your article :)

I missunderstood your hint and applied the UseSynchronizationContext-stuff at the serverside.

Now after applying it on the client-side class which implements the callback-interface it works as expected.

Best Wishes

Markus

Markus

Monday, February 04, 2008 6:50:36 PM (GMT Standard Time, UTC+00:00)

A lot of nice info in regard to desktop WCF applications, but which options work with the compact framework on mobile devices? That's a very opaque topic, because nearly all books and tutorials cover only WCF for desktop applications.

Anyway, best regards.

Rüdi

Name
E-mail	(will show your gravatar icon)
Home page

	Remember Me
Comment (HTML not allowed)