Is it possible to integrate UDP file transfer into a .NET web application?

Question

Background

I have recently been tasked with designing a rebuild of an existing .NET web application that currently uses a third-party company to handle large file transfers (as big as 50Gb).

Currently, the .NET app depends on a .JAR (Java Applet) provided by this third-party which is called up inside of an iFrame and exposes the appropriate file-system interaction for selecting entire directories for upload and so forth.

I realize that so far all of this is possible using some combination of .NET networking classes (ftp) and Flash or Silverlight for client access.

I have been told that the reason that the third-party plugin is so special is that it uses UDP protocol so that if an upload or download is interrupted, it can be resumed later right where it left off. I have also been told that the third-party tool suite allows the IT folks to throttle bandwith (I don't even know what that means) and do a couple of other cool things.

Question

Assuming that we will use the latest version of C# and and the .NET framework (4.0), is it reasonably possible to replicate this UDP-based behavior? By reasonable, I mean could it be accomplished in less than, say, 240 dev hours.

Please note that the rebuilt app will ideally use all Microsoft technologies (including Silverlight for client access) and will run on Azure.

Answer 1

Yes, .Net fully supports UDP. You can create a UDP Socket and then wrap it in a NetworkStream.

I have been told that the reason that the third-party plugin is so special is that it uses UDP protocol so that if an upload or download is interrupted, it can be resumed later right where it left off.

That doesn't make any sense. For example HTTP, supports this too. And since it seems they are using some custom protocol over UDP, a custom protocol over, say, TCP could achieve the same effect too. There is nothing special about UDP in this regard.

I have also been told that the third-party tool suite allows the IT folks to […] do a couple of other cool things.

This really sounds like it's some custom protocol. We can't tell you how hard that will be, because we don't know anything about it – i.e. how complex it is, how well documented it is, etc.

Answer 2

Disclaimer: I work for a company which produces UDP file transfer software, probably a competitor of the maker of the UDP plug-in you talk about.

Yes it is possible to build a UDP file transfer application using C#, but no it is not possible to do it well within 240 developer hours.

UDP/IP involves placing nearly raw datagrams onto the network wire. Things you take for granted with TCP/IP, like making sure the datagram gets there, avoiding duplicates, keeping messages in order, making sure you don't send data too fast or too slow, all have to be done by you.

UDP based file transfer solutions are becoming very popular because of the opportunity to develop all of the transport functionality from scratch, thereby avoiding a lot of the problems inherent in TCP. UDP is simply a blank slate upon which one can create a better (or worse) solution.

Throttling simply means making sure that the data rate does not exceed some set value. That's actually pretty easy by itself. All UDP transport solutions that I know of will do that.

Making sure that the network can actually handle going that fast is much harder and is a key differentiator amongst the various UDP solutions out there. Cramming too much data into a network path, even for a moment, can create huge disruptions. Setting a throttle limit is the simplest way to avoid that, but it only works if you know in advance what the network capacity happens to be.