Stream
The Stream sample demonstrates the use of streaming transfer mode communication. The service exposes several operations that send and receive streams. This sample is self-hosted. Both the client and service are console programs.
Windows Communication Foundation (WCF) can communicate in two transfer modes—buffered or streaming. In the default buffered transfer mode, a message must be completely delivered before a receiver can read it. In the streaming transfer mode, the receiver can begin to process the message before it is completely delivered. The streaming mode is useful when the information that is passed is lengthy and can be processed serially. Streaming mode is also useful when the message is too large to be entirely buffered.
Streaming and Service Contracts
Streaming is something to be considered when designing a service contract. If an operation receives or returns large amounts of data, you should consider streaming this data to avoid high memory utilization due to buffering of input or output messages. To stream data, the parameter that holds that data must be the only parameter in the message. For example, if the input message is the one to be streamed, the operation must have exactly one input parameter. Similarly, if the output message is to be streamed, the operation must have either exactly one output parameter or a return value. In either case, the parameter or return value type must be either Stream, Message, or IXmlSerializable. The following is the service contract used in this streaming sample.
[ServiceContract(Namespace="http://Microsoft.ServiceModel.Samples")]
public interface IStreamingSample
{
[OperationContract]
Stream GetStream(string data);
[OperationContract]
bool UploadStream(Stream stream);
[OperationContract]
Stream EchoStream(Stream stream);
[OperationContract]
Stream GetReversedStream();
}
The GetStream operation receives some input data as a string, which is buffered, and returns a Stream, which is streamed. Conversely, UploadStream takes in a Stream (streamed) and returns a bool (buffered). EchoStream takes and returns Stream and is an example of an operation whose input and output messages are both streamed. Finally, GetReversedStream takes no inputs and returns a Stream (streamed).
Enabling Streamed Transfers
Defining operation contracts as previously described provides streaming at the programming model level. If you stop there, the transport still buffers the entire message content. To enable transport streaming, select a transfer mode on the binding element of the transport. The binding element has a TransferMode property that can be set to Buffered, Streamed, StreamedRequest, or StreamedResponse. Setting the transfer mode to Streamed enables streaming communication in both directions. Setting the transfer mode to StreamedRequest or StreamedResponse enables streaming communication in only the request or response, respectively.
The basicHttpBinding exposes the TransferMode property on the binding as does NetTcpBinding and NetNamedPipeBinding. For other transports, you must create a custom binding to set the transfer mode.
The following configuration code from the sample shows setting the TransferMode property to streaming on the basicHttpBinding and a custom HTTP binding:
<!-- An example basicHttpBinding using streaming. -->
<basicHttpBinding>
<binding name="HttpStreaming" maxReceivedMessageSize="67108864"
transferMode="Streamed"/>
</basicHttpBinding>
<!-- An example customBinding using HTTP and streaming.-->
<customBinding>
<binding name="Soap12">
<textMessageEncoding messageVersion="Soap12WSAddressing10" />
<httpTransport transferMode="Streamed" maxReceivedMessageSize="67108864"/>
</binding>
</customBinding>
In addition to setting the transferMode to Streamed, the previous configuration code sets the maxReceivedMessageSize to 64MB. As a defense mechanism, maxReceivedMessageSize places a cap on the maximum allowable size of messages on receive. The default maxReceivedMessageSize is 64 KB, which is usually too low for streaming scenarios.
Read more: MSDN
QR: 