博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
WCF中的Stream操作
阅读量:6987 次
发布时间:2019-06-27

本文共 3073 字,大约阅读时间需要 10 分钟。

WCF支持对Stream对象的操作,尤其对于传递size过大的消息而言,如要考虑传递消息的效率,WCF推荐通过Stream进行操作。

然而,WCF对于Stream操作规定了一些限制,在我们编写相关程序时,需要特别注意:
1、绑定的限制
如 果需要使用Stream操作,可以使用的绑定只能是BasicHttpBinding,NetTcpBinding以及 NetNamedPipeBinding。此外,在使用Stream操作时,不能使用Reliable Messaging。如果考虑到消息安全,则此方式是不可取的。
2、对Stream对象的限制
要作为服务操作所传递的消息对象,这样的对象必须是可序列化的。遗憾的是,FileStream类的定义却是不支持序列化的,我们能够使用的Stream对象,包括Stream,MemoryStream等。使用Stream类对象是大多数Stream操作的首选。
一个有趣的现象是FileStream与Stream类型的转换。例如在服务契约的操作中,有如下的实现:

public
 Stream TransferDocument(Document document)
{
     FileStream stream 
=
 
new
 FileStream
                             (document.LocalPath, FileMode.Open, FileAccess.Read);
     
return
 stream;
}

 

注意,操作TransferDocument()的返回类型为Stream,而方法的实现中,返回的对象则为FileStream类型。由于Stream类是FileStream类的父类,这样的实现没有问题。

然而,在客户端调用该操作时,却不能将操作的返回值赋给FileStream类型的对象,如下所示:

FileStream stream 
=
 m_service.TransferDocument(doc);

此时获得的Stream对象则为null。因而,我们只能这样调用操作:

Stream stream 
=
 m_service.TransferDocument(doc);

但是,还有一个奇怪的问题是WCF并不支持Stream对象Length属性的序列化,也就是说,在客户端我们不能使用服务操作返回的Stream对象的Length属性。诸如stream.Length的调用会抛出NotSupportedException异常。

3、TransferMode的限制

若 要使用Stream操作,必须修改绑定的TransferMode属性。该属性的默认值为Buffered。我们应该根据操作中Stream对象的参数类 型,以决定TransferMode的值分别为Streamed、StreamedRequest或者StreamedResponse。

4、MaxReceivedMessageSize的限制

MaxReceivedMessageSize 属性的默认值为64kb,如果传递的Stream对象一旦超过了MaxReceivedMessageSize属性的设置值,则客户端在操作该对象时,就 会出现CommunicationException异常。因此,我们应根据实际需要设置MaxReceivedMessageSize的值。 MaxReceivedMessageSize属性的取值范围为1-9223372036854775807(Int32.MaxValue)。如果设置 值不在该范围之内,则无法通过编译。编程方式设置为:

binding.MaxReceivedMessageSize
 
=
 120000
;

配置文件的设置方式为:

<
binding …… maxReceivedMessageSize
=
"
120000
"
/>

5、操作参数的限制

WCF对包含了Stream对象的操作参数进行严格的限制,它只允许这样的操作只能包含一个Stream对象,这里所谓的一个Stream对象,是包含return对象,out和ref对象在内的。也就是说如下的操作定义都是错误的:

void
 Transfer(Stream s1, Stream s2);
void
 Transfer(Stream s1, 
out
 Stream s2);
void
 Transfer(Stream s1, 
ref
 Stream s2);
Stream Transfer(Stream stream);

如果定义了这样的操作,则会出现运行时错误。

6、实例激活类型的限制

由 于Stream操作受到绑定的限制,只能使用BasicHttpBinding,NetTcpBinding以及NetNamedPipeBinding 绑定,因此必然会影响服务实例的激活类型,最主要的是对Session模式的影响。首先BasicHttpBinding并不支持Session模式的激 活类型。NetTcpBinding以及NetNamedPipeBinding绑定虽然支持Session模式,但是由于Stream操作不支持可靠消 息传递,即不能将ReliableSession设置为true。因此在定义服务契约的SessionMode时,不能将其值设置为 SessionMode.Required,否则会抛出异常。

实际上,Stream操作(指TransferMode不为 Buffered)本身并不支持Session模式。即使我们在使用NetTcpBinding时,将服务契约的SessionMode设置为 Allowed,并将服务的InstanceContextMode设置为PerSession,服务的执行方式仍然是PerCall方式。(如果不是 Stream操作,这样的设置服务应为PerSession模式)

因此,在执行Stream操作时,即使按照Session模式对服务进行设置,如果我们通过OperationContext.Current.SessionId去获得会话ID,其值应该为空。

此外,由于传输的Stream对象较大,可能会消耗过长的时间,因而建议增大绑定的SendTimeout属性值。例如设置为10分钟。编程方式设置为:

binding.SendTimeout 
=
 TimeSpan.FromMinutes(
10
);

配置文件的设置方式为:

<
binding …… sendTimeout
=
"
00:10:00
"
/>

注意,对绑定的相关设置必须要求服务端与客户端的配置一致。最佳实践是均通过配置文件进行设置。例如在我的应用程序中是这样设置的:

<
basicHttpBinding
>
        
<
binding name
=
"
DocumentExplorerServiceBinding
"
 
                 sendTimeout
=
"
00:10:00
"
 
                 transferMode
=
"
Streamed
"
                 messageEncoding
=
"
Text
"
 
                 textEncoding
=
"
utf-8
"
 
                 maxReceivedMessageSize
=
"
9223372036854775807
"
>
          
        
</
binding
>
</
basicHttpBinding
>
本文转自wayfarer51CTO博客,原文链接: http://blog.51cto.com/wayfarer/280105
,如需转载请自行联系原作者
你可能感兴趣的文章
Citrix发布支持Framehawk技术的HDX协议,用户体验优势进一步扩大
查看>>
Android各种访问权限Permission详解
查看>>
RHEL5.5安装中文支持
查看>>
web前端开发中浏览器兼容问题(五)
查看>>
小博老师解析Java核心技术 ——动态解析Jar的运用
查看>>
我的友情链接
查看>>
博为峰Java技术文章 ——JavaSE Swing BoxLayout布局管理器I
查看>>
PC时代的20位英雄
查看>>
经典的MySQL 数据备份daemon程序
查看>>
腾讯云TDSQL审计原理揭秘
查看>>
postgresql的源码安装及配置使用
查看>>
Nginx反向代理腾讯云COS的一个坑
查看>>
简单sql server数据库自动还原脚本
查看>>
我的友情链接
查看>>
【MySQL数据库开发之四】MySQL 处理模式/常用查询/模式匹配等(下)
查看>>
http 长连接和短连接介绍
查看>>
E-STP
查看>>
(JMX读书笔记)-JMX基本概念
查看>>
grep的语法和用法
查看>>
【hadoop】25.MapReduce-shuffle之分组
查看>>