Question

In this article, (toward the end in the 'Windows Communication Foundation' section) the author suggests that a one way transmission in WCF is essentially UDP. Is this correct? Should I assume based off the content of this article that marking my service ops as 'one way' means I'm using UDP?

Furthermore, he's suggesting using UDP in conjunction with WS-ReliableMessaging to negate the need to write those aspects of the transport protocol yourself... Ok, but if I want to leverage the performance benefits of UDP in a situation that warrants it, I should, as per this article's suggestion, just use 'one way' and WS-ReliableMessaging and I'm good to go!? Sounds a little far fetched to me...

So what's the deal here? What are the caveats of what this article is suggesting?

Was it helpful?

Solution

No, you are misunderstanding the article. The article is saying two different things:

  1. WCF one way operations are somewhat analogous to UDP datagrams.

  2. WS-ReliableMessaging could be implemented on top of UDP if desired.

Even one way operations require acknowledgements, retransmissions, and the like to make them reliable.

OTHER TIPS

From the article you mentioned:

WCF exposes multiple network protocols (most notably TCP) and is extensible to other network protocols by writing a WCF transport channel. WCF supports UDP through its extensibility model, and the code for a basic UDP channel will be provided as a code sample in the WinFX® SDK.

They're using a UDP transport in their setup so in their situation, yes. If you have a service using a TCP-based transport then one way communication would not be UDP.

And further down in the article:

The WCF-based implementation of UDP is a one-way channel

So they are really only talking about how UDP in WCF is implemented, and not WCF in general.

WS-ReliableMessaging relies on the receiver sending acknowledgments ('acks') back to the sender. Otherwise the sender would have no way of knowing whether the message needed resending. In TCP, this is built into the transport protocol (that's one of the differences between TCP and UDP).

In UDP, you are forgoing the 'overhead' of TCP, but if you need reliable messaging your server is still sending something back to the client.

Actually, if you read that section of the article a bit more closely, you'll see that there's a fair bit more to it than just using one-way messaging and WS-ReliableMessaging. You also have to add a UDP binding element (.e.g, bindingElements.Add(new UdpTransportBindingElement());), and other similar things. If you don't add those things, you're still gonna be using TCP.

As an additional note, my suspicion is that you'd need to indulge yourself in some pretty sophisticated benchmarks before you could conclude that UDP is actually going to have higher performance than TCP for web services. I haven't done these tests myself, but my suspicion is that by the time your soap.udp:// binding gets done adding all the reliable messaging bits and what-not to your service, you're going to have pretty much all the same overhead as TCP. I suspect that the reason UDP is available as a transport binding is not because of any superior performance characteristics, but to provide an alternative for the corner case of scenarios where TCP (for whatever bizarre environmental reason) isn't available.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top