注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

还东国的博客

行之苟有恒,久久自芬芳

 
 
 

日志

 
 

wcf(六)  

2012-07-26 18:12:23|  分类: NET(C#) |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
 

 

时隔将近一年,重新开始总结WCF的经验和学习新的知识,子曰:学而时习之,不亦乐乎。那就开始乐吧。

WCF在去年的总结里其实是丢下了一个小尾巴的,但由于工作的紧迫和后来的不作为,这个小尾巴就放到那儿了。其实也没什么,就是在“使命必达: 深入剖析WCF的可靠会话[实例篇](内含美女图片,定力差者慎入)”这篇博文中的实例,没有调通。

这两天琢磨着重新用WCF干点儿东西,就把这个就小问题搞定一下。主要是两个问题:

1、  不能够象实例代码中一样增加自定义的信道,即报一个configurationerrorsexception” 无法加载为扩展”unreliabeNetworkSimulate” 注册的类型”。

在网上找到一种解决方法,说是微软的BUG,在app.config的扩展节上(<extensions>),将type类型中所有的逗号(,)后面加一个空格。不过可惜的是,在这里不能解决这个问题。然后折腾了将近一下午,偶然用VS2010中提供的工具“工具—WCF服务配置编辑器”打开这个app.config文件,发现同样报找不到那个扩展的类型,手动去打开,发现即使进入到扩展节的工程里也找不到这个DLL,于是觉得发现找到解决的方法了,将名字改了一下,果然,能够用工具进行编辑了,但发现使用是还是报一个错,不过换了“创建 system.serviceModel/extensions 的配置节处理程序时出错: 未能加载文件或程序集“MyWCF.fjf.Expands, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null”或它的某一个依赖项。找到的程序集清单定义与程序集引用不匹配。 (异常来自 HRESULT:0x80131040)”,明白了,肯定是动态进行刷新了。

于是,打开扩展库属性,将其默认命名空间和程序集名都改成了app.config(客户端)中扩展节的名字,即:MyWCF.fjf.Expands,果然再编译时,通过了。

这个耽误了好长时间,主要是怀疑服务端有问题,或者名字写错了,这通修改啊,怎么也没有想到是名空间的不对,因为写的名空间是对的,只是默认的程序集和空间名称没想到不一致。没办法啊。悲催。

2、 图像无法传输

这个其实才是最主要的,也查了半于,莫名的发现,服务端的app.config中endpoint的地址和客户端的竟然不一样,主要是端口,前者从7777—8888-9999,而后者为6666-7777-8888,晕了,改了后,果然可以传输图像。

3、 图像传输不稳定。

图像的传输时好时坏,如果不增加那个扩展的自定义信道(也就是不模拟不稳定网络),程序跑得很好。但增加后,这个图像时好时坏。但实例却一直很好,说明程序还是有地方写的不对。

在修改时不小心把this.m_shHost = new ServiceHost(typeof(ImageTransferServices));这行代码的ImageTransferServiecs给写成了接口IMyImageTransfer,悲催了,一上午就在弄这个,虽然在网上查找时,记得有提醒是这个的,但还真得没有引起注意啊。结果把原来代码拷过来,发现可以用,才发现这个问题的。如果用接口,则会报一个“ServiceHost only supports class service types”如果是中文版的会报“service host 仅支持类服务类型”,可怜的人。

回到图像传输的不稳定上,错误现象很怪异,有时候儿好,有时候儿坏,有时候儿换个端口也好,但大多数的情况下,图像是无法传输的。经过认真的调试和源码比对:

发现在:UnreliableNetworkSimulateChannel.cs这个类文件中,出现了三处致命的错误:

第一个函数,异步接收:

 public IAsyncResult BeginTryReceive(TimeSpan timeout, AsyncCallback callback, object state)

        {

            return this.InnerSessionChannel.BeginTryReceive(timeout, callback, state);

        }

第二函数关闭:

        public void Close(TimeSpan timeout)

        {

            this.InnerSessionChannel.Close(timeout);

        }

第三个函数发送:

       public IAsyncResult BeginSend(Message message, TimeSpan timeout, AsyncCallback callback, object state)

        {

            return this.InnerSessionChannel.BeginSend(message, timeout, callback, state);

        }

其中,第二个函数丢失了传输的参数,也就是timeout,第一和第三个函数更可怕,竟然直接调用了自己,也就是说把InnerSessionChannel给丢失了,怪不得程序总是报是不是有递归调用造成栈溢出,当时真是就没有向这方面想,真是的,看来人家编译器提供的错误提示还是比较准确的。

这其中出现过得错误还有“目标主机积极拒绝”,“无法连接到 net.tcp://IP:端口/Service。连接尝试持续了 00:00:01.0840620 时间跨度。TCP 错误代码 10061: 由于目标计算机积极拒绝,无法连接。”等,总之用了将近两天的时间总算把去年的小尾巴搞定了,更深入的认识了WCF的配置文件的作用,其实主要的错误产生还是配置文件误配造成的。一定要小心,再小心。

坚定方向,奋力前进。

顺道骂句粗口,网易的BLOG管理员真TMD有病,明明啥都木有,就是不让发表。看看写的什么GB过滤文本程序。

 

 

 

 

  评论这张
 
阅读(806)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017