在默认状况下,当客户端调用服务时,服务只有在接收到完整的消息后才会被调用,一样,客户端只有在包含了调用结果的返回消息被完整接受时,才会解除对它的阻塞。编程
对于数据量小的消息,这种交换模式提供了简单的编程模型,由于接收消息的耗时较之处理消息自己而言是微不足道的。然而,一旦须要处理数据量较大的消息,如包含了多媒体内容、大文本或数据块的消息,若是每次都要等到完整接收消息以后才能解除阻塞,则未免不太现实。缓存
为了解决这样的问题,WCF容许接收到(客户端或服务)在经过通道接收消息的同时,启动对消息数据的处理。这种类型的处理过程称为流传输模型。对于具备大量负载的消息而言,流操做改善了系统的吞吐量和响应速度,由于在发送 或接收消息的同时,不论是发送方仍是接收方都不会被阻塞。安全
若要处理消息流,WCF须要使用.NET的Stream类。事实上,契约操做对流的使用看起来和传统的I/O方法并没有区别。在.NET中,Stream类是全部I/O的基类(如FileStream、NetworkStream和MemoryStream类),它容许将I/O资源中的内容转化为流。咱们须要作的就是返回或接收一个Stream类型的操做参数,以下例所示:大数据
[ServiceContract] interface IMyContract { [OperationContract] System.IO.Stream StreamReply1(); [OperationContract] System.IO.Stream StreamReply2(out System.IO.Stream stream); [OperationContract] void StreamRequest(System.IO.Stream stream); [OperationContract(IsOneWay = true)] void OneWayStream(System.IO.Stream stream); }注意,只能将抽象类型Stream类型或特定的可序列化的子类(如MemoryStream)做为操做参数。诸如FileStream这样的子类都不支持序列化,由于使用基类Stream实际上是无奈之举。spa
WCF容许服务将请求消息、应答消息,以及请求与应答消息转换为流。code
只有TCP、IPC和基本的HTTP绑定支持流操做。在默认的状况下,这些绑定是禁止流操做的。即便使用了Stream对象,绑定仍然会将消息总体放到缓存中。咱们须要根据所需的流模式,经过设置TrasferMode属性启用流操做,例如,如下使用BasicHttpBingding时。对象
public enum TransferMode { //对请求和响应消息进行缓冲处理 Buffered, //对请求和响应消息进行流式处理 Streamed, //对请求消息进行流式处理,对响应消息进行缓冲处理 StreamedRequest, //对请求消息进行缓冲处理,对响应消息进行流式处理 StreamedResponse } public class BasicHttpBingding:Bingding { public TransferMode TransferMode{get;set} ....... }TransferMode.Streamed支持全部的流模式,也是惟一支持第二节例子中定义的全部操做。可是,若是契约只包含特定的流类型,如如下转换为流的应答消息,则能够包含一个设置为buffered的请求消息,也能够经过选择TransferMode.StreamedResponse将消息转化为流:blog
[ServiceContract] interface IMyConttract { //流的应答消息 [OperationContract] Stream GetStream1(); [OperationContract] int MyMethod(); }在客户端或服务段(或同时在两端),必须为每一个所需的流模式配置绑定。资源
<system.serviceModel> <client> <endpoint address = "http://localhost:8000/MediaService" binding = "basicHttpBinding" bindingConfiguration = "StreamedHTTP" contract = "IMediaService" /> </client> <bindings> <basicHttpBinding> <binding name = "StreamedHTTP" transferMode="Streamed"> </binding> </basicHttpBinding> </bindings> </system.serviceModel>
WCF的流操做只不过是一种良好的编程模型。从根本上讲,传输自身并不支持流操做,它默认的最大消息长度为64KB。这样的数据可能存在问题时,开发者可能但愿使用流操做,转换为流的消息每每会很是大。若是默认的限制不够大,开发者能够增长接收端消息的最大长度,以适应大数据量的消息。能够经过MaxReceivedMessageSize属性,以得到指望的最大消息长度。开发
public class BasicHttpBingding:Bingding,... { public long MaxReceivedMessageSize{get;set;} }能够在运行时采用反复试验找出消息的大小,而后设置相应的绑定。
一般,咱们应避免使用编程方式,而是将一段配信息放到配置文件中,由于消息大小的改变一般发生在部署阶段:
<bindings> <basicHttpBinding> <binding name = "StreamedHTTP" transferMode="Streamed" maxReceivedMessageSize ="120000"> </binding> </basicHttpBinding> </bindings>当使用流操做时,不能使用消息层的传输安全。这是由于TCP、IPC和基本的HTTP绑定支持流操做,对于这些绑定,一般不能使用消息安全。在使用TCP绑定执行流操做时,一样不能启用可靠消息传输。
示例下载:下载