WCF通讯

[写个昵称都这么麻烦]

求助大神帮忙！问题可能有点长、请耐心看完再回答、多谢
使用WCF服务作为客户端去连接另外一个WCF服务、这两个服务都是用Windows服务承载的、然后作为客户端的那个WCF服务连接另外一个WCF服务、使用它提供的任何服务都是没问题的、同时那个作为客户端的WCF服务里面有个线程一直监视着另外一个WCF服务、如果发现它挂掉了、就会立即自动去启动它、
发现那个WCF服务挂掉然后去启动它是没问题的、之后重新client.open()也没问题、到这里问题就来了、我再次使用那个WCF提供的服务时就会报错了、说通道处于出错状态、现在我初步怀疑是WCF服务重启后、上一次连接的通道没关闭、而第二次client.open()连接后会产生两个通道、但是我去调用WCF提供的服务时它使用的是第一次的通道、所以会报这种错误！后来我在那个线程监视里做了处理、第二次连接之前就已经把第一次的通道给client.close()关闭了、但是问题依然没解决、快奔溃了、求大神！！！！！！

错误提示“
通信对象 System.ServiceModel.Channels.ServiceChannel 无法用于通信，因为其处于“出错”状态。”

[写个昵称都这么麻烦]

引用 4 楼 dongxinxi 的回复:

发现那个WCF服务挂掉 LZ是依据什么来判断的？client对象的连接状态还是目标WCF服务的进程？ 重新启动服务后，用其他的工具测试一下那个服务是否可用

我说了用Windows服务承载了WCF服务、看清楚问题再回答、

[qldsrx]

自从我改用了Stream模式传输（不支持Open）后，就再也没有遇到过楼主的烦恼了。

[写个昵称都这么麻烦]

引用 6 楼 qldsrx 的回复:

自从我改用了Stream模式传输（不支持Open）后，就再也没有遇到过楼主的烦恼了。

大神啊、你又出现了、帮我分析下这问题吧！ 我被搞晕了 双工通讯中、我们的win form客户端如果是用UI的线程去open 那么如果想要close的话必须得开另外一个线程去close 因为回调是一直占用着通道的、所以close的信息不能返回

[写个昵称都这么麻烦]

    [ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant, InstanceContextMode = InstanceContextMode.Single)]

[写个昵称都这么麻烦]

我有点头绪了、试下先

[qldsrx]

我从一开始尝试了下双工模式后，就直接放弃了，因为这个模式不但使用麻烦，还很耗资源，非常不适合当前的网络条件。就拿你这里的情况，还要不停的监视连接状态，那还不如需要的时候新建连接更好，用完就关闭连接更好。设想为啥IIS默认的保持连接才120秒，不肯更长，因为外网条件多变，保持连接很难做长。 我不知道你的委托回调是不是在后台线程中工作的，如果是的话，不会阻塞当前线程进行Close的，另外WCF也内部提供了异步操作的方法，可以查看Silverlight中的WCF的写法，完全是异步模式的。

[qldsrx]

我举个例子说明保持连接的消耗： 如果客户端通过最简单的TCP连接到服务器，为了保证当前连接可用，必须定时发送心跳包，如果不这样做，中间即使发生断网的情况都不会被发现，只有在数据传输过程中，不能顺利到达才被认为是连接断开了。如果我改为轮询服务器是否有通知下来，效果也一样，而带来的好处是我不需要为了各种连接断开而烦恼了。除非网络条件非常好（内网），同时需要有高速的响应，且做好了消息队列，处理发送失败的消息重发，否则还不如定时轮询服务器更实在。

[写个昵称都这么麻烦]

难道问题出在跨线程？

[我为自己_代言]

http://blog.csdn.net/FarmerCode/article/details/8151433

[lshfong]

你把连接日志写到一个txt文件里跟踪下

[IE11下面经常卡到爆]

发现那个WCF服务挂掉 LZ是依据什么来判断的？client对象的连接状态还是目标WCF服务的进程？ 重新启动服务后，用其他的工具测试一下那个服务是否可用

[qldsrx]

你可以看下WCF的路由模式

[写个昵称都这么麻烦]

引用 11 楼 qldsrx 的回复:

我举个例子说明保持连接的消耗： 如果客户端通过最简单的TCP连接到服务器，为了保证当前连接可用，必须定时发送心跳包，如果不这样做，中间即使发生断网的情况都不会被发现，只有在数据传输过程中，不能顺利到达才被认为是连接断开了。如果我改为轮询服务器是否有通知下来，效果也一样，而带来的好处是我不需要为了各种连接断开而烦恼了。除非网络条件非常好（内网），同时需要有高速的响应，且做……

问题解决了、是线程阻塞了 针对问题说明下、由于项目的特殊性、服务必须24小时开着、而整个项目中服务的个数还是很多的、每个WCF服务作为服务的同时它也是其他服务的客户端、各个服务之间是要时刻进行通讯着的、所以需要的时候才连接这不现实、所以只能通过一些方法去保持每时每刻都是连接的、最重要的是我们是千兆网络的内网、服务不会对外公布、所以负荷还不是很大 话说分析到这地步真的很牛B啊、啥时候我也能像你们这样 上面说到的轮询服务器、是什么来的、能详细说下么、什么是轮询

[qldsrx]

轮询服务器就是定时访问服务器，服务端有什么要传达给客户端的，在双工通信中可以直接通过委托回调无延迟地实现，而轮询服务器则表现为服务端先自己缓存要回调的消息，等下次客户端主动来采集，频率则看实时性要求了。如果无任何动作，服务端一般只返回空内容，数据传输量几乎可以忽略的。

[qldsrx]

另外你8楼给的ServiceBehavior，看似是多线程支持了，其实那个对多个调用而言的，我最初接触双工通信的时候，也以为只要设置了ServiceBehavior就能做到异步回调了，其实根本不是那么回事，在服务端的方法中要调用客户端方法的话，那部分代码最好使用后台线程，用委托的BeginInvoke或者开启新的Thread来实现。虽然服务端没有UI界面的说法，不会卡界面，但是卡服务也是一样的。不过没有UI界面就没有跨线程操作控件的麻烦，服务类中的任何全局变量都可以在任何线程中被访问。那么为了让某个含有客户端回调的方法不会在执行中被卡住，让整个方法都运行在后台线程中去吧，这样客户端即使调用方法和回调委托处于同一个线程也不会出现线程阻塞的情况（修改服务端来实现）。

[空格键]

[写个昵称都这么麻烦]

引用 14 楼 qldsrx 的回复:

另外你8楼给的ServiceBehavior，看似是多线程支持了，其实那个对多个调用而言的，我最初接触双工通信的时候，也以为只要设置了ServiceBehavior就能做到异步回调了，其实根本不是那么回事，在服务端的方法中要调用客户端方法的话，那部分代码最好使用后台线程，用委托的BeginInvoke或者开启新的Thread来实现。虽然服务端没有UI界面的说法，不会卡界面……

这些我都已经知道了 想听听像我这种情况的、不用WCF去实现、 还有别的解决方案么

[写个昵称都这么麻烦]

引用 17 楼 qldsrx 的回复:

你可以看下WCF的路由模式

找到最简洁的解决办法了、只需在客户端加上 [CallbackBehavior(UseSynchronizationContext = false)] 这句就可以了、理论没错、但一开始方向就错了 WCF作为微软的三大核心技术之一、所有可能的情况应该都会提供了解决方法、 只是我们不知道而已、个人猜想的 虽然问题是自己解决的、但你说的蛮中肯的、就结贴给分了吧