What’s new in WCF 4.5? UDP transport support

February 15, 2012

11 comments

This is the tenth post in the WCF 4.5 series. I’ve started this series of posts 4 months ago when .NET 4.5 developer preview was announced; The Beta/RC/RTM version is still to come, but hopefully it will be available soon, and you will be able to use the new WCF 4.5 features in your projects.


Until now, I’ve shown new features in configuration easiness and hosting improvements. In this post and the next one I will cover new transport features, starting with the support for the UDP transport.


Previous posts:


1. What’s new in WCF 4.5? let’s start with WCF configuration


2. What’s new in WCF 4.5? a single WSDL file


3. What’s new in WCF 4.5? Configuration tooltips and intellisense in config files


4. What’s new in WCF 4.5? Configuration validations


5. What’s new in WCF 4.5? Multiple authentication support on a single endpoint in IIS


6. What’s new in WCF 4.5? Automatic HTTPS endpoint for IIS


7. What’s new in WCF 4.5? BasicHttpsBinding


8. What’s new in WCF 4.5? Changed default for ASP.NET compatibility mode


9. What’s new in WCF 4.5? Improved streaming in IIS hosting


I’ve been teaching WCF for several years now, and almost every time I explain to people about the different types of bindings and supported transports someone asks me if there is a built-in support for a UDP transport. Until now my answer was “It isn’t supported out-of-the-box, but there is a UDP transport sample in the WCF/WF samples”. From now on my new answer is “In WCF 4/3.5 there is a sample implementation, but it is now out-of-the-box in WCF 4.5”.


You can get some basic info about the binding in the System-Provided Bindings page on MSDN (make sure you look at the 4.5 version), unfortunately there is no documentation on the UdpBinding type yet, but hopefully MS will create it by the time WCF 4.5 is released.


Declaring an endpoint that uses UDP is quite simple:

<endpoint address=”soap.udp://localhost:8080/” binding=”udpBinding” contract=”UdpHost.IService” />

Some facts about the new UDP binding:



  1. The address scheme for this binding is soap.udp://

  2. The binding is supported only by .NET (since it does uses text encoding for the SOAP messages, it can be considered interoperable, although currently no other SOAP-based services technology support UDP)

  3. Security is not supported (neither transport or message)

  4. Sessions, transactions, streaming, and duplex are not supported (I was hoping for a duplex UDP using one-way messages)

  5. Supported encoding is text

  6. The binding can be used in code by adding a reference to the System.ServiceModel.Channels assembly

  7. The binding is not supported in IIS/WAS, since there is still no UDP shared listener for WAS

  8. In the case of One-Way messages, this is a true one-way unidirectional call – the client won’t throw an exception if the service is unavailable

  9. If you specify a multicast address in the endpoint, such as 224.0.0.1 or 239.255.255.255 (the later is used by UDP discovery endpoints), you can create multiple listeners on the same address+protocol even from different machines – one client can send a single message that will be received by multiple listeners – this can be a great way to synchronize server state, do pub-sub (notification) calls etc…

Using a multicast listening address is also quite simple:

<endpoint address=”soap.udp://239.255.255.255:8083/” binding=”udpBinding” contract=”UdpHost.IService” />

As for performance, I’ve create a simple client which sends 5000 messages using request-response and one-way (simple and multicast), with HTTP (basicHttp), TCP, and UDP bindings. For the purpose of the test I’ve removed all security settings from the NetTcp binding. The result is shown below:


Calling 5000 iterations one way using UDP
One-way using UDP took 0 seconds, average is 0.1792ms


Calling 5000 iterations one way using HTTP
One-way using HTTP took 6 seconds, average is 1.3ms


Calling 5000 iterations one way using TCP
One-way using TCP took 2 seconds, average is 0.5876ms


Calling 5000 iterations one way using UDP Multicast
One-way using UDP Multicast took 3 seconds, average is 0.736ms


Calling 5000 iterations of request-response using UDP
Request-response using UDP took 7 seconds, average is 1.4738ms


Calling 5000 iterations of request-response using HTTP
Request-response using HTTP took 8 seconds, average is 1.7784ms


