dotnet web services: MTOM vs HttpWebRequest for file upload -- dotnet web services

You're in the

dotnet web services

group:

MTOM vs HttpWebRequest for file upload

MTOM vs HttpWebRequest for file upload

russell.lane
10/23/2006 5:59:30 PM

dotnet web services:

I've been looking at both MTOM and simple HTTP POST or PUT for file uploads.
Some relevant details:

... We want to support programmatic file uploads from Winform apps.
... The files are large binaries, large enough that we would need to increase
the maxRequestLength value.
... We don't need the other WS-* features that come with WSE.
... Currently a pure intranet environment. We may extend outside the
firewall in the mid-term future, but it's unclear if file uploads will be
part of that.

Given the above, what are the pros and cons of each approach?

Many thanks -

RE: MTOM vs HttpWebRequest for file upload

stcheng NO[at]SPAM online.microsoft.com
10/24/2006 12:00:00 AM

Hello Russell,

As for the file uploading from your client winform application to the
server service, do you need to do additional authentication against the
client before upload or at each file uploading?

Regardless of any other requirement, from performance perspective, use HTTP
POST to upload file will be more efficient because the file content is
directly transfered as binary content in the http post request. While
using WSE MTOM, it still use some particular encoding schema to convert the
file content thus it will add some additional overhead. However, comparing
to directly transfer byte[] in webservice method, using MTOM will be much
more efficient.

You can consider which approach to use according to your scenario. If there
is any other questions on this, please feel free to post here.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

Re: MTOM vs HttpWebRequest for file upload

russell.lane
10/27/2006 8:30:08 AM

Steven -

Many thanks for this reply, and for your follow-up to me.

We are authenticating the client to the service layer using integrated
Windows authentication. This is primarily for tracking who is doing what,
i.e., auditing, and less for security per se. We have other controls on who
can run the app itself, so the back end trusts the client to not permit
illegal uploads. If you can get to the service at all through the app, the
service assumes that you are a legitimate user.

The upload service, via its app pool identity, owns the permission to read
and write to the backing filesystem, the user does not.

As it turns out, I also overestimated the size of the files. They are
binary *.wav files ranging in size from the low K's to hundreds of K's of
bytes.

From your comments so far my intuition is that HTTP POST will be the better
choice. Does that seem correct?

Many thanks, again, for your comments, they were very helpful.

Best -

R

[quoted text, click to view]

Re: MTOM vs HttpWebRequest for file upload

stcheng NO[at]SPAM online.microsoft.com
10/27/2006 12:47:04 PM

Thanks for your followup Russell,

Sure. I think use http post directly will be the best choice for you here
and you do not need to use webservice at all since it will add additional
XML serizalization overhead.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

Re: MTOM vs HttpWebRequest for file upload

gw1128
10/27/2006 4:26:01 PM

Hi,

I have a similar problem. Thank you for your response.

It seems that these approaches have the same problem - the entire content of
file needs to be loaded in memory on the client before transmitted, and the
entire content of the file needs to be loaded in memory on the server before
anything can be done with it.

Can you recommend an approach which allows streaming or chunking of the
upload? I have seen sample code that attempt to do this with web-methods and
the IXmlSerializable interface, but I can't make them work for upload.

I will post here if I have something working!

Thanx!

[quoted text, click to view]

Re: MTOM vs HttpWebRequest for file upload

stcheng NO[at]SPAM online.microsoft.com
10/30/2006 2:04:01 AM

Hi Gw,

Thanks for the input.

Yes, you're right, both the two solutions will load the full binary content
into memory before send or receive since both HttpWebRequest or MTOM WSE
are encapsulated component which make use of the default behavior of HTTP.
For your scenario, if you want a streaming or chunkced solution, you may
need to consider use socket programming directly and handle the
client-server's network transfering.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

Re: MTOM vs HttpWebRequest for file upload

Chris Mullins
10/30/2006 5:01:23 PM

One of the weakest points of MTOM (to me) is that it loads the entire file
into memory on the web server. This, in essence, makes it unusable for large
files, or over unstable connections.

I was trying to force MTOM to work with very large files (1GB+), and ended
up having to use an FTP type of solution instead. It seems strange to me
that, at the protocol level, they couldn't work around this by building in
chunking or having a standard procol on top of MTOM.

--
Chris Mullins, MCSD.NET, MCPD:Enterprise
http://www.coversant.net/blogs/cmullins

[quoted text, click to view]

Re: MTOM vs HttpWebRequest for file upload

Pavel
12/4/2006 3:29:00 PM

Hello Steven,

is there any solution to bypass the main memory while sending data to a
server?
In my case i have to write a SharePoint client, which should be able to
upload data bypassing the RAM because there should be no file size limitation.
I'm not sure if I should go down to the socket layer, due to my lack of
experiance with the socket security behavior and about the security polices
on the server. Actually all I know about the server is that it is running
SharePoint.

Is there anyway to transmit data bypassing the RAM with the WebClient /
WebRequest classes?!

Thank You in advance!

I badly need a solution!

Many thanks,

Pavel

[quoted text, click to view]

Got something to say? Click here to post a reply to this thread.

Don't see what you're looking for? Try a search.

View other messages in the dotnet web services group.

home · blog · groups

Questions? Comments? Contact the dn