Lighttpd源码分析之状态机与插件
Lighttpd启动时完成了一系列初始化操作后,就进入了一个包含11个状态的有限状态机中。
每个连接都是一个connection实例(con),状态的切换取决于con->state。
lighttpd经过初步处理后将con的基本信息初始化,而插件对事件的处理就是针对con进行的,它拿到con后按照业务需要进行相应处理,然后再交还给lighttpd,lighttpd根据con中的信息完成响应。
状态定义如下:
- typedef enum
- {
- CON_STATE_CONNECT, //connect 连接开始
- CON_STATE_REQUEST_START, //reqstart 开始读取请求
- CON_STATE_READ, //read 读取并解析请求
- CON_STATE_REQUEST_END, //reqend 读取请求结束
- CON_STATE_READ_POST, //readpost 读取post数据
- CON_STATE_HANDLE_REQUEST, //handelreq 处理请求
- CON_STATE_RESPONSE_START, //respstart 开始回复
- CON_STATE_WRITE, //write 回复写数据
- CON_STATE_RESPONSE_END, //respend 回复结束
- CON_STATE_ERROR, //error 出错
- CON_STATE_CLOSE //close 连接关闭
- } connection_state_t;
下面就是lighttpd的状态机:
在每个连接中都会保存这样一个状态机,用以表示当前连接的状态。
在连接建立以后,在connections.c/connection_accpet()函数中,lighttpd调用connection_set_state()函数,将新建立的连接的状态设置为CON_STATE_REQUEST_START。在这个状态中,lighttpd记录连接建立的时间等信息。
整个状态机的核心函数是connections.c/ connection_state_machine()函数。
函数的主体部分删减之后如下:
- int connection_state_machine(server * srv, connection * con)
- {
- int done = 0, r;
- while (done == 0)
- {
- size_t ostate = con -> state;
- int b;
- //根据当前状态机的状态进行相应的处理和状态转换。
- switch (con->state)
- {
- case CON_STATE_REQUEST_START: /* transient */
- //do something
- case CON_STATE_REQUEST_END: /* transient */
- //do something
- case CON_STATE_HANDLE_REQUEST:
- //do something
- case CON_STATE_RESPONSE_START:
- //do something
- case CON_STATE_RESPONSE_END: /* transient */
- //do something
- case CON_STATE_CONNECT:
- //do something
- case CON_STATE_CLOSE:
- //do something
- case CON_STATE_READ_POST:
- //do something
- case CON_STATE_READ:
- //do something
- case CON_STATE_WRITE:
- //do something
- case CON_STATE_ERROR: /* transient */
- //do something
- default:
- //do something
- break;
- }//end of switch(con -> state) ...
- if (done == -1)
- {
- done = 0;
- }
- else if (ostate == con->state)
- {
- done = 1;
- }
- }
- /* something else */
- /* 将fd加入到fdevent系统中,等待IO事件。
- * 当有数据可读的时候,在main函数中,lighttpd调用这个fd对应的handle函数,
- * 这里就是connection_handle_fdevent()函数。
- * 这个函数一开始将连接加入到了joblist(作业队列)中。
- */
- switch (con->state)
- {
- case CON_STATE_READ_POST:
- case CON_STATE_READ:
- case CON_STATE_CLOSE:
- fdevent_event_add(srv->ev, &(con->fde_ndx), con->fd, FDEVENT_IN);
- break;
- case CON_STATE_WRITE:
- /* request write-fdevent only if we really need it
- * - if we have data to write
- * - if the socket is not writable yet
- */
- if (!chunkqueue_is_empty(con->write_queue) &&
- (con->is_writable == 0)&& (con->traffic_limit_reached == 0))
- {
- fdevent_event_add(srv->ev, &(con->fde_ndx), con->fd, FDEVENT_OUT);
- }
- else
- {
- fdevent_event_del(srv->ev, &(con->fde_ndx), con->fd);
- }
- break;
- default:
- fdevent_event_del(srv->ev, &(con->fde_ndx), con->fd);
- break;
- }
- return 0;
- }
这个函数首先根据当前的状态进入对应的switch分支执行相应的动作,然后根据情况进入下一个状态。
跳出switch语句之后,如果连接的状态没有改变,说明连接读写数据还没有结束,但是需要等待IO事件,这时跳出循环,等待IO事件。
如果在处理的过程中不需要等待IO事件,那么在while循环中,连接将被处理完毕并关闭。
在我们的main函数中,之前讨论过,在一个while循环中,处理超时,处理IO时间,之后有下面这段代码:
- for (ndx = 0; ndx < srv->joblist->used; ndx++) {
- connection *con = srv->joblist->ptr[ndx];
- handler_t r;
- connection_state_machine(srv, con);
- switch(r = plugins_call_handle_joblist(srv, con)) {
- case HANDLER_FINISHED:
- case HANDLER_GO_ON:
- break;
- default:
- log_error_write(srv, __FILE__, __LINE__, "d", r);
- break;
- }
- con->in_joblist = 0;
- }
这段代码对joblist中的所有连接依次调用connection_state_machine()函数进行处理。
下面说明下各状态的主要内容:
- CON_STATE_CONNECT
- 清除待读取队列中的数据-chunkqueue_reset(con->read_queue);
- 置con->request_count = 0。(本次连接还未处理过请求)
- CON_STATE_REQUEST_START /*transient */
- 记录事件起始时间;
- con->request_count++(一次长连接最多可以处理的请求数量是有限制的);
- 转移到CON_STATE_READ状态。
- CON_STATE_READ和CON_STATE_READ_POST
- connection_handle_read_state(srv,con);
- CON_STATE_REQUEST_END /*transient */
- http_request_parse(srv, con);
- 解析请求,若是POST请求则转移到CON_STATE_READ_POST状态,
- 否则转移到CON_STATE_HANDLE_REQUEST状态。
- CON_STATE_HANDLE_REQUEST
- http_response_prepare(srv, con);
- 函数中调用
- handle_uri_raw;
- handle_uri_clean;
- handle_docroot;
- handle_physical;
- handle_subrequest_start;
- handle_subrequest。
- 如果函数返回了HANDLER_FINISHED,且con->mode!=DIRECT(事件已经被我们的业务插件接管),
- 则直接进入CON_STATE_RESPONSE_START。
- 否则lighttpd会做一些处理后再进入CON_STATE_RESPONSE_START状态。
- 如果函数返回了HANDLER_WAIT_FOR_FD或
- HANDLER_WAIT_FOR_EVENT,
- 状态依旧会停留在CON_STATE_HANDLE_REQUEST,等待事件或数据。
- 如果函数返回了HANDLER_ERROR,进入到CON_STATE_ERROR状态。
- CON_STATE_RESPONSE_START
- connection_handle_write_prepare(srv,con);
- CON_STATE_WRITE
- connection_handle_write(srv,con);
- CON_STATE_RESPONSE_END
- 调用插件的handle_request_done接口。
- 如果是长连接,重新回到CON_STATE_REQUEST_START;否则调用插件的handle_connection_close接口。
- 执行connection_close(srv, con);和connection_reset(srv, con);将连接关闭。
- CON_STATE_ERROR /* transient */
- 调用插件handle_request_done;
- 调用插件handle_connection_close;
- 执行connection_close将连接关闭。
- CON_STATE_CLOSE
- connection_close(srv, con);将连接关闭。
以上是状态机的概况。
总览了状态机,我们知道状态机会针对相应的阶段对事件进行处理,那么状态机是如何处理这些事件的?
事实上,对于事件的处理,一部分是由lighttpd完成的,而一部分是由插件完成的。插件中那些负责事件处理的接口分布在某几个状态中。我们只需在插件的各个阶段完成指定工作并返回相应的返回值,就可以促使状态机完成状态切换,完成事件的整套处理流程,并最终由lighttpd完成事件的响应。
在插件中,我们可以编写代码来注册lighttpd提供的回调接口,lighttpd在初始化阶段、状态机执行阶段、退出阶段会分别调用这些回调函数,完成插件的实例化,初始化,连接重置,事件处理,插件释放等功能。
要了解lighttpd对插件的调用方式,需要明白一个概念:事件接管。
对于每个事件,都有一个mode字段(con->mode)。该字段的定义:
typedef enum { DIRECT, EXTERNAL } connection_type;
连接对象有一个字段mode用来标识该连接是最初由服务器accept产生的客户端连接还是插件产生的其他辅助连接,当mode=DIRECT时表示对应连接由lighttpd服务器accept产生,mode!=DIRECT时表示对应连接是由插件产生的。
事件(con)初始化时mode是DIRECT;connection_reset(srv,con);
lighttpd在大部分流程中会在入口检查到mode != DIRECT时直接返回GO_ON。即:此事件由用户插件接管,lighttpd不参与。
用户编写的插件应通过将mode置为插件自身的ID达到接管的作用。插件ID是在插件加载时由插件的加载顺序确定的,是插件的唯一标识。
用户编写插件在每个接口的一开始应该判断mode是否等于自身的ID,若相等才能继续执行,否则直接退出,返回GO_ON。
了解了以上概念之后,我们就可以理解lighttpd对插件的调用方式了:
在lighttpd需要调用插件某一个阶段的接口函数时,会对所有插件注册在该处的接口顺序调用,顺序与插件加载顺序相同。例如:调用uri_raw接口,会先调用A插件的mod_A_uri_raw,然后调用B插件的mod_B_uri_raw,直到将所有已加载插件这个位置的接口全部调用完成。但实际处理这次事件通常只有一个插件,即插件ID与mode相同的那个插件。
因此,假设在CON_STATE_HANDLE_REQUEST状态,lighttpd调用了插件的handle_uri_raw接口,但是我们有多个插件,每个插件都注册了handle_uri_raw这个接口,lighttpd也能辨别出要使用哪个插件。
如果插件在处理事件的过程中,想让lighttpd接管,还需要把mode置为DIRECT才行。
以上是lighttpd状态机和插件的总览概况。
Lighttpd源码分析之状态机与插件相关推荐
- MyBatis 源码分析 - 插件机制
1.简介 一般情况下,开源框架都会提供插件或其他形式的拓展点,供开发者自行拓展.这样的好处是显而易见的,一是增加了框架的灵活性.二是开发者可以结合实际需求,对框架进行拓展,使其能够更好的工作.以 My ...
- MyBatis源码分析(一)MyBatis整体架构分析
文章目录 系列文章索引 一.为什么要用MyBatis 1.原始JDBC的痛点 2.Hibernate 和 JPA 3.MyBatis的特点 4.MyBatis整体架构 5.MyBatis主要组件及其相 ...
- 【Android 插件化】VirtualApp 源码分析 ( 启动应用源码分析 | HomePresenterImpl 启动应用方法 | VirtualCore 启动插件应用最终方法 )
文章目录 一.启动应用源码分析 1.HomeActivity 启动应用点击方法 2.HomePresenterImpl 启动应用方法 3.VirtualCore 启动插件应用最终方法 一.启动应用源码 ...
- 【Android 插件化】VirtualApp 源码分析 ( 目前的 API 现状 | 安装应用源码分析 | 安装按钮执行的操作 | 返回到 HomeActivity 执行的操作 )
文章目录 一.目前的 API 现状 二.安装应用源码分析 1.安装按钮执行的操作 2.返回到 HomeActivity 执行的操作 一.目前的 API 现状 下图是 VirtualApp 官方给出的集 ...
- 【转载】SharpDevelop源码分析(四)SharpDevelop的AddInTree View 插件
SharpDevelop的AddInTree View 插件 http://www.cnblogs.com/passos/archive/2004/10/15/52513.html 自从SharpDe ...
- Kafka源码分析10:副本状态机ReplicaStateMachine详解 (图解+秒懂+史上最全)
文章很长,建议收藏起来,慢慢读! Java 高并发 发烧友社群:疯狂创客圈 奉上以下珍贵的学习资源: 免费赠送 经典图书:<Java高并发核心编程(卷1)> 面试必备 + 大厂必备 +涨薪 ...
- 云客Drupal源码分析之插件系统(下)
以下内容仅是一个预览,完整内容请见文尾: 至此本系列对插件的介绍全部完成,涵盖了系统插件的所有知识 全文目录(全文10476字): 实例化插件 插件映射Plugin mapping 插件上下文 具 ...
- 云客Drupal源码分析之插件系统(上)
各位<云客drupal源码分析>系列的读者: 本系列一直以每周一篇的速度进行博客原创更新,希望帮助大家理解drupal底层原理,并缩短学习时间,但自<插件系统(上)>主题开始博 ...
- Android 双开沙箱 VirtualApp 源码分析(四)启动插件 Service
上一章:Android 双开沙箱 VirtualApp 源码分析(三)App 启动 原生 Service 创建过程 首先有必要了解一下原生 framework 对 Service 的创建,因为在 VA ...
最新文章
- [置顶] WindowsPhone之我见
- java发送加密报文_RSA加密---从后台到客户端实现报文加解密
- 开源资产管理系统_开源cmdb来啦 通用CMDB 开源资产管理系统
- 在计算机领域做研究的一些想法-- 转载
- C++ cin.putback()输入【已知行数】但【未知每行数字个数】的思路
- linuxpython拍照_linux下python抓屏实现方法 -电脑资料
- LeetCode 660. 移除 9(9进制)
- 学习Spring Boot:(十九)Shiro 中使用缓存
- java调用lua 路径_luacom打开中文路径的Word文件
- git进阶(撤销pull、撤销merge、撤销add)
- React后台管理系统-订单管理
- python 超像素分割
- 【气象检测项目】BME280
- 博世中国的战略与战术,如何应对复杂多变的中国市场需求
- stub,存根是什么?
- Redis 使用lua脚本最全教程
- Excel 数据统计小技巧
- CTF-Crypto学习1(软件加壳、反汇编、Babe64、Rijndael密码算法)
- 贷超、贷超分销系统 贷超分销模式 简介
- MySQL攻略(2)