다음을 통해 공유

Slicing the Windows Communication Foundation Technology Stack, Part 2

  • 아티클

Yesterday I introduced a simple web service scenario along with one way to solve the scenario using WCF.  If you actually tried to use that architecture though, you would quickly run into a couple of problems.

The first problem is common and I hope that it will be easy to diagnose when the problem is occurring.  The transports we ship with WCF try to be secure out of the box.  Each of the standard transports has a security setting (called MaxMessageSize in earlier preview releases and MaxReceivedMessageSize in later preview releases) that limits the maximum size of a SOAP message that the transport will attempt to receive.  Once a message exceeds this limit, the transport raises a fault and stops receiving data.  This limits Denial of Service attacks that try to fill up system memory by sending your service a never-ending message.  By default, we conservatively put this security setting at 64 kilobytes.

This poses an obvious problem for our scenario that is going to be sending large blobs of data in messages.  When the transport faults, you'll get a nice exception and trace on the receiving end telling you that there was an overly large message.  The solution is to tune the quota value for this setting on the transport.  Since we expect to receive large messages in this scenario, and we're willing to spend the additional memory, we can increase this setting to avoid the problem.  The maximum size is a 64-bit value in case a message size of 4 gigabytes is not enough for everyone.

One thing to be aware of is that intermediate channels and transports can also have policies controlling maximum message size.  If you are connecting through a proxy server that has a limited message size, then changing this setting on the endpoints cannot help you send larger messages.  The setting on an endpoint does not push through intermediary connections.  Proxy server administrators control their own quota settings through system policy.

The other problems with this scenario are performance related and require thinking about how transports interact with higher-level web service features.

Next time: Slicing the Windows Communication Foundation Technology Stack, Part 3

Comments

  • Anonymous
    February 14, 2006
    Continuing with the same seemingly simple web service scenario as before, last time we saw an obvious...
  • Anonymous
    February 14, 2006
    Now it's time to start digging a little deeper into the guts of WCF.  I decided to make up a simple...
  • Anonymous
    October 17, 2006
    Now it's time to start digging a little deeper into the guts of WCF. I decided to make up a simple scenario