[WCF安全系列]绑定、安全模式与客户端凭证类型:NetNamedPipeBinding、NetTcpBinding与NetMsmqBinding...

在前面两篇(《绑定、安全模式与客户端凭证类型:BasicHttpBinding》和《绑定、安全模式与客户端凭证类型:WSHttpBinding与WSDualHttpBinding》)中,我们详细地介绍了四种基于HTTP的绑定分别支持的安全模式,已经在相应的安全模式下可以采用怎样的客户端凭证。在本篇文章中,我们安全线相同的方式来介绍三种基于局域网的绑定,即NetNamedPipeBinding、NetTcpBinding与 NetMsmqBinding。

一、NetNamedPipeBinding

NetNamedPipeBinding只能用于同一台机器上的不同进程之间的通信(IPC:Inter-Process Communication)。在IPC这样的通信场景下,根本不需要基于Message模式的安全。所以在表示NetNamedPipeBinding安全的NetNamedPipeSecurity类型中,表示支持的安全模式的Mode属性对应的NetNamedPipeSecurityMode枚举仅仅具有两个选项:None和Transport。在默认的情况下,NetNamedPipeBinding采用Transport安全模式。

此外还有一点值得一提:表示Transport模式安全的NamedPipeTransportSecurity类并不存在ClientCredentialType属性,因为它总是采用Windows作为其客户端凭证。NetNamedPipeBinding安全相关的应用编程接口如下面的代码片断所示。

   1: public class NetNamedPipeBinding : Binding, IBindingRuntimePreferences
   2: {
   3:     //其他成员
   4:     public NetNamedPipeSecurity Security { get; set; }
   5: }
   6: public sealed class NetNamedPipeSecurity
   7: {
   8:     //其他成员
   9:     public NetNamedPipeSecurityMode Mode { get; set; }
  10:     public NamedPipeTransportSecurity Transport { get; set; }
  11: }
  12: public enum NetNamedPipeSecurityMode
  13: {
  14:     None,
  15:     Transport
  16: }
  17: public sealed class NamedPipeTransportSecurity
  18: {
  19:    //不存在ClientCredentialType属性
  20: }

二、NetTcpBinding

较之NetNamedPipeBinding,NetTcpBinding涉及安全相关的定义就要复杂一些。Security属性返回的是一个用于设置NetTcpBinding安全的NetTcpSecurity对象。表示安全模式的NetTcpSecurity的Mode属性返回的是我们提到过的SecurityMode枚举,意味着NetTcpSecurity和WSHttpBinding以及WS2007HttpBinding支持相同的安全模式集,即None、Transport、Message和Mixed(TransportWithMessageCredential)。在默认的情况下,NetTcpBinding采用Transport安全模式

NetTcpSecurity的Transport属性返回的是一个用于进行Transport安全设置的TcpTransportSecurity类型对象。TcpTransportSecurity的ClientCredentialType属性以TcpClientCredentialType枚举的形式表示采用的客户端凭证类型。定义在TcpClientCredentialType中的三个枚举值表示NetTcpBinding在Transport模式下支持的所有客户端凭证类型:None、Windows和Certificate。在默认的情况下,NetTcpBinding采用Windows凭证

而通过Message属性返回的用于进行Message安全设置的则是一个MessageSecurityOverTcp类型对象。MessageSecurityOverTcp用于表示客户端凭证类型的ClientCredentialType属性的依然是MessageCredentialType,意味着NetTcpBinding和上述的三个WS绑定在Message模式下,具有相同的客户端凭证集。在默认的情况下,NetTcpBinding采用Windows凭证。NetTcpBinding安全相关的应用编程接口如下面的代码片断所示。

   1: public class NetTcpBinding : Binding, IBindingRuntimePreferences
   2: {
   3:     //其他成员
   4:     public NetTcpSecurity Security { get;set}
   5: }
   6: public sealed class NetTcpSecurity
   7: {  
   8:     //其他成员
   9:     public SecurityMode Mode {  get; set; }
  10:     public TcpTransportSecurity Transport { get;  set; }
  11:     public MessageSecurityOverTcp Message { get; set; }
  12: }
  13: public sealed class TcpTransportSecurity
  14: {    
  15:     //其他成员
  16:     public TcpClientCredentialType ClientCredentialType { get; set; }
  17: }
  18: public sealed class MessageSecurityOverTcp
  19: {    
  20:     //其他成员
  21:     public MessageCredentialType ClientCredentialType { get; set; }
  22: }
  23: public enum TcpClientCredentialType
  24: {
  25:     None,
  26:     Windows,
  27:     Certificate
  28: }

三、NetMsmqBinding

NetMsmqBinding的Security属性的类型为NetMsmqSecurity。而表示NetMsmqBinding采用的安全模式的Mode属性返回一个NetMsmqSecurityMode枚举。NetMsmqSecurityMode枚举的定义反映了NetMsmqBinding支持的安全模式集与其它系统定义绑定都不太一样。定义在NetMsmqSecurityMode的四个枚举值反映了NetMsmqBinding支持的四种安全模式:None、Transport、Message和Both。

首先,NetMsmqBinding具有 一种独有的安全模式Both。这种模式意味中同时采用Transport和Message,就像是加上了双保险。有人可能会提出这样的问题:如果同时采用Transport和Message两种模式,性能岂不是会变得很差?但是,由于MSMQ总是采用一种单向(One-Way)或者异步的消息发送机制,对性能并没有太高的要求。此外,NetMsmqBinding并不支持Mixed(TransportWithMessageCredential)。在默认的情况下,NetMsmqBinding采用Transport安全模式

通过NetMsmqSecurity的Transport属性返回的用于进行Transport安全设置的是一个类型为MsmqTransportSecurity的对象。和NetNamedPipeBinding类似,MsmqTransportSecurity并没有一个ClientCredentialType属性。这是因为在Transport模式下,NetMsmqBinding总是采用Windows凭证。而通过用于进行Message安全设置的Message属性对应的类型为MessageSecurityOverMsmq。MessageSecurityOverMsmq具有一个类型为MessageCredentialType的ClientCredentialType属性。NetMsmqSecurity安全相关的应用编程接口定义反映在下面的代码片断中。

   1: public class NetMsmqBinding : MsmqBindingBase
   2: {    
   3:     //其他成员
   4:     public NetMsmqSecurity Security {get; set; }
   5: } 
   6: public sealed class NetMsmqSecurity
   7: {    
   8:     //其他成员
   9:     public NetMsmqSecurityMode Mode {  get; set; }
  10:     public MsmqTransportSecurity Transport { get; set; }
  11:     public MessageSecurityOverMsmq Message { get; set; }
  12: }
  13: public enum NetMsmqSecurityMode
  14: {
  15:     None,
  16:     Transport,
  17:     Message,
  18:     Both
  19: }
  20: public sealed class MsmqTransportSecurity
  21: {
  22:     //不存在ClientCredentialType属性
  23: }
  24:  
  25: public sealed class MessageSecurityOverMsmq
  26: {
  27:     //其他成员
  28:     public MessageCredentialType ClientCredentialType {get; set; }
  29:  }
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
"java.io.IOException: Stream closed"是一个常见的错误消息,它表示在处理输入或输出流时出现了问题。在Java中,输入和输出流是用于读取和写入数据的工具。 通常情况下,抛出这个异常的原因是由于输入或输出流在操作之前已被关闭。当我们使用Java的IO类进行输入或输出操作时,我们需要按照一的顺序正确关闭流,以避免出现此错误。 在遇到这个错误消息时,我们可以检查以下几个方面: 1. 检查是否正确地打开和关闭了输入或输出流。在使用完流之后,我们应该使用`close()`方法来关闭流。 例如,在读取文件时,我们应该使用以下代码片段: ```java try { FileInputStream file = new FileInputStream("myfile.txt"); // 读取文件的代码逻辑 } catch (IOException e) { e.printStackTrace(); } finally { try { if (file != null) { file.close(); // 关闭流 } } catch (IOException e) { e.printStackTrace(); } } ``` 2. 检查代码中是否存在多个线程尝试共享同一个流。当多个线程同时对同一个流进行操作时,可能会导致其中一个线程关闭了流,而其他线程尝试读取或写入数据时抛出"Stream closed"异常。确保在多线程环境中正确同步流的访问。 3. 检查流对象是否被重复使用。有时我们可能会在多个地方使用相同的流对象进行读写操作。如果在一次操作之后关闭了流,在后续操作中再次使用该流对象将导致"Stream closed"异常。确保每次操作都使用一个新的流对象。 总之,当遇到"java.io.IOException: Stream closed"异常时,我们应该仔细检查流的打开和关闭过程,确保在正确的时间关闭流,并避免多个线程或重复使用流对象造成的问题。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值