rickgaribay.net

Space shuttles aren't built for rocket scientists, they're built for astronauts. The goal isn't the ship, its the moon.
posts - 303, comments - 180, trackbacks - 35

My Links

News

Where's Rick?


AgileAlliance deliver:Agile 2019- 4/29
Desert Code Camp, PHX - 10/11
VS Live Austin, TX - 6/3
VS Live SF - 6/17


About Me
Hands on leader, developer, architect specializing in the design and delivery of distributed systems in lean, agile environments with an emphasis in continuous improvement across people, process and technology. Speaker and published author with 18 years' experience leading the delivery of large and/or complex, high-impact distributed solutions in Retail, Intelligent Transportation, and Gaming & Hospitality.

I'm currently a Principal Engineer at Amazon, within the North America Consumer organization leading our global listings strategy that enable bulk and non-bulk listing experiences for our WW Selling Partners via apps, devices and APIs.

Full bio

Note: All postings on this site are my own and don’t necessarily represent the views of my employer.



Check out my publications on Amazon Kindle!





Archives

Post Categories

Published Works

Image Uploads with WCF

I am building a service that uploads images from a client to a UNC share. The service is built with WCF (what else) and I must say it is pretty slick.

To serialize images, you basically convert the bits into a byte array, serialize the array and away you go.The service I am working on takes advantage of the MTOM (Message Transmission Optimization Mechanism) encoding, which significantly improves the perfornance of larger payloads, which are usually common when dealing with images.

MTOM is a good choice when you are working with large binary attachments, regardless of transport protocol. For example, if you are using HTTP, MTOM is an excellent choice for optimizing the handling of binary data. In addition, TCP will also gain substantial improvements from using MTOM for large binary attachments.

One of the things you should know when dealing with larger message sizes, specifically, those that exceed 65K. Attempting to submit an image (message) larger than 65K will result in a 400 Bad Request error at the server.

Once you have a good idea of how large the images are going to be, you will want to adjust the maxReceivedMessageSize property on the binding of choice. The default is 65K which may be too small for most scenarios, even with low res images. Below is an example of a custom binding configuration you can use when using large message uploads:

 <bindings>
    <basicHttpBinding>
     <binding name="basicHttpOptimized" maxReceivedMessageSize="2000000" messageEncoding="Mtom">
      <readerQuotas maxArrayLength="2000000" />
     </binding>
    </basicHttpBinding>
   </bindings>

 Notice the messageEncoding is set to "Mtom", and I've set the maxReceivedMessageSize to 2MB, matching it with the readerQuota. Both are just many of the switches and knobs at your disposal in WCF configuration and is another great example of how WCF is secure by default.

While MTOM does optimize large binary transfers, there is a point of diminishing returns if the binary data is not big enough to really get a boost from MTOM. For example, the payload of a moderate binary upload may be smaller than that of which is MTOM encoded because the MIME notation itself does introduce a swell in message size.

As a rule of thumb, always do some performance testing to ensure that you aren't hititng the head of a pin with a sledgehammer.

 

6.    

Print | posted on Monday, October 15, 2007 7:42 PM | Filed Under [ WCF ]

Comments have been closed on this topic.

Powered by: