1

There are a number of posts on stackoverflow that deal with WCF and large files but the general recommendation is to use streaming. This doesn't seem like a very interoperable solution.

How do you deal with large files in WCF and still maintain interoperability?

Joachim Sauer
  • 302,674
  • 57
  • 556
  • 614
Fireworks
  • 135
  • 3
  • 14

1 Answers1

0

Honestly the reason why streaming is such a popular solution is that it works well. The normal way that .net handles WS-I style requests is horrifically ineffecient with large files. It's not meant to transmit large files and if you really try to do it then you'll find it hard to scale up to any significant traffic volume.

The best answer is to avoid it. If you need to, add a service request that can "set up" a file transfer over your service, then have a normal HTTP request using a cookie to actually get the file.

If you really must send the file over a WS-I service, all you can do is enable MTOM and hope that you don't get enough requests at once to run the server out of RAM handling those really big XML messages.

Tridus
  • 5,021
  • 1
  • 19
  • 19
  • Can you explain "The best answer is to avoid it. If you need to, add a service request that can "set up" a file transfer over your service, then have a normal HTTP request using a cookie to actually get the file." Also, do you have any references so I can read up? – Fireworks Apr 05 '11 at 13:50
  • That's referring to if you have to do any work before the file transfer, you can make a service call that does that stuff and gets everything ready so when the client next tries to do the file transfer, the file is "ready" for them. If all you're doing is just sending big files without much extra work, it isn't necessary. I had t do it in an internal project for uploading large files. The user calls a normal service that creates the file record & entries, and checks permissions. If approved it sends back a "token" value (over SSL of course). – Tridus Apr 05 '11 at 13:55
  • (continued) The client then streams the file using the token as part of the request, so the server knows who it is. Had to do that because WCF streaming doesn't support authentication. I don't know exactly what you're trying to do, so you might not have to worry about that. (And no good references come to mind, sorry. I had to figure a lot of this out on my own. :) ) – Tridus Apr 05 '11 at 13:55
  • In short, I get an XML payload, parse it to submit data to RDBMS, update XML ID's based on the update/inserts that occured, and then make the updated XML available for pickup to another application which will commit all of the XML to another RDBMS. There is also a very strong possibility that this needs to be called by an Adobe Livecycle ESB (Jboss based but abstracted to make it easier), hence my need for WS-I. – Fireworks Apr 05 '11 at 14:38
  • That's pretty complicated. How large are these payloads? Unless they're absolutely huge it sounds like it'll be more trouble then its worth to try and do something nonstandard, so you're probably best just to treat them like normal requests. – Tridus Apr 05 '11 at 17:10
  • The payload is going to be from 5-10MB. Do you mean non standard as in streaming, which will break WS-I compatibility? – Fireworks Apr 06 '11 at 13:50
  • Yeah. But for 5-10MB sizes you're probably small enough to not worry about it. I transfer those a fair bit and unless you get under really heavy load it works alright. Just don't try to do any 200MB payloads. :) – Tridus Apr 06 '11 at 14:02