Yesterday, we looked at an architecture change from a buffered transport strategy to a streamed transport strategy.  Making this change improved the scalability of the service by eliminating the large memory allocation for each concurrent connection.  I mentioned last time that one consequence of making this change is the need to switch from message security to transport security.

A consequence that I didn't mention is that changing the transport transfer mode from buffered to streamed also changes how we expose the TCP/IP transport to your code.  WCF has a number of built-in design patterns for sending and receiving messages, called 'channel shapes'.  I will be going into detail about channel shapes in a few weeks, but what's important to know is that changing the transfer mode causes the TCP transport to use a different channel shape.  To update the application code, you will either need to change the channel shape you expect to get back or use a shim that implements one channel shape in terms of other shapes.

Using a streamed transfer mode is not the only way to avoid the cost of buffering large messages.  Next time, I'll reslice the problem and present an architecture that doesn't require changing the security mechanism or channel shape.

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