Is WCF strictly an asynchonous comms platform?

Question

Since I last had to do any comms/network programming, the field has exploded with acronyms. In fact, networking almost feels like it is now described by a whole new language.

The very name "Windows Communication Foundation" suggests it should be all things to all people... but I need to be sure I can program up some synchronous real-time* comms on a dedicated gigabit ethernet network. Can someone confirm that WCF is not a starter for this task... or if it is, which of the many confusing acronyms I should get familiar with?

* By real-time, I mean I need to reduce latencies down to an acceptably low level. For our application, which involves transmitting results of video & audio analyses continuously every few milliseconds, I need to ensure 99% or better of those analyses are presented at the UI within (ideally) 0.5 seconds so that the user has time to respond before the originating network node deletes data out of its buffer to make way for subsequent analyses.

Answer 1

For real time programming needs the Microsoft solution is SignalR. Other options would be to use web sockets which are new in HTML 5 or good old fashioned socket programming. It sounds like you need to do video/audio streaming, in which case there are other libraries dedicated to that which could be more helpful. WCF is XML/JSON over HTTP which does have an overhead cost if you are planning to send lots of continuous data, it would be better to use a technology that works at a lower level to reduce that overhead.

Answer 2

Basically, WCF is intended for asynchronous communications, and I won't be surprised to learn that at a certain level, everything it does it asynchronous.

This being said, you can do blocking operations with WCF, so yes, synchronous real-time communications can use WCF under the hood, given that WCF provides you some interesting aspects such as the fact that it can guarantee that messages will be delivered, and will be in the order they were sent.

The ability to use blocking operations includes even the WCF's web sockets, by the way.

Why would you block the thread until you receive a reply from a distant machine is a different subject. Think twice, since it you probably don't want to freeze your entire application definitively if the network goes down.

One of the uses I've found for blocking operations is to have a proxy class which communicates through WCF under the hood. In this case, when you access someObject.Products, you don't have to know that products are loaded through WCF. It's a powerful abstraction, but also a leaky one: if the distant machine goes down during the operation, you certainly have to know what happens when you call Products property.