关闭代理服务器有什么影响云服务器有什么用途

我们想对WCF具有一定了解的人都会知道：在客户端通过服务调用进行服务调用过程中，服务代理应该及时关闭。但是如果服务的代理不等得到及时的关闭，到底具有怎样的后果？什么要关闭服务代理？在任何时候都需要关闭服务代理吗？是否有一些例外呢？本篇文章将会围绕着这些问题展开。

一、会话信道（SessionfulChannel）
V.S.数据报信道（DatagramChannel）

WCF通过信道栈实现了消息的编码、传输及基于某些特殊功能对消息的特殊处理，而绑定对象是信道栈的缔造者，不同的绑定类型创建出来的信道栈具有不同的特性。就对会话的支持来讲，我们可以将信道分为以下两种：

对于绝大部分绑定类型（BasicHttpBinding除外），在默认的情况下创建的都是会话信道。对于WCF客户端来说，如果进行基于会话信道的服务调用，有一些问题需要引起足够的重视，如果使用不当，不但影响客户端本身的服务调用，还会对服务处理请求的吞吐量造成很大的影响。

基于会话信道服务调用须要注意的第一个问题和WCF流量限制有关，为了使读者对这个问题先有一个直观认识，我们照例通过一个简单的实验来重现须要解决的问题。本例使用我们熟悉的计算服务例子，在服务寄宿的时候采用WsHttpBinding，下面是客户端程序。

从输出的结果可以看出，虽然在代码中我们通过一个for循环进行了20次服务调用，但是真正成功执行的仅仅有11次，第12次进行服务调用的时候，抛出Timeout异常。这种情况的出现源于WCF对并发会话数量的控制。说得具体点，WCF对一个ServiceHost所能处理的并发会话作了限制，在默认的情况下，允许的最大并发会话数量为10。

那么细心的读者马上会问一个问题，既然默认的并发会话数量为10，为什么上面的例子中，会有11次成功的并发服务调用呢？这是因为，服务端的信道监听器允许一个额外的会话信道。在很多情况下，11个并发会话肯定是不能满足具体的需求的，那么是否可通过相应的配置根据具体的需求灵活指定一个合适的最大并发会话数量呢？答案是肯定的，服务允许的最大并发会话可以通过ServiceThrottlingBehavior服务行为的MaxConcurrentSessions属性进行配置。在下面的配置中，将该值设为了20。

WCF对服务的并发会话的限制给WCF客户端提出了一个要求，那就是在服务代理不再使用的情况下，应该及时将其关闭。基于服务代理对象的会话会随着服务代理的关闭而关闭。服务端在处理客户端请求的时候，如果当前并发的会话数量超过了所允许的范围，后续的请求将会被放入等待队列，以等待现有会话的结束。对于客户端来说，服务调用在允许的超时时限（默认1分钟）内还未接收到回复，则会抛出一个TimeoutException异常，如例子所表现的一样。如果能够及时地关闭服务代理对象，即使是次调用都没有问题，如下所示：

上面讲的是对最大会话的限制，实际也可以说成是对最大会话信道的限制，那么对于非会话信道是否也有此限制呢？实践出真知，照例通过具体的例子来说明问题。我们知道绑定是信道的创建者，信道的特性通过组成绑定的元素（绑定元素）决定，所以信道对会话支持的特性也不例外。以上面例子使用的WsHttpBinding为例，只有WsHttpBinding的安全（Security）或可靠会话（ReliableSession）开启的情况下，创建的信道才具有会话的特性，否则创建出来的信道是不能支持信道的。在默认的情况下，WsHttpBinding的安全模式（SecurityMode）为基于消息的安全，所以创建出来的信道自动被赋予了会话的特性。

为了验证在非会话信道的情况下，WCF最大并发会话限制是否存在，我们对上面的代码稍加修改，在创建WsHttpBinding的时候，将安全模式设为SecurityMode.None（当然，在进行服务寄宿的时候，WsHttpBinding也须要进行相同的设置）。通过最终输出结果可以看出，MaxConcurrentSessions的限制不适合非会话邦定。

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。

2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。