Web services and large content in .NET 2.0

Yasser on streaming ASMX with Whidbey

Service Station — Thu, 11 Nov 2004 01:36:00 GMT

re: Web services and large content in .NET 2.0

Laurent Kempé — Wed, 10 Nov 2004 22:37:00 GMT

Using attachment (DIME) you don't have any inflation.

re: Web services and large content in .NET 2.0

Yasser Sohoud — Wed, 10 Nov 2004 22:49:00 GMT

Sure, using DIME you get no inflation compared to Base64 encoding where you get 33% inflation. The point is, if your motivation for using DIME is to decrease bandwidth util, you can achieve that (and often even less bandwidth util) by Base64 encoding + compression. What you gain is wider interop because Base64 encoding is supported by every SOAP stack out there. Also, depending on the DIME implementation you use, you may be forced to buffer whereas with IXmlSerializable you can stream.

Back to life again

Girish Bharadwaj — Thu, 11 Nov 2004 06:34:00 GMT

re: Web services and large content in .NET 2.0

Simon Fell — Thu, 11 Nov 2004 04:24:00 GMT

What about going the other way, does ASP.NET still do brain dead buffering of the request ? (see http://www.pocketsoap.com/weblog/2003/12/1392.html)

re: Web services and large content in .NET 2.0

Yasser Sohoud — Thu, 11 Nov 2004 05:16:00 GMT

Thanks for the question Simon. I asked my friend Erik Olson on the ASP.NET team and here's what he said:

ASP.NET has a threshold after which it's buffered onto disk and gets chunked in automagically from the request stream. The threshold is 512 KB. This is adjustable in the <httpRuntime/> config section and can be scoped to the URL using <location>. See requestLengthDiskThreshold.

re: Web services and large content in .NET 2.0

JF — Thu, 11 Nov 2004 18:36:00 GMT

When you say "In .NET 2.0, the client will automatically tell the server that it accepts gzip compression and it will automatically decompress replies." are you referring to the MTOM stuff?

Streaming via Web Service ...

Il Blog di Paolo Pialorsi — Thu, 11 Nov 2004 21:49:00 GMT

re: Web services and large content in .NET 2.0

Yasser Sohoud — Fri, 12 Nov 2004 02:14:00 GMT

No this is not MTOM. This is using the HTTP ACCEPT header to tell the server it can send gzip compressed content if it wants to.

re: Web services and large content in .NET 2.0

smartguy — Fri, 12 Nov 2004 17:36:00 GMT

So, this doesn't appear to compliment MTOM, it appears to compete with it. When should you choose MTOM over this method?

Also, the encoding and then zipping of the data seems like it would be a bit slow. I'd like to get away from Base64 entirely.

Serialization using Limited Resources

Emitter — Sun, 10 Apr 2005 22:33:20 GMT

netzooid » Streaming MTOM on a WSE client?

netzooid » Streaming MTOM on a WSE client? — Tue, 18 Jul 2006 19:46:58 GMT

PingBack from http://netzooid.com/blog/2006/07/18/streaming-mtom-on-a-wse-client/

Yasser Shohoud : Web services and large content in .NET 2.0

Audio — Sat, 24 May 2008 02:48:13 GMT

There are a couple of features in .NET 2.0 (Whidbey) that help solve the problems of dealing with large data. The two main issues with sending large data in Web service messages are: 1. working set (memory) due to buffering by the serialization engin

Enviar ficheros con servicios web | hilpers

Enviar ficheros con servicios web | hilpers — Tue, 20 Jan 2009 22:42:47 GMT

PingBack from http://www.hilpers-esp.com/484609-enviar-ficheros-con-servicios-web