问题描述
1、服务器未提供有意义的回复；这可能是由协定不匹配、会话过早关闭或内部服务器错误引起的。2、套接字连接已中止。这可能是由于处理消息时出错或远程主机超过接收超时或者潜在的网络资源问题导致的。本地套接字超时是“00:01:00”服务器上每天都会有一两次这种错误，还没等跟踪呢就自己好了。每天都有，又不会经常出现；大神们帮忙分析分析是什么问题。
解决方案
解决方案二：
没有人么？！~3、服务器拒绝了会话建立请求4、在流的位置1处读取消息组帧格式时出错(状态:Start)这些都是啥情况呀。。。
解决方案三：
解决方案四：
连接超时，如果你的服务端跟客户端分属不同的网络服务商，那么这一现象尤为频繁，有时你放大超时设置也没用，就这么回事。
解决方案五：
可是各个服务器之间是在局域网访问的
解决方案六：
服务要用完就关闭，使用的时候再重新实例化。不要在一个连接里面调用一个不能确定时间的方法，例如等待用户点击确定。
解决方案七：
如果每天只出现1、2次，那么可能算是“正常”的现象。网络本来就是时断时通的，无法保证总是100%不断线。通过缩小信令大小，修改业务流程，等等方法，肯定可以减小碰上这些麻烦的概率。但是不可能100%都避免。只能尽力去发现规律并进行优化。只是需要在最初设计时选择轻量的、高效率的、稳定的、自己能把握核心技术的东西，就能保证以后不出大问题。
解决方案八：
我们曾经因为每天一两次这种问题，于是将WCF改为直接http访问。结果是：调用方法更自由了（直接对任意实体进行json序列化/反序列化，然后使用httpPOST方式发送），最主要地是再也不会有这种异常抛出了。
解决方案九：
这个问题解决了，是因为应用程序池回收太频繁导致的，HTTP调用的方法效率好像很低，动不动就超时了。。后来还是换成了NET.TCP方式，应用程序池的回收改为定时回收，最近一直没出什么问题。
解决方案十：
WCF项目中放了日志跟踪，里面每天有好多“套接字超时”的错误，但是并不反映到页面上。查了好久，分析为应用程序池的保持连接时间为2分钟导致，连接断开，重连时就会记录该错误不知道我的分析对不对