What is the trade of between OneWay and Async calls for broadcasting events to clients? (WCF)

I am writing a WCF (netTcpBinding planned at present) client/server application that has to support a “handful” of clients including sending events to the clients.

I do not wish the server to block while the clients process the events.

Logically I cannot see mat开发者_Python百科ch difference between marking the callback methods as “OneWay” or calling them with "being_MethodName(..)"

So what are the pros and cons of each technique?

I am finding from my readings that the error handling of OneWay messages is complex and you can unexpectedly get the channel going bad... E.g the are not fire and forget!

From an abstract contract definition POV, if the server does not require any response from the client, then there's no reason to write it into the "contract" with the client.

At a more pragmatic level, you'll be incurring bandwidth costs and processing overhead of having to send and receive the extraneous message.

One other major concern I would have is whether the client is sending messages to the server on the same TCP channel that the server is sending notifications to the client. If that is the case, you definitely want to use OneWay messages so as to avoid a possible deadlock (see my comment in this thread: WCF duplex channel gets closed when using callbacks).

Also, to be clear, one-way and async are not exclusive -- you can and likely should send your one-way messages using the async pattern. It is possible for a one-way message send to block, for example if the network buffer is full, so using async will ensure that your server event notification thread stays unblocked.