从事软件开发行业十多年,专注于网络通信技术和网络语音视频技术,擅长系统架构设计、系统性能优化等。zhuweisky.cnblogs.com
上文讲述的是AS中的基于连接池的消息处理器,现在我们把焦点转移到功能服务器FS上来,看看FS上消息分派的过程。当FS接收到到一个请求后,会从已加载的功能插件列表中选择一个合适的插件来处理这个消息,而每一个功能插件就相当于一个消息处理器。
前面的两篇文章我们已经介绍了Tcp连接池和Tcp连接池管理器,并且引入了ITcpPool接口,这个接口可以将单个连接池和一组连接池统一起来,使它们有相同的外部使用方式。现在我们需要考虑的问题是,当消息分派器分派一个接收到的请求时,如果这个请求需要被FS上的某个功能插件处理,那么消息分派器是如何将这个消息分派到对应的FS上去的? 回顾介绍消息分派器时画出的各消息组件联系图,我们非常自然的想到,创建一个消息处理器,这个消息处理器将请求消息通过Tcp连接池转发给对应FS处理。
上文已经讲到,Tcp连接池管理器为我们的应用进行了很多复杂的管理,比如功能服务器的调度(实现FS的负载均衡)、连接池的动态添加/移除、控制每个连接池的相关参数在UI上的显示等,并且连接池管理器与单个连接池拥有一样的接口ITcpPool。
凡是带有“池”的,比如数据库连接池、对象池、缓冲区池(后面可以看到IBuffPool)等等,都是为了避免资源的反复创建/销毁所带来的开销。需要为哪些资源对象建立“池”了?这些资源对象通常符合下面几个特性:(1)在应用中需要反复的被创建/销毁。
使用ESFramework开发C/S(通常为4层、3层也没问题)应用,当需要增加一项新的业务时,我们需要做的仅仅是开发两个插件,一个是服务端的业务功能插件(FunAddin),一个是客户端插件(PassiveAddin),这两个插件合在一起称为Addin Pair。
前文已经提到了,在IServerAgent的基础上,客户端也可以采用插件的结构形式,客户端插件需要实现IPassiveAddin接口。 我的想法是,当客户端主程序加载一个新的PassiveAddin时,可以在某个菜单的子Items上添加一项,当双击这个子菜单项时,则弹出该客户端插件提供的“业务操作窗体”。
(本文原作于2006.03.15,第一次修正于2006.06.06,修正后适用于ESFramework V0.3+) (本文是ESFramework对客户端开发的支持特性之一 ,如果要按顺序阅读,请转到ESFramework介绍(序)) 分布式系统的构建一般有两种模式,一是基于消息(如Tcp,http等),一是基于方法调用(如RPC、WebService、Remoting)。
从2004年7月开始,就一直从事N层C/S架构的服务端的开发,时至今日,慢慢的积累了一些开发经验,ESFramework网络通信框架体系便是这些经验的总结。ESFramework网络通信框架这是一套完全可复用的、灵活的、单纯的、支持N层C/S架构的网络通信框架,内置了对Tcp和Udp协议的支持。
网络上传输的消息经常是经过加密和压缩,有的特定类型的消息可能还需要进行其它变形,ESFramework通过INetMessageHook对这些功能提供支持。需要说明的是,ESFramework对消息进行截获(Hook)处理有两种方式,一是仅仅Hook处理消息主体(Body),而不对消息头作任何变换;另一种方式是对整个消息(包括消息头和主体)都进行Hook处理。
一。ESFramework网络通信框架与消息处理器 无论是服务端还是客户端,都需要对接收到的消息进行处理,在ESFramework网络通信框架中,处理消息的组件称为消息处理器,所有的消息处理器都实现了接口IDataDealer: 1 public interface IDa...
ESFramework网络通信框架与元数据 较之C++而言,.NET是一个更加“动态”的平台,其动态能力建立在反射机制之上,而反射的基础是“元数据”。 上文已经提到过,如果一个框架要为我们的应用做更多的事情,那么这个框架必须建立更多的标准,必须对框架自己要处理的消息有更多的了解,所以,每个消息都要是自描述的,也就是说每个消息要包含它自己的“元数据”。
一.ESFramework网络通信框架与字节流 通过网络通信的系统之间(如客户端与服务端的通信)要想正常交互,它们必须有“共同的语言”,这种语言就是消息协议。遵守消息协议的消息才能被我们的系统所理解。
在我前面的“压缩与解压缩 ZipHelper ”一文中提到了使用ICSharpCode.SharpZipLib.dll库的BZip2OutputStream和BZip2InputStream 来进行数据流的压缩。
我在AgileIM的开发中解决视频/音频会话功能时,发现传输的音/视频数据量太大,通过一些格式转换(如BMP->JPG、或 帧间预测编码)可以适当减少带宽的需求,但是仍然不能满足需求,于是我想到了数据压缩,经过我测试、普通的音/视频数据经压缩后可以只有原来的一半大小,基本可以满足需要了。
.NET FrameWork 1.1之前版本根本不支持多媒体,.NET FrameWork 2.0也只是对多媒体进行了最简单最有限的支持,如果在我们的.NET程序中需要播放多媒体文件,通常只有通过互操作引入Activex控件来播放音频/视频。
说这是一个完全的解决方案,其实有点夸大了,但这个方案确实可以缓解TCP服务器遭受“拒绝服务攻击”时表现出的脆弱性。 当服务器以Tcp的方式提供服务时,客户端通过tcp连接上服务器。这时,恶意的程序,也可以通过tcp连接我们的服务器,如果恶意的程序采用循环与我们的服务器建立成千上万的连接,并在每个连接上都发送恶意的数据包给服务器,慢慢就会导致服务器资源耗尽而崩溃! 为了增强Tcp服务器在遭受“拒绝服务攻击”时的稳定性,我采用的方案是这样的:(1)通信协议的消息头增加Token字段,并且它是消息头的第一个字段。
近日,做一个分布式数据库定时同步的项目,也就是说有多个物理节点上的数据库需要在每天某时来同步表中的数据,对于某个指定节点上的某个表发生的变化(增量)可以通过对该表执行的SqlCommand来记录,当同步过程发生时,需要对其它所有节点上的同名表执行相同的SqlCommand。
(本文转自梦想风暴的blog)一个朋友发了封mail问了几个问题,其中的一个是关于IoC和DI的:Inversion of Control和Dependency Injection 是什么关系,我认为两个词代表的是同一个意思,只是两种不同的表示,对吗? 下面是我对这个问题的一些理解。
以前曾写过一篇“关于跨程序集的反射”的blog,关于跨程序集加载类型,文中使用的是方法是:先加载目标类型所在的程序集,再使用Assembly. GetType方法获取类型。文后Luna兄的评论说,可以直接使用Type.GetType(",")来加载类型,当初我查了MSDN,MSDN中也说到了这一点,我也就记住了这个解决方案。
上一篇主要讲到了Tcp通信层中的核心组件――Tcp组件的实现,Tcp组件是整个通信层的消息驱动源,甚至,可以将Tcp组件看作是我们整个服务器系统的消息驱动源,消息处理过程从这里引发。类似的消息驱动源还有发布的WebService接口、Remoting接口等。
2006年已经来临,回首刚走过的2005,心中感慨万千。在人生和生活的目标上,有了清晰明确的定位,终于知道了自己喜欢什么样的生活,喜欢什么样的生活方式;在技术上,成熟了不少,眼界也开阔的不少,从面向对象到组件、从.Net到J2EE、从微软到开源,颇有收获。
在Web开发中,经常需要使用Session来保存特定用户的信息,在我们的程序中很多地方散落着类似下面的语句: int userAge = (int)this.Session["UserAge"]; 我们知道,Session中存放的是键值对,键是string类型的,如果我们一不小心把上面的语句写成这样: int userAge = (int)this.Session["UseAge"]; 编译期不会发现这个错误,但运行时一定会抛出异常,这是在程序中直接操作Session可能引发的问题之一。
1、大多数人想要改造这个世界,但却罕有人想改造自己。 2、积极的人在每一次忧患中都看到一个机会, 而消极的人则在每个机会都看到某种忧患。 3、莫找借口失败,只找理由成功。
最初Peter Deutsch从J2EE的企业开发中总结了7大谬误,后来,James Gosling在其基础上增加了一条,再后来,Ted Neward又在其上增加了两条,总共为“十大谬误”。这段时间正在看两本书:《Effective Enterprise Java》和《J2EE AntiPatterns》,恰好两本书都提到了“分布式计算的*大谬误”,我在这里简单引荐一下这“分布式计算十大谬误”:)(1)网络是可靠的。
设想这样一种场景:我们的服务系统提供一系列的功能服务,而以后会有更多新的功能服务增加进来,也可能出现功能服务需要被更改或移除的情况。对于这样的服务系统,一个常见的基本的要求就是,在添加/移除/更新功能服务的时候不能停止的服务系统的运行。
手头上的一个项目使用了Spring.net的AOP了处理程序的异常,一不小心就掉进了陷阱,这里记录下来,希望对后来者有所帮助。Spring.net的AOP实现是通过运行时创建动态的AOP代理来完成的。
在.Net Remoting的应用中,经常碰到需要预定Remoting Object的事件的情况,要能使远程事件发布/预定如预期中的进行,需要注意如下问题:1. Remoting 配置 在Remoting配置文件中,需要将typeFilterLevel设置为Full,否则,将出现RemotingHandler无法序列化的异常。
在DataGrid的web版控件中提供了自动分页的功能,但是我从来没用过它,因为它实现的分页只是一种假相。我们为什么需要分页?那是因为符合条件的记录可能很多,如果一次读取所有的记录,不仅延长获取数据的时间,而且也极度浪费内存。
通常我们在程序中需要调用WebService时,都是通过“添加Web引用”,让VS.NET环境来为我们生成服务代理,然后调用对应的Web服务。这样是使工作简单了,但是却和提供Web服务的URL、方法名、参数绑定在一起了,这是VS.NET自动为我们生成Web服务代理的限制。
在习惯了使用基于接口的编程之后,经常会遇到这样的问题,比如,B组件需要使用实现了IA接口的A组件,但是如果在没有A组件的情况下B组件也可以正常工作,像这样: public interface IA { void DoWork1() ; void ...
昨天买了一本《Effective C#》,看了几个Item,虽然没有当初读《Effective C++》时的那般震撼,但是也收获不少。把其中的要点记录于下,有些条款加上了自己的理解,权当作读书笔记吧 :-)Item 1: Always Use Properties Instead of Accessible Data Members 这个是地球人都知道的条款了。
昨天看到某个公司招聘出的一道题目,题目是这样的:判断任意三个点是否构成三角形,以及某个点是否位于指定的三角形内。 关于这个问题,我给出了自己的答案,首先解决第一个问题: /// /// IsTriangle 判断集合中的头三个点PointF是...
以前空闲的时候用C#实现的路径规划算法,今日贴它出来,看大家有没有更好的实现方案。关于路径规划(最短路径)算法的背景知识,大家可以参考《C++算法--图算法》一书。 该图算法描述的是这样的场景:图由节点和带有方向的边构成,每条边都有相应的权值,路径规划(最短路径)算法就是要找出从节点A到节点B的累积权值最小的路径。
出手自Rod Johnson的《J2EE Development without EJB》是一本难得的好书,无论是对于Java程序员,还是.NET程序员。特别是对于.NET程序员,.NET平台的企业级应用还不是很多,.NET平台上的实用性的架构也远远不及J2EE这么成熟,所以我们.NET开发人员绝对有必要Open自己,到Java的世界去看看。
前文介绍了异常关闭器的AOP实现,而权限管理也是一个AOP可以大展拳脚的地方,下面就来看看如何使用EsbAOP实现权限管理。 首先要解决的问题是如何判断用户是否拥有调用某个操作的权限,这个判断是由各个应用程序自己实现了,为了统一对权限的判断,所以我们指定了接口IPermissionVerifier: /// /// IPermissionVerifier 用于验证当前用户对目标类的目标方法的调用权限是否足够。
以我自己的异常处理经验,我通常会在UI事件处理函数或线程启动函数中截获所有的异常,然后对截获的异常作特定的处理--很多情况下,是显示一个错误信息给用户,或记录异常日志!在这“很多情况下”,我都需要做相同的工作,首先是用try...catch把UI事件处理函数或线程启动函数中的所有代码围起来,然后,可能就是MessageBox.Show(ex.Message)或其它的处理。
EsbAOP是EnterpriseServerBase类库中的轻量级AOP框架,它实现了AOP的主要思想--对方法调用进行截获,并加入自定义的预处理、后处理。 EsbAOP与其它很多开源的AOP实现有些不同,其不同之处主要在于EsbAOP并没有严格的实现AOP理论的各种设施,但是EsbAOP非常实用,在后续的文章中,大家可以看到EsbAOP是如何运用于实际的系统开发中的。
事件通知服务用于解决多个应用程序之间的事件发布与预定的问题。在.NET平台上,跨应用程序的事件发布/预定通常以Remoting作为底层的通信基础,在此基础之上,事件通知服务使用中介者模式来简化跨应用程序的事件通知问题。
在开发中,经常会遇到这种情况,在A.dll中需要反射B.dll中的类型,如果稍不注意,就会产生运行时错误。关于跨程序集的反射,记住两点就可以:(1)如果使用typeof,编译能通过,则跨程序集的反射一定可以正常运行。
当UI动作引发一个耗时的计算时,我们经常需要将这个耗时的过程放到后台线程中去完成,然后获取该过程的结果。使用.NET提供的默认设施,无论是使用Thread还是使用异步调用,细节都比较繁琐。
类厂服务的主要功能是简化创建具体工厂任务,使工厂访问代码和工厂创建代码解藕。类厂服务是以抽象工厂模式为基础,并且在其上进行再综合。 在正式进入正题之前,为了方便后面的叙述,先要澄清一些概念,把上下文(Context)搭建起来,然后,我们再在这个上下文中进行讨论。
所谓企业开发基础设施,指的是为那些几乎所有的企业开发都会遇到的共同的基础性的问题提供服务的设施,比如事务、日志、权限等等。其中很多设施都会以AOP的方式实现,有些则可能以类库的方式提供。我也一直在积累这方面的AOP组件和类库。
人们都善于用直观简单的方式来理解事物,我也坚信,所有优秀的解决方案都是直观而简单的,我喜欢直观而简单的解决方案,也许在找到直观简单的解决方案之前,我们已经尝试了用很多复杂费解的方式来解决问题。
相比于写代码,我更喜欢写能自动产生代码的生成器,和许多人一样,我讨厌写重复的代码,这种重复包括字面的重复和结构的重复、还有思想的重复。 在日常的开发过程中,一旦我发现一种需要经常使用的元素(类/结构/方法),我就将它整理出来,所谓整理主要是做这样的工作:重构、最大限度降低这个元素与其它元素的耦合性、最大限度地扩展该元素的适用范围、精简算法。
一个系统不仅需要优秀的分析和设计,更需要一个良好的过程将其从蓝图转化为实现。这个过程中最重要的是对团队的管理,也就是人的管理。一个优秀的团队和一个糟糕的团队的效能是天壤之别,她们之间的比例不是1:100或1:1000这样量化的数字能够表示的。
软件架构师的主要职责是什么?是抉择、是权衡。把软件称为艺术一点都没有夸张,可以说软件是科学、工程、与艺术的结合体。软件的艺术体现在权衡上。在这一期的《程序员》杂志上看到了一篇“鱼与熊掌--完美主义架构师的梦魇”,其中关于权衡要素的论述正切合我之所想,现将主要部分转摘如下,如果想了解更详细内容,请在本期程序员阅读全文。
事件是面向组件开发的必要特性之一,但C++不直接支持事件,没关系,我自己实现了一个,感觉很好用,分享给大家! 最开始打算用函数指针模拟事件,但由于C++中成员函数指针不能和void*相互强转,而且 typedef中不能含有模板,所以才不得已以接口继承实现。
1.异常处理相对于返回错误代码的一个最大优点在于,异常可以被自动传递,这样,在编程时异常更加难以被忽视。 2.通常,只在最上层(一般是UI层)捕捉异常。如果要在其它层捕捉异常,除非是下列情况之一: (1)能够处理该异常,或者 (2)能够忽略该异常,或者 (3)需要转换该异常为其它特定异常后抛出新异常 3.UI层捕获异常后,可以 (1)将无关紧要的异常忽略。
很久以前我就考虑这样一个问题:有这样一个函数,它的功能是从一个整数集合中返回最大的那个数,如何设计这个函数的签名了?当时没有得出令自己满意的答案,所以就搁浅了。今天重新思考,终于有所悟!现在把我思索的整个过程展现于此。
以前一直在csdn的blog上活动(http://blog.csdn.net/zhuweisky),由于种种原因,现在全面迁移到博客园来,感觉这里的氛围更好一些。借此机会先和各位博客打个招呼,多多指教!但愿我们的博客园越办越好,成为博客们温馨的家!