Framing Size Limits for the Tcp and Named Pipe Transports

I've talked about the framing that goes on in the network stack before, but today's topic is a case where the framing actually affects what your application can do. Inside the WCF transport, essentially the uppermost level of the WCF network stack that actually has a byte stream, we need to make a decision about how that stream of bytes will get pushed onto the wire. A WCF message has an almost unlimited size. You can of course constrain the size of messages that you'll deign to receive, but in theory it's possible to create really, really big messages and there might be someone actually willing to receive a message that big.

Network messages almost never have an unlimited size. Some network transports (the layer below WCF transports) cap out at hundreds of bytes, while others cap out at millions of bytes (queues, but I haven't talked about those yet), but nearly all have a cap that is less than the quadrillions or quintillions of bytes you can stuff into a WCF message. How is it possible to actually send a WCF message over a size-constrained network transport?

The solution is message framing. Surrounding each message is contextual information that allows the receiver to reassemble fragments into the original WCF message. Each transport is responsible for splitting the byte stream, applying its own framing format, and performing the reassembly.

At the beginning of the message are two pieces that could conceivably be quite large, the via for message delivery and the content type of the message. Now, these pieces are constrained by your maximum message size, but you have to know where the message is going before you can do things like perform user authentication. This is a sticky point because while you might be ok with authorized users sending you millions of bytes, you probably don't want unauthorized users to do the same.

This was a somewhat long digression to motivate a problem you might encounter with our TCP and named pipe transports. The framing format for these transports specifies that the receiver may, if they want to, cap the maximum size of the message via and content type. That's the Via property on your IOutputChannel and the ContentType property on your MessageEncoder. We do in fact want to do this. There are even specific faults to send back in the event that the limits are reached. What you probably want to know though is: what are those limits? 2048 bytes for the message via and 256 bytes for the content type.

Next time: Mapping Channels to Shapes