Streaming Data from a WCF Service

MTOM is useful for encoding large binary data objects in messages, but if these objects become too large they can consume significant amounts of memory in the computer hosting the WCF service and the client applications that receive them. Additionally, very large messages can take a long time to construct and transmit, and it is possible that the client applica tion could time-out while waiting for a response containing a large binary object.

In many cases, it does not make sense to even attempt to try and package up data into a single message. Consider a WCF service that provides an operation that emits audio or video data. In this scenario, it is far more efficient to send the data as a stream than to try and send it as one big chunk. Streaming enables the client application to start receiving and processing bytes of data before the service has transmitted the end of the message, resolving the need to create large buffers for holding an entire message in the service and the client application, and resolving the time-out issue.

Enabling Streaming in a WCF Service and Client Application

WCF provides streaming support for operations by enabling you to modify the TransferMode property of binding configurations based on the basicHttpBinding, netTcpBinding, or netNamedPipeBinding bindings. If you need to use a binding other than these, you must create a custom binding with a transport channel element that exposes the TransferMode property (basically, this means using <HttpTransportBindingElement>, <HttpsTransportBindingElement>, <TcpTransportBindingElement>, or <NamedPipeTransportBindingElement>). For further information on creating and using a custom binding, refer back to Chapter 10.

You can set the TransferMode property to one of the following values:

• Buffered. This is the default transfer mode. Messages are completely constructed in memory and transmitted only when they are complete.

• StreamedRequest. Request messages are streamed, but response messages are buffered.

• StreamedResponse. Response messages are streamed, but request messages are buffered.

• Streamed. Request and response messages are all streamed.

Designing Operations to Support Streaming

There is more to streaming than just changing the TransferMode property of a binding, and not all operations are conducive to streaming. To support request streaming, an operation can take only a single input parameter, and this parameter must either be a stream object (a descendent of the System.IO.Stream class) or be serializable using the encoding mechanism specified by the binding. To support response streaming, an operation must either have a non-void return type or a single out parameter, and, like the input parameter, the type of this return type or parameter must either be a stream object or be serializable. As an example, here is the service contract for a version of the GetPhoto operation from the ShoppingCartPhotoService service that supports streaming:

 public interface IShoppingCartPhotoService {     [OperationContract(Name = "GetPhoto")]      byte[] GetPhoto(string productNumber); }

If you enable message logging, you will see that the body of the response message appears like this:

 <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing">   <s:Header>     …   </s:Header>   <s:Body>... stream ...</s:Body> </s:Envelope>

Note 

A version of the ShoppingCartPhotoService that uses streaming is available in the Microsoft Press\WCF Step By Step\Chapter 12\Streaming folder under your \My Documents folder. The solution contains a project called StreamingHost that implements the GetPhoto operation, a console application called StreamingServiceHost that hosts the service and configures a TCP binding with the TransferMode property set to enable streaming, and a GUI client application called StreamingGUIClient that exercises the GetPhoto operation.

Security Implications of Streaming

Message level security features such as signing and encryption require the WCF runtime to have access to the entire message. When you enable streaming for a binding, this is no longer possible, so you must use transport level security instead.

Additionally, you cannot use reliable messaging. This feature depends on buffering so that the protocol can acknowledge delivery of complete messages and optionally order them (if ordered delivery has been specified for the binding). This is only really an issue for bindings based on the HTTP transport, as the TCP protocol and named pipes typically provide their own inherently reliable delivery mechanisms that are independent of the WCF implementation of the WS-ReliableMessaging protocol.

One final point concerning security: by default, bindings created by WCF allow a maximum received message size of 64Kb. If a message being received exceeds this limit, the WCF runtime throws an exception and aborts the operation. This limit is primarily intended to reduce the scope for Denial of Service attacks. This value is sufficient for most message-oriented operations but is too low for many streaming scenarios. In these cases, you will need to increase the value of the MaxReceivedMessageSize property of the binding. However, be aware that this is a global setting for the binding and so affects all operations exposed by the service through this binding.