What Do You Need to Send Data?

There are three transports that I tend to refer to as the "standard" transports of WCF: HTTP, TCP/IP, and named pipes. These transports receive a lot more attention than the other transports we've written, MSMQ and PeerChannel, although it's tough to get excited about named pipes.

Ignoring WCF for a moment, almost everyone that writes web applications uses HTTP as their transport. Almost everyone that doesn't use HTTP uses TCP/IP instead. There's a very long tail of other formats, ranging from tens of users to tens of thousands of users.

Now, let's stop ignoring WCF and start ignoring existing web applications. If you were writing an application that used any network protocol you wanted, what would you want to have support for? Well, it depends on what purpose you're building the application for. Let's say I want to write an application that streams some content to clients. Here's my list of five protocols I'd think about:

  1. BitTorrent
  2. Some instant messaging protocol
  3. TCP/IP
  4. Some cloud data storage service protocol
  5. UDP (with multicasting)

Most of these protocols have good reach and connectivity. There's either a naturally low bar for establishing connections or someone else has a vested interest in providing a low bar. Very few of these protocols has a natural programming model that makes writing applications fun and easy.  HTTP doesn't even make the top five.

Assuming that we can solve the programming model problem, which protocols are the right ones to put in the toolbox?

Comments (3)

  1. Why not HTTP?

    My first thought was agreement – after all, HTTP was born to be a simple Hypertext Transfer Protocol, and not the be-all and end-all protocol it has ballooned to be. But then I thought of the reasons HTTP has become such a standard protocol, and they all have to do with reach.

    The reason Web Services are traditionally (can we say ‘traditionally’ for something that has existed for scant few years?) reached on port 80 because that’s a port you’re almost guaranteed to have open. Whether it’s the client, server or ISP in the middle, port 80 is usually kept free of interruptions – the Web drives the Internet.

    You could say "Just use TCP on port 80" – there’s nothing magical about port 80 and HTTP that ties them together. But that would mean squishing together all your endpoints onto port 80, and also having human clients try to go there for their webpages as well.

    HTTP servers like Apache or IIS are already well suited for multiplexing many requests for different endpoints, so why not use the existing HTTP servers for it?

    I haven’t read much about WAS in Vista yet, but if I understood it correctly, it will allow me to host any protocol on IIS. This might be the answer to my question – use the power of the IIS platform without being tied to HTTP.

    Please do correct me if I’m spewing complete nonsense. Just my understanding of things.

  2. "If you were writing an application that used any network protocol you wanted, what would you want to have support for?"

    1. Reliable Messaging

    2. Pub/Sub

    I’d also like a nice API to express this. See http://udidahan.weblogs.us/archives/036658.html for a more thorough write-up.

  3. PubSub is an interesting one because it doesn’t necessarily represent a specific network protocol.  The two protocols I’ve heard a lot for this scenario are Tibco integration and UDP multicast.

Skip to main content