Browse by Tags

• HTTP
• Indigo
• Messages and Encodings

• A Problem with Large Faults

  Fault messages have their own quota sizes, allowing you to limit the amount of data you'll process in response to an error. Existing transport protocols don't know about SOAP fault messages, but some of them have their own error reporting mechanisms that we use for similar purposes. HTTP lets you send back error responses, and there is a similar quota setting for HTTP web requests that let you bound the size of the response. The point of writing this is that the translation doesn't always go smoothly between these quota systems. Our SOAP quotas are measured in bytes while the HTTP quotas need to be rounded up in size to the next largest value measured in kilobytes. Someone recognized that this means that there's a potential for integer overflow in the conversion and so handled that case specially. We take the maximum buffer size and use that to bound your maximum HTTP error size. For buffered transfers, the maximum buffer size is the same thing as the maximum received message size while for streamed transfers, the total message can span many buffered transfers. Unfortunately, the way that overflow is avoided in the computation causes the HTTP quota to not be set in that case. This means that if your maximum buffer size is within 1 KB of Int.MaxValue, the maximum error size doesn't get increased. There's a couple of solutions that you can use here. The default allowed error size is 64 KB so this bug doesn't matter at all if your error messages are smaller than this size. From a practical perspective, there isn't much difference between using Int.MaxValue or a slightly smaller value for the buffer size, so you can avoid the bug by reducing your maximum buffer size by 1025 bytes. It's also possible to directly set the default maximum error size. This is the DefaultMaximumErrorResponseLength setting of HttpWebRequest. Changing this value affects all HTTP traffic in your application, but if you know what your maximum limit is, you can set this and we won't ever use a smaller value. Next time: Reader Mail Read More... Posted Friday, October 06, 2006 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Transports, Documentation, HTTP

• Choosing a Transport

  This is the last planned article in a documentation series covering various aspects of Windows Communication Foundation transports. Today's topic covers how to choose a transport and associated encoder. Choosing a Transport The Windows Communication Foundation (WCF) programming model separates the behavior of endpoint operations from the transport mechanism that connects two endpoints. This gives you flexibility when deciding how your services should be exposed to the network. Transports and message encoders are pieces of WCF that sit below a service to provide connectivity. This document discusses some of the characteristics you need to evaluate when choosing a transport and message encoding. In scenarios where you must connect to a preexisting client or server, you may not have a choice about using a particular transport and message encoding. However, WCF services can be made accessible through multiple endpoints, each with a different transport or message encoding. When a single selection does not cover the entire intended audience for your service, you should consider exposing your service over multiple endpoints. Client applications can then choose the endpoint that is most favorable for them. Using multiple endpoints allows you to combine the advantages of different transports and message encoders. Transports and Message Encoders In WCF, the transfer of data across a network requires the joint cooperation of a transport and message encoder. A message encoder converts a System.ServiceModel.Channels.Message to a serialized form. This document covers the Text, Binary, and MTOM message encoders that are included in WCF. The text message encoder supports both a plain XML encoding as well as SOAP encodings. The plain XML encoding mode of the text message encoder is called the POX encoder to distinguish it from the text-based SOAP encoding. A transport sends the serialized form of the message to another application. This document covers the HTTP, TCP, and named pipe transports that are included in WCF. WCF provides several standard bindings that combine a transport, message encoder, and other options. For instance, the BasicHttpBinding binding combines the HTTP transport with a text message encoder. Similarly, the NetTcpBinding binding combines the TCP transports with a binary message encoder. You are not limited to choosing a preset combination given by a standard binding. Decision Points for Choosing a Transport The following table describes several decision Read More... Posted Wednesday, May 24, 2006 5:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Messages and Encodings, Transports, Documentation