【精选】[Karrigell]Karrigell 网络框架结构分析[Karrigell]Karrigell 网络框架结构分析.doc

【精选】[Karrigell]Karrigell 网络框架结构分析[Karrigell]Karrigell 网络框架结构分析.doc

  1. 1、本文档共9页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
【精选】[Karrigell]Karrigell 网络框架结构分析[Karrigell]Karrigell 网络框架结构分析

Karrigell 网络框架结构分析? ?? 我喜欢有灵气的程序作品,喜欢看tvb电视剧,趁着欣赏tvb的布衣神相的同时,我决定分析一下Karrigell的框架代码,看看它是怎么实现的,也作为写zope结构分析过程中的一个插曲^_^。 ?? 我还是喜好从一个框架的启动开始,一直跟踪它的工作流程,从而分析它各种功能的协作与实现。 ??? ?? Karrigell使用的是一个异步模型,但是它不是直接使用asyncore和asynchar标准模块,原作者说是为了使处理的逻辑简单一点,但是Server的算法和asyncore的算法是一样的。(可以看看我的zope的结构分析中的medusa篇)。Karrigell的server其实非常简单就是soocket-bind-listen-accept-new client甚至可以说它只是一个通用的server,而不是httpserver(不过每一个server,在最地层都是这个样子的啦,其实我想说的是,在接受连接这一步上,Karrigell使用的是自己的手工代码,而不是现有的http server库。(zope使用的是medusa) ?? 在接收到新的请求(accept成功后,KG创建一个asyncRequestHandler实例与它对应,并把它加入到监听队列中,这个队列是一个字典)。也就是说所有的是与协议相关的事情和响应的流程都是通过这个asyncRequestHandler(继承DialogManager和KarrigellRequestHandler)来实现的,与asyncore的设计一样,当server监听到对应的请求有数据到达时,或者可以发送数据时,就会调用DialogManager的handle_read和hande_write,从而实现数据处理。 ?? 先看handle_read,也许是类似的东西看多了,KG在完成的工作我们可以猜到:首先是收集输入的数据,然后就是解析头部,一般来说头部都只要解析到/r/n/r/n就可以了,因为python的标准模块cgi.FieldStorage会帮我们把POST或者是PUT的数据以树的结构解析出来(cgi.FieldStorage具体的处理流程可以看看我前面写的cherrpy3结构分析)。当然还要加上基本的错误处理,否则KG就会很脆弱了。 ? ?? 看看原代码,的确和我想象的差不多,不过这里KG做了完整头部的缓冲。这里有一个parse_request的调用这个函数是来自于BaseHTTPRequestHandler中的,正如KG所说的,其实它自己并不解析HTTP协议,所有的东西都是借助python的标准模块SimpleHTTPServr或相关的功能模块完成。所以在本分析只对于这些标准模块的结合的细节上说明,至于SimpleHTTPServer的工作方式,留在分析SimpleHTTPServer的时候再展开。 ?? 由于在初始化的过程中DialogManager并没有调用基类的__init__,所以DialogManager必须实现一些标准模块中需要的调用接口,那个wfile就是为了要实现这样的协作接口而引入的,同时一些也要覆盖一些基本的成员函数,例如;do_GET等。这里有一点需要注意的,对于POST方式提交的数据,KG做了一件非常傻的事,就是自己先缓冲提交的数据(包括:把过大的上传信息保存为临时文件,然后又通过cgi.FieldStorage来重新组织这些数据,在KG的设计中这是没有办法避免的,因为KG的设计是基于复用IO,这种模式的最大的特点(也可以说是优点/局限)就是单线程,任何的数据交互都不能阻塞,否则导致整个系统阻塞)。所以为了不阻塞,KG必须在数据完成接收完前(可以调用cgi.FieldStorage进一布分析上传的数据前)进行自己缓存,而为了节省内存,它又不可避免地创建临时文件。 ?? 在处理完Client提交地数据以后,KG很简单地根据请求地命令调用(do_XXX/GET/HEAD/POST),其实这些调用最后都会转到self.pre_handle_data()在整个函数中做了一个很奇怪地操作,那就是将self.wfile清空,到这里为止,我不能想象这个操作到底有什么含义(在后面的分析中我们可以看到它的作用)?这个self.wfile只有在parse_request调用时用于产生(保存出错的信息,但是这里却把它清空了??难道这是为了表示一个结束??还是在后面进行的处理需要重写这个self.wfile?现在先不管),接着就是调用self.handle_data() ?? 这个self.handle_data()做的一件事就是寻路,也就是根据前面parse_request的结果得到对应的文件,这个只是用户请求的文件,不一定是真实存在

文档评论(0)

tazhiq2 + 关注
实名认证
内容提供者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档