Calling 5000 iterations of request-response using TCP
Request-response using TCP took 4 seconds, average is 0.9518ms


Conclusions:



  1. One-way messages are fast when using UDP – about 7 times faster than HTTP, and 3 times faster than TCP. I assume this is because when using UDP we don’t need to wait for the TCP ACK (also used in HTTP).

  2. One-way multicast messages in UDP are slower than direct messages – about 4 times slower

  3. Request-response message in UDP are slower than TCP, but faster than HTTP. I assume the reason for being slower than TCP is that UDP uses two channels to create request-response whereas TCP requires only one channel.

Trying to run the same sample when the server has not been started produces the following results:


Calling 5000 iterations one way using UDP
One-way using UDP took 0 seconds, average is 0.1216ms


Calling 5000 iterations one way using HTTP
One-way using HTTP failed


Calling 5000 iterations one way using TCP
One-way using TCP failed


Calling 5000 iterations one way using UDP Multicast
One-way using UDP Multicast took 1 seconds, average is 0.376ms


Calling 5000 iterations of request-response using UDP
Request-response using UDP failed


Calling 5000 iterations of request-response using HTTP
Request-response using HTTP failed


Calling 5000 iterations of request-response using TCP
Request-response using TCP failed


As you can see, UDP one-way messages are unidirectional!!!


The sample code is available on my SkyDrive.


Add comment
facebook linkedin twitter email

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

11 comments

  1. Mads TokssMarch 6, 2012 ב 4:42 pm

    Hi,

    In practical terms and/or real world cases, where this transport is useful?

    Reply
  2. Ido FlatowMarch 6, 2012 ב 5:11 pm

    UDP is good for two common scenarios – when you don’t require the delivery notice, such as the one you get when working with TCP (the acknowledgment), and when you need efficient multicast messaging that doesn’t require knowing the address of each client.

    In real-life scenarios you can find UDP in sensor gathering systems, video streaming (where you don’t case if some of the frames get lost along the way – so not suitable for video encoders, more for live viewing), simple one-way pub/sub. UDP can also be used sometimes in online games when you send updates all the time, so a lost packet is usually irrelevant a few seconds after the fact

    Reply
  3. DylanJuly 21, 2012 ב 10:23 am

    hey Kitamura-san,Didn’t know you had a tech blog of your own. I just do # service sattus-all, but I like your way better. Btw, I don’t see Centos in your word cloud there we’re gonna have to change that, if we keep corresponding. =) hope all is well,Alex

    Reply
  4. FullerAugust 25, 2012 ב 6:38 am

    I visited several websites except the audio quality for audio
    songs current at this web page is in fact superb.

    Reply
  5. MedlockSeptember 15, 2012 ב 10:41 am

    When someone writes an paragraph he/she maintains the thought of a user
    in his/her mind that how a user can know it. Therefore that’s why this post is amazing. Thanks!

    Reply
  6. PennellDecember 14, 2012 ב 1:46 am

    What’s up, this weekend is good for me, since this time i am reading this great informative paragraph here at my residence.

    Reply
  7. UlmerDecember 20, 2012 ב 8:23 pm

    Thanks for sharing your thoughts on Ido Flatow WCF MOC HPC
    Azure Entity Framework Silvelright. Regards

    Reply
  8. GurleyDecember 22, 2012 ב 12:10 pm

    I could not resist commenting. Well written!

    Reply
  9. OconnorDecember 23, 2012 ב 11:08 pm

    You are so awesome! I don’t suppose I’ve read something like this before.
    So great to find someone with some genuine thoughts on this
    topic. Really.. many thanks for starting this up.

    This website is something that’s needed on the internet, someone with some originality!

    Reply
  10. FortierJanuary 8, 2013 ב 5:43 am

    Your style is really unique in comparison to other folks I have read stuff from.
    I appreciate you for posting when you’ve got the opportunity, Guess I’ll just book
    mark this web site.

    Reply
  11. SpurlockJanuary 9, 2013 ב 4:51 pm

    I think the admin of this site is really working hard for his website, because here every material is quality based material.

    Reply