入门

个人习惯编译选项

./configure –with-features=huge –enable-cscope –enable-fontset –enable-multibyte –enable-perlinterp –enable-rubyinterp –enable-pythoninterp

工作目录

:pw[d] 显示当前工作目录
:cd[!] {path} 工作目录切换到path

移动: h j k l 0 ^ $ e E b B w W f F t T ; , % gg G [ ]
编辑: d y p r c o

在vim中还存在如x,s等编辑命令,这些命令只是 编辑命令 + 移动命令 的简答组合,如x X D C s S Y

简单总结大小写操作命令的区别:

作用于行首: I
作用于行尾: D,C,A,R
作用于整行: Y,S,V
作用于逆方向: X,F,P,O,N
搜索时大小写相关: \C
改变大小写: gU

关于编辑命令,需要说明一点: x,d,c这些命令会把脏数据置入vim的粘贴板(所谓脏数据,也就是被命令删除或改变的那部分数据).

利用vim的这个特性,我们可以轻易的实现文本剪切,如交换两个字符,交换两行文本,甚至是交换两段文本:

16进制编辑,码农必备,lol

:%!xxd 16进制编辑
:%!xxd -r 文本编辑

保存会话

Session可以忠实地记录vim当前的视图,如windows和tabs,甚至是高亮.真是谁用谁知道.

:mks[!] [file] 把当前视图保存到file,如file未指定,则缺省为Session.vim
vim -S Session.vim 打开Session.vim,也就是Reload view,重新打开视图.

可视化编辑

v: charwise
V: linewise

Ctrl-V: blockwise,后文介绍.

gv 重选上次选中的区域,谁用谁知道

区域

% 作用于当前打开的整个文件
‘<,'> 作用于当前选中的区域,其中,’<表示选中区域第一行,'>表示选中区域的最后一行.
{num1},{num2} 作用于从第num1行到第num2行

内置命令

. 当前行,比如说,想要作用于从当前行开始的总共8行文本,则可以8:,
$ 最后一行,

:[range] substitute/from/to/[flags] 替换文本

:[range] copy {num1} {num2} 复制文本

:[range] Tabluarize /{char1} 对齐文本

甚至可以是:
:[range] TOhtml 文本转为html

查找: / ? * #

:help pattern

/ 向前查找keyword
? 向后查找keyword

n 重做最后一次/或?
N 反方向重做最后一次/或?

\c 查找时忽略大小写
\C 查找时大小写相关

\< 表示一个词的开始
\> 表示一个词的结束

tabs

:help tabpage

:tabnew 新建tab
:tabclose 关闭当前tab
:tabedit {file} 新建tab,并在新创建的tab打开file (等价于: tabnew后:edit {file})
:tabmove {idx} 把当前tab移动到第idx tab之后

gt 切换到下一tab
gT 切换到上一tab
{idx}gt 切换到第idx tab

为了方便,我的vimrc配置如下:

536 map <A-1> 1gt
537 map <A-2> 2gt
538 map <A-3> 3gt
539 map <A-4> 4gt
540 map <A-5> 5gt
541 map <A-6> 6gt
542 map <A-7> 7gt
543 map <A-8> 8gt
544 map <A-9> 9gt

尽管很dirty,好歹能工作.

windows

:sp {file} 横向(horizontally)切割窗口,并在新窗口打开file
:vsp {file} 竖向(vertically)切割窗口,并在新窗口打开file

h 切换到左侧窗口
j 切换到下方窗口
k 切换到上方窗口
l 切换到右侧窗口

如果对所有vimer的配置做统计,下面这段配置绝对是出现频率最高的:

577 map <C-h> <C-w>h
578 map <C-j> <C-w>j
579 map <C-k> <C-w>k
580 map <C-l> <C-w>l

省下的绝对不仅是一次w按键,vimer你懂的.

关于窗口的扩大缩小, :help window-resize

marks

:help marks

我用得最多的marks操作是:

‘[ 跳到上一次被改变(changed)或者复制的文本段的第一个字符
'' 跳回上一次跳转的地方
'^ 跳到插入模式最后一次结束的地方
'. 跳到上一次文本被修改的地方

缩进与对齐

:help indent.txt

> 向右缩进shiftwidth个字符大小
< 同上,但是向左缩进
= 对齐文本

>,<.=这三个命令的作用域既可以是选中的一段文本,也可以是一个文本对象(后文进阶部门会解释).

进阶

[N]<command> 执行<command>N次

NOTE: [N]<command><range>和<command>[N]<range>是不一样的,如:d3w和3dw两个操作虽然看似一样,但实际上它们在vim内部的行为是有本质区别的:
d3w表示一次删除3个w,而3dw表示一次删除一个w,重复3次.

[start pos]<command>[end pos] 从start pos开始执行<command>到end pos,[]表示其内部的命令不是必须的,也就是说,start pos和end pos都不是必须的.

gg=G和^y$是两个极好的例子:

gg=G 对齐整个文件(gg跳到第一行,=对齐,G最后一行)
^y$ 从当前行行首复制至行尾(^行首,y复制,$行尾),你能看出^y$和Y的区别吗?

NOTE: start pos和end pos仅仅表示一个位置(黑话叫锚点),至于如何从光标移动到start pos或者end pos,vim并没有做出要求.于是,我们可以轻松地敲出如下命令,大大提高文本编辑的效率:

df=, yf=, cf=, vf= 从当前字符开始删除(复制,改变,选中),直到遇到=之后
dt”, yt”, ct”, vt” 从当前字符开始删除(复制,改变,选中),直到遇到”之前

text object

:help text-objects

<action>i<object> 作用于对象内部(i: inner)
<action>a<object> 作用于整个对象(a: an)

其中,action可以是v,d,c,y,甚至可以是>,<等
而object可以是w,W,s,p,b,B,以及各种成对符号,如',",<,{,(,[等

有了文本对象,写起代码来更是得心应手,如:

向右缩进一段代码: >i{
删除(复制,改变,选中)光标所在单词: diw, yiw, ciw, viw
删除(复制,改变,选中)”"内所有文本: di”, yi”, ci”, vi”
删除(复制,改变,选中)”"号内所有文本,包括引号本身: da”, ya”, ca”, va”

visual block

${select region}<commands>

块操作可以一次编辑多行文本,对有规律的编辑需要实在是一大利器.如:

宏

所谓宏,就是一段录制好的操作.

q${register}<commands>q 录制commands到寄存器register
[N]@register 重放寄存器register中的宏N次

看起来,宏和块操作的区别非常明显: 宏“可以认为”是linewise,而块操作是blockwise,也就是说,宏对应的是几行文本,块操作对应的则是选中的block.

从这明显的区别中我们可以推出一个重要的结论: 宏中的锚点有相对的概念,而块操作是绝对的.比如说,行尾就是一个最简单的相对概念,每一行的行尾所在的锚点可能都不一样,但这丝毫不影响宏正确的在所有行行尾插入一段文本.而在块操作中,命令A(在行尾插入)对应的语义却变成了block的尾部,显然,”block的尾部”这一概念对block中的所有行都是相同的,也就是所谓绝对的位置.

折腾

配色

:help syntax

vim自带了许多配色方案(在这里有各种预览),可以用colorscheme命令选择,如: colorscheme desertEx

哪怕再性感的配色,看久了也会生烦,所幸vim自带了synIDattr函数,在vimrc中加入如下脚本:

215 nmap <C-S-P> :call <SID>SynStack()<CR>
216 function! <SID>SynStack()
217    if !exists("*synstack")
218       return
219    endif
220    echo map(synstack(line(‘.’), col(‘.’)), ‘synIDattr(v:val, "name")’)
221 endfunc

:so %安装后就可以通过Ctrl-Shift-P组合键方便地查看某段文本的ID了.

得到文本ID之后,需要通过指定颜色来实现自定义.vim支持rgb配色(#445599之流),可是,身为毫无艺术感的二逼后台开发,我自然更偏爱skyblue这类见其名即可知其意的配色方案了:).为了让生活容易些,可以:runtime syntax/colortest.vim直接预览,谁用谁知道.

vim的强大总是让人爱不释手,我们甚至可以自定义ID,比如说,我的代码中TODO横行,为了更直观的显示TODO项,于是便有了这段配置:

60 highlight RipGroup ctermbg=yellow cterm=none ctermfg=black
61 match RipGroup /TODO/

btw,在终端下切记要打开256色: set t_Co=256

再次btw,简单回答一个可以很好的区分vim新手和老鸟的问题,对Alt键的map为何在终端模式下如此虐心? 因为终端他妈的自动在Alt前面加了Esc前缀,这该让人多胸闷啊.

代码折叠

:help fold.txt

vim支持多种折叠方法(fold methods),如indent,expr,marker,syntax等.我偏向于按syntax折叠,配置如下:

716 set foldenable           " enable folden
717 set foldmethod=syntax    " manual : Folds are created manually.
718                          " indent : Lines with equal indent form a fold.
719                          " expr   : ‘foldexpr’ gives the fold level of a line.
720                          " marker : Markers are used to specify folds.
721                          " syntax : Syntax highlighting items specify folds.
722                          " diff   : Fold text that is not changed.
728
729 "set foldclose=all
730 " use space to folden
731 nnoremap <space> @=((foldclosed(line(‘.’)) < 0) ? ‘zc’ : ‘zo’)<CR>

其中,.表示当前行,zo表示展开,zc表示折叠,整行配置的意思就是通过空格键折叠代码,效果如下:

vim默认在搜索和undo时会展开你辛辛苦苦设置好的折叠,这是让人非常难受的,所以我会追加这么一段配置:

726 set foldopen-=search     " dont open folds when I search into thm
727 set foldopen-=undo       " dont open folds when I undo stuff

编码

249 set encoding=utf-8
250 set fileencodings=ucs-bom,utf-8,cp936,gb18030,big5,gbk,euc-jp,euc-kr,latin1
251 if has("win32")
252     set fileencoding=chinese
253     " fix menu gibberish
254     source $VIMRUNTIME/delmenu.vim
255     source $VIMRUNTIME/menu.vim
256     " fix console gibberish
257     language messages zh_CN.utf-8
258 else
259     set termencoding=utf-8
260     set fileencoding=utf-8
261 endif

gui设置

简单介绍一下gvim的设置,首先是字体,我的配置如下:

229 set guifont=Courier_New:h9:cANSI
231 set guifontwide=幼圆:h10:cGB2312

guifont对应的应为字体,guifontwide对应所谓的宽字节字体,中文就是宽字节.

我个人倾向于隐藏gvim菜单栏,工具栏,滚动条等,以最大化代码可视面积:

237 if has("gui_running")
238     " set guioptions-=m  " remove menu bar
239     set guioptions-=T  " remove toolbar
240     set guioptions-=r  " remove right-hand scroll bar
241     set guioptions-=l  " remove left-hand scroll bar
242     set guioptions-=L  " remove left-hand scroll bar even if there is a vertical split
243     set guioptions-=b  " remove bottom scroll bar
244 endif

我要吐槽的是,即便设置了set guioptions-=l,当切割了横向窗口时,左侧的滚动条还是会如幽灵般出现.各种不解后查了手册才明白,原来还要set guioptions-=L,但是,右侧滚动条却没有这个坑,简直坑爹.

tags

:help tags

tags是什么,程序员都懂.通过ctags程序可以很方便的为C++/C项目生成tags:

ctags -R –c++-kinds=+p –fields=+iaS –extra=+q .

–c++-kinds=+p 生成函数原型,该选项默认关闭.同样默认关闭的选项还有l(局部变量)和x(外部变量).
–fileds=+iaS 分别对应类的继承inheritabce,类成员访问权限(access)和routine签名(Signature, 如原型或参数列表等).
–extra=+q 为类成员生成的tag加上其所属的类信息.

这行命令敲起来太累了,不如按一下F5来的痛快:

492 map <F5> :!ctags -R –c++-kinds=+p –fields=+iaS –extra=+q .<CR>

该命令生成的文件为当前目录下的tags.

作为后台开发程序员,查阅系统源码是常有的事,不妨为/usr/include目录生成tags,然后配置vimrc,以便每次启动vim时自动加载(即便有再多的autoload,即便vim启动速度再慢,也足以秒杀emacs了…这算是降维攻击不?):

274 if has("win32")
275     set tags+=E:\workspace\linux\tags  " tags for /usr/include/
276 else
277     set tags+=~/.vim/tags/include/tags " tags for /usr/include/
278 endif
279 set tags+=tags                         " tags for current project

需要说明的是,我偶尔需要在windows上写代码,所以我把linux下的/usr/include目录拷贝到了windows上,然后用ctags windows版生成了tags,于是在windows上写代码也舒适了许多.

插件

vim什么都硬,只是有一点比较短: 扩展性,vim在这一点被咖啡机emacs拉下远远不止一条街,但是对于普通青年我,却也算是差强人意了.”Do one thing and do it well”,这恐怕是不少vim拥趸自我解脱的说辞.

下面是个人最喜欢的一些插件,排名不分先后:

Quickfix.vim

:help quickfix

Quickfix是vim的标准插件,它是一个典型的plumber: 只要输入符合error format(efm),则vim可以正确理解和识别”错误列表”,并跳转到对应行.

我们通过gcc和grep的输出来更好地理解error format:

Error: Unclassifiable statement at hello-world.f90:9.4 gcc编译器的错误提示
./sys/net/bpf.c:137: bpf_wakeup __P((struct bpf_d *)); grep的输出(加上-n)

可以看到,它们的格式是非常类似的.

虽然Quickfix插件原意是为了更方便地调试代码,可是借用error format实现文本的匹配也是非常拉轰的:

505 " search word under cursor like source insight
506 " <cword> is replaced with the word under the cursor (like |star|) (:help cmdline or :help cword)
507 map <C-F> :execute "let g:word=expand(\"<cword>\")"<Bar>execute "vimgrep /\\<" . g:word ."\\>/g **/*.[ch] **/*.cpp"<Bar>execute "cc 1"<Bar>execute "cw"<CR>
508 " next matched line
509 map <silent> <F10> :cnext<CR>
510 " previous matched line
511 map <silent> <F11> :cprevious<CR>
512 " open QuickFix
513 " :copen
514 " close QuickFix
515 " :cclose

简单说明一下这段配置,表示当前光标下的单词(:help cmdline or :help cword),也就是|,表示串联命令.cc 1表示跳到”错误列表”第一条,cw表示打开quickfix窗口,如果存在可识别的错误列表.cnext和cprevious表示在错误列表中切换.

btw,vim在匹配时默认使用自带的vimgrep插件,如果觉得不方便,可以显示指定使用grep: set grepprg=grep

A.vim

A.vim插件可以方便地切换源文件和头文件,还是那句话,谁用谁知道啊.

:A 在同一tab切换源文件/头文件
:AV 竖向切割窗口,打开对应的源文件/头文件.
:AS 横向切割窗口,打开对应的源文件/头文件.

NERDTree.vim

NERDTree插件可以清楚地展示目录树,而且支持许多快捷键.个人最喜欢的快捷键是t: 在新建的tab打开光标所对应的文件.可惜的是,NERDTree原版插件对所新建的tab的命名看起来没什么具体的含义,于是我用上了二手版,配置如下:

378 map <F6> <plug>NERDTreeTabsToggle<CR>
379
380 let g:nerdtree_tabs_open_on_gui_startup=1     " Open NERDTree on gvim/macvim startup
381 let g:nerdtree_tabs_open_on_console_startup=1 " Open NERDTree on console vim startup
382 let g:nerdtree_tabs_open_on_new_tab=1         " Open NERDTree on new tab creation
383 let g:nerdtree_tabs_meaningful_tab_names=1    " Unfocus NERDTree when leaving a tab for descriptive tab names
384 let g:nerdtree_tabs_autoclose=1               " Close current tab if there is only one window in it and it’s NERDTree
385 let g:nerdtree_tabs_synchronize_view=1        " Synchronize view of all NERDTree windows (scroll and cursor position)
386
387 " When switching into a tab, make sure that focus is on the file window, not in the NERDTree window.
388 let g:nerdtree_tabs_focus_on_files=1

OmniCppCompelete.vim

OmniCppComplete借助于tags实现智能补全,Ctrl-X Ctrl-O弹出待选择tags菜单,Ctrl-N切换至下一选项,Ctrl-P切换至上一选项.

个人配置如下:

318 " :help omnicppcomplete
319 set completeopt=longest,menu      " I really HATE the preview window!!!
320 let OmniCpp_NameSpaceSearch=1     " 0: namespaces disabled
321                                   " 1: search namespaces in the current buffer [default]
322                                   " 2: search namespaces in the current buffer and in included files
323 let OmniCpp_GlobalScopeSearch=1   " 0: disabled 1:enabled
324 let OmniCpp_ShowAccess=1          " 1: show access
325 let OmniCpp_ShowPrototypeInAbbr=1 " 1: display prototype in abbreviation
326 let OmniCpp_MayCompleteArrow=1    " autocomplete after ->
327 let OmniCpp_MayCompleteDot=1      " autocomplete after .
328 let OmniCpp_MayCompleteScope=1    " autocomplete after ::

在智能补全时,OmniCppComplete会在当前工作窗口上方横向切割出一个preview窗口,preview窗口包含当前待选项的各种说明.杯具的是,当通过Ctrl-N或者Ctrl-P切换待选tags时,该preview窗口将会随着待选说明的变化而增大缩小,如果切换速度较快,则preview窗口看起来就像抖动一般.这也让人很难受,我们可以如下配置,关闭preview特性.

319 set completeopt=longest,menu      " I really HATE the preview window!!!

另外,不要被插件名字欺骗了,OmniCppCompelete同样支持其他语言,如python,xml等.配置如下:

331 autocmd FileType python set omnifunc=pythoncomplete#Complete
332 autocmd FileType javascript set omnifunc=javascriptcomplete#CompleteJS
333 autocmd FileType html set omnifunc=htmlcomplete#CompleteTags
334 autocmd FileType css set omnifunc=csscomplete#CompleteCSS
335 autocmd FileType xml set omnifunc=xmlcomplete#CompleteTags
336 autocmd FileType php set omnifunc=phpcomplete#CompletePHP
337 autocmd FileType c set omnifunc=ccomplete#Complete

关于autocmd,找manual: help autocmd

Supertab.vim

vim在插入模式下支持13种补全方式(:help ins-completion),普通青年记不住,于是有了Supertab插件,配置如下:

312 let g:SuperTabRetainCOmpletionType=2    " 2: remember last autocomplete type, unless I use ESC to exit insert mode
313 let g:SuperTabDefaultCompletionType="<C-X><C-O>"

Taglist.vim

该插件展示当前文件对应的tags列表.配置如下:

299 if has("win32")
300     let Tlist_Ctags_Cmd=‘ctags’             " set ctags path
301 else
302     let Tlist_Ctags_Cmd=‘~/ctags-5.8/ctags’ " set ctags path
303 endif
304 let Tlist_Show_One_File=1               " only show current file’s taglist
305 let Tlist_Exit_OnlyWindow=1             " if taglist is of the last windows, exit vim
306 let Tlist_Use_Right_Window=1            " show taglist at right
307 let Tlist_File_Fold_Auto_Close=1        " hide taglist if it’s not for current file

mark.vim

这是一款高亮插件.<leader>m高亮当前光标所对应的单词,再次<leader>m清除高亮.<leader>n清除所有高亮.

mark.vim默认只有下面这6种高亮颜色.如果觉得太少,可以自由地在mark.vim中添加.

 68 " default colors/groups
 69 " you may define your own colors in you vimrc file, in the form as below:
 70 hi MarkWord1  ctermbg=Cyan     ctermfg=Black  guibg=#8CCBEA    guifg=Black
 71 hi MarkWord2  ctermbg=Green    ctermfg=Black  guibg=#A4E57E    guifg=Black
 72 hi MarkWord3  ctermbg=Yellow   ctermfg=Black  guibg=#FFDB72    guifg=Black
 73 hi MarkWord4  ctermbg=Red      ctermfg=Black  guibg=#FF7272    guifg=Black
 74 hi MarkWord5  ctermbg=Magenta  ctermfg=Black  guibg=#FFB3FF    guifg=Black
 75 hi MarkWord6  ctermbg=Blue     ctermfg=Black  guibg=#9999FF    guifg=Black

最后

推荐两大暗爽已久的神器,一是vimperator,在firefox上高度仿真了vim.一是hhkb,其惊艳的键位布局彻底释放了我被压抑多时的小拇指(码农你懂的),而奢侈的电容键盘更让人概叹“RealForce的素质,那仅仅是HHKB的起点而已”.当然,如果拿hhkb来码中文,那就是另一回事了…

译者注: 原文写于2003年,文中描述的不少内容已经发生了改变,在不影响愿意的情况下,我擅自增删了一些内容.

翻译过程中找到的好资料:

• How SKBs Work
• Evaluation of TCP retransmission delays
• Congestion Control in Linux TCP
• Anatomy of the Linux networking stack — From sockets to device drivers
• Guide to IP Layer Network Administration with Linux
• Linux内核源码剖析 —TCP/IP实现
• Understand Linux Network Kernel
• TCP/IP Illustrated, Vol. 2
• RFC793, RFC1122, RFC1323, RFC2001, RFC2018, RFC2581

translated by ripwu, 个人主页: http://godorz.info

sk_buff

结构体定义

一个sk_buff对应的内存抽象图示为:

为了实现sk_buff在各层间传输时的零拷贝,采用的是将数据放在内存最后,增减报文头时在内存前面操作,然后重新设置相关指针即可.下图演示了一个UDP数据包在发送时添加UDP报头和IP报头的过程:

sk_buff的实现方式是双向链表.和所有的链表一样,sk_buff含有指向下一元素的next指针和指向前一元素的prev指针,为了更快的知道某个sk_buff元素属于哪一链表,sk_buff还包含一个指向头结点的list指针.

sk_buff元素组成的链表结构图如下:

创建和销毁

alloc_skb()负责sk_buff的创建,从sk_buff结构体的定义可以看到,当创建一个sk_buff时,总共需要申请两块内存,一块内存存储sk_buff本身(通过kmem_cache_alloc()),另一块内存存储sk_buff.data指向的数据区(通过kmalloc()).示意图如下:

其中, Padding的作用是字节对其. skb_shared_info这里不做介绍,详细信息参考<Understand Linux Network Kernel>.

sk_buff的销毁稍微复杂,但原理很简单,这里也不做介绍.

2. 网络层

本节介绍底层接收和处理packet(数据包)的流程.

接收packet的过程如下:

1. 网卡接收packet.

这些packet由DMA机制存储在最近使用的网卡的rx_ring中.rx_ring是一种工作于内核态的环形队列,其容量大小依赖于具体的网卡.有一种比较老的网卡,工作方式为轮询(PIO)模式: 由CPU将网卡数据读入内存态内存.

2. 网卡产生中断.

CPU开始执行网卡驱动的ISR代码,在2.4.19内核版本后,工作方式有些区别:

对于2.4.19版本之前(包括2.4.19)的内核:

如上图所示,中断处理程序将调用netif_rx()(net/dev/core.c). netif_rx()将接收到的数据压入被中断CPU的backlog队列,然后调度一个软中断(softirq, 一种内核行为,见 http://tldp.org/HOWTO/KernelAnalysis-HOWTO-5.html 和  http://www.netfilter.org/unreliable-guides/kernel-hacking/lk-hacking-guide.html 译注: 这里实际是指”下半段”,与硬中断的”上半段”呼应,见<Linux内核设计与实现> Update[2011-09-06] 译注错误: 软中断是bottom half的扩展,两者不应混为一谈. 操作系统之所以独立分开一个top half的概念,主要是因为中断是在CPU关中断(CLI)的情况下运行的,为了不丢失新到的中断信号,操作系统将中断服务程序一分为二,前者(top half)对其执行时间要求比较严格,一般立刻响应中断请求,为保证原子操作,它在关中断情况下执行,后者(bottom half)对时间要求没那么严格,通常在开中断下执行.但是,bottom half有一个致命的缺点,它只能在一个CPU上运行,也就是严格的串行,为了更充分的利用SMP,Linux2.4内核扩展了bottom half,成果便是所谓的”软中断(softirq)”机制,软中断最大的优点在于它可以在多CPU上运行,它在设计与实现中自始自终都贯彻了一个思想: “谁触发,谁执行(Who marks, Who runs),即触发软中断的那个CPU负责执行它所触发的软中断,而且每个 CPU 都由它自己的软中断触发与控制机制.), 由 软中断来负责packet的进一步处理(比如说: TCP/IP 协议的处理). backlog队列的 长度为300个packet大小(/proc/sys/net/core/netdev_max_backlog).

当backlog队列为满时,它转入throttle状态,在此状态等待数据清空,然后重新回到正常状态,正常状态下,backlog允许packet的入队操作.(netif_rx(), net/dev/core.c). 当backlog队列处于throttle状态时, netif_rx()将丢弃新来的packet.  我们可以通过/proc/net/softnet_stats来查看backlog队列的统计信息: 每一行对应一颗CPU,前两列分别是packet量和丢包量,第三列表示backlog队列有多少次进入了throttle状态.

对于2.4.19版本之后的内核:

如上图所示,内核采用的是NAPI新机制(见http://en.wikipedia.org/wiki/NAPI): 中断处理程序调用netif_rx_schedule()(include/linux/netdevice.h).该函数执行入队的对象不是packet,而是packet的一个引用(reference).(softnet_data>poll_list; include/linux/netdevice.h). 与旧内核机制相同的是,中断处理程序同样会调度一个软中断.为了向后兼容, 在NAPI机制中, backlog被当作像网卡一样可以处理所有到达packet的虚拟设备.内核开发者重写了netif_rx(),该函数将packet压入backlog之后,又将backlog压入CPU的poll_list链表.

3. 软中断执行net_rx_action()(net/core/dev.c).

在这一步中,新老内核处理方式同样有所不同:

对于2.4.19版本之前(包括2.4.19)的内核:

net_rx_action()为backlog队列中的所有packet调用**_rcv()函数(net/ipv4/ip_input.c),这里的**指代不同的packet类型,如ip, arp, bootp等.

对于NAPI:

CPU轮训其poll_list链表中的设备(注: NAPI中backlog为虚拟设备, process_backlog: net/core/dev.c),从设备的rx_ring环形队列中获得全部packet.CPU的轮询是通过 netif_receive_skb()(net/core/dev.c)调用ip_rcv()来完成的.

当一个packet被创建时,内核做了如下工作:

*IP packet由arp_constructor()创建.每个packet都包含dst field信息,dst提供了路由所需的目的地址,它对应一个output方法,对于IP packet而言,此方法为dev_queue_xmit().

*内核提供了多种排队原则(queueing disciplines, 简称qdisc).默认的排队原则使用FIFO队列,其缺省长度为100个packet大小.(ether_setup(): dev->tx_queue_len ; drivers/net/net_init.c),此长度可以通过带txqueuelen选项的ifconfig命令进行设置. 我们无法查看默认FIFO的统计信息,这里提供一个小技巧,通过tc 命令可以设置新的FIFO,以取代缺省的qdisc:

• 取代缺省的qdisc: tc qdisc add dev eth0 root pfifo limit 100
• 查看统计信息: tc -s -d qdisc show dev eth0
• 重新设置缺省qdisc: tc qdisc del dev eth0 root

1.对从IP层(IP layer)传入的packet,调用dev_queue_xmit()(net/core/dev.c).该函数将packet压入外发网卡(output interface, 它由路由决定)相应的qdisc.如果网卡驱动正常, qdisc_restart()(net/sched/sch_generic.c)将处理qdisc中的所有packet;

2.调用hard_start_xmit().该方法实现于网卡驱动,它将packet压入tx_ring环形队列,然后网卡驱动将通知网卡有数据可发送.

3. 网卡发送packet并通知CPU. CPU调用net_tx_action()(net/core/dev.c)将packet压入completion_queue,然后调度一个负责释放packet内存的软中断.网卡与CPU之间的通信方式是硬件相关的,这里不作详细介绍.

3. 传输层

IP相关文件有:

• ip_input.c         –  处理到达packet
• ip_output.c      –  处理发送packet
• ip_forward.c    –  处理由本机路由的packet

还有一些模块负责处理 IP packet fragmentation(ip_fragment.c),IP options(ip_options.c), multicast(ipmr.c) 和 IP over IP (ipip.c)

下图描述了packet在IP层的流转路径. 当一个packet到达主机后,如前文所述种种流程,net_rx_action()将它转给ip_rcv()处理. 在经过first netfilter hook后, ip_rcv_finish()验证该packet的目的地是否就是本机.如果是的话, ip_rcv_finish()将该packet传给ip_local_delivery(), 然后由ip_local_delivery()转发给合适的传输层(transport layer)处理函数(tcp, udp, etc).

如果IP packet的目的地址是其他主机,那么处理该packet的当前主机就起了router的角色(这种场景在小型局域网上很常见). 如果主机允许转发packet(通过/proc/sys/net/ipv4/ip_forward查看或设置),那么该packet将由一系列复杂但高效的函数处理.

如果路由表(它是一种hash表)中存在packet的路由信息的话,该packet的行经路径通过ip_route_input()查找,否则,通过ip_route_input_slow(). ip_route_input_slow()调用fib(Forward informationbase, 路由表)族函数,这些函数定义在fib*.c文件中. FIB结构体非常复杂.

如果packet是多播(multicast)数据包,那么内核通过ip_route_input_mc()计算出packet发往的那些设备(该情况下,packet目的地址不变).

在计算出packet的路由信息之后,内核往IP pcaket插入新的目的地址,并将其所属设备信息插入对应的sk_buff结构. 然后,packet被转发(forwarding)函数(ip_forward() 和 ip_forward_finish()).

一个packet也可以从上层发往ip层(通过 TCP or UDP 传输). 处理该packet的第一个函数ip_queue_xmit(),它通过ip_output()将packet发往output part.

output part对packet做了最后的修改. dev_queue_transmit()将packet压入输出队列(output queue),然后通过q->disc_run()来调用网络调度机制(network scheduler mechanism).该指针指向不同的函数,这取决于内核采用的调度器(默认为FIFO类型,可以通过tc工具进行设置).

调度函数(qdisc_restart() 和 dev_queue_xmit_init())独立于IP层其他函数.

4. TCP

本节介绍Linux内核网络协议栈中最为复杂的TCP.

Introduction

TCP相关文件有:

• tcp_input.c           -  最大的一个文件,它处理网络中到达的packet
• tcp_output.c        -  处理将发往网络的packet
• tcp.c                         -  TCP代码
• tcp_ipv4.c             -  IPv4具体的TCP代码
• tcp_timer.c           – 定时器
• tcp.h                         – 定义TCP结构体

TCP数据的处理如下两图,上图处理接收,下图处理发送.

TCP Input (mainly tcp_input.c }

TCP input在TCP实现中占了很大一部分.它处理TCP packet的接收,因为TCP实体(TCP entity, 也就是TCP协议栈)可以同时处于接收和发送两种状态,所以这两类代码混杂在了一起.

ip_local_deliver()将packet从IP层发往TCP层.它把packet传给ipproto->handler,在IPv4的实现中该handler就是tcp_v4_rcv().此函数进一步调用tcp_v4_do_rcv().

tcp_v4_do_rcv()会根据TCP连接(connection)的不同状态调用不同的函数.如果连接已建立(TCP_ESTABLISHED),它会调用tcp_rcv_established(),这是我们接下来会重点介绍的部分. 如果连接状态是TIME_WAIT,它会调用tcp_timewait_process().

对于其他的状态, tcp_v4_do_rcv()统一调用tcp_rcv_state_process().对于SYS_ENT状态的连接,该函数进一步调用tcp_rcv_sysent_state_process().

tcp_rcv_state_process()和tcp_timewait_process()必须初始化TCP结构体,这通过tcp_init_buffer_space()和tcp_init_metrics()完成. tcp_init_metrics()调用tcp_init_cwnd()来初始化其拥塞窗口(congestion window).

tcp_rcv_established()

tcp_rcv_established()有两条分支路径.我们首先介绍慢路径(slow path)分支,因为它简单清晰,另一分支留待后文介绍.

slow path

在RFC中,slow path只要有7步操作:

• tcp_checksum_complete_user()计算校验码(checksum).如果检验码有误,packet被丢弃.
• tcp_paws_discard()负责PAWS(Protection Against Wrapped Sequence Numbers).
• STEP 1 – 检查packet序列号(sequence). 如果序列号不再接收端口中,接收模块(receiver)将 通过tcp_send_dupack()发回一个DUPACK.tcp_send_dupack()通过tcp_dsack_set()设置一个SACK,然后调用tcp_send_ack()进行发送.
• STEP 2 – 检查RST位(th->rst),如果该位被置位,调用tcp_reset().
• STEP 3 – 检查安全性(security)和优先级(precedence, RFC建议,但内核未实现)
• STEP 4 – 检查SYN位,如果该位被置位,调用tcp_reset()…
• 通过tcp_replace_ts_recent()估算RTT(RTTM).
• STEP 5 -检查ACK位,如果该位被置位,调用tcp_ack().
• STEP 6 -检查URG位,如果该位被置位,调用tcp_urg().
• STEP 7 -通过tcp_data_queue()处理packet携带的数据.
• 通过tcp_data_snd_check()检查是否有数据要发回.该函数将调用TCP发送模块( output sector)的tcp_write_xmit().
• Finally, 通过tcp_ack_snd_check()检查是否有ACK要发回.ACK的发回有两种情况: 通过tcp_send_ack()直接发回; 或者通过tcp_send_delayed_ack()延时发回(译注: 这是TCP的延时确认(Delayed ACK)机制,目的为减少分组,可通过/proc/sys/net/ipv4/tcp_delack_min设置),被延时的ACK存储在tcp->ack.pending.

tcp_data_queue()

tcp_data_queue()负责处理packet数据.如果packet顺序到达(所有之前的packet已到达),它将把数据拷贝到tp->ucopy.iov (skb_copy_datagram_iovec(skb, 0, tp->ucopy.iov, chunk)).

如果packet并非顺序到达,那么它将通过tcp_ofo_queue()把packet压入乱序队列(out of order queue).

如果乱序队列满,根据RFC 2581文档4.2节, 协议栈将返回一个ACK(tp->ack.pingpong 被置0,tcp_ack_snd_check()被调用来返回ACK).

packet的到达引起各种反应,这由tcp_event_data_recv()处理. 它首先通过tcp_schedule_ack()调度一个ACK的发回,然后通过tcp_measure_rcv_mss()估算MSS(Maximum Segment Size).在特定的情况下(如: 慢启动), tcp_event_data_recv()选择调用tcp_incr_quickack(),以立刻返回ACK(即不使用延时确认机制).最后, tcp_event_data_recv()通过tcp_grow_window()增大通告窗口(advertised window, 译注: 其实也就是receive window,即接收窗口,更多参数设定见 http://140.116.72.80/~smallko/ns2/TCPparameter.htm).

tcp_data_queue()最终将检查FIN位,如果该位被置位,调用tcp_fin().

tcp_ack()

对发送模块(“sender”)而言,它每收到一个ACK,都会调用tcp_ack(),注意这一点不要和接收模块(“receiver”)通过tcp_send_ack()调用tcp_write_xmit()发送ACK的行为混淆了.

tcp_ack()首先检查ACK是否比先前收到的ACK较老还是较新,如果较老的话,内核通过执行 uninteresting_ack和old_ack无视之.

如果一切正常, tcp_ack()将通过tcp_ack_update_window()和/或tcp_update_wl()更新发送端的拥塞窗口.

如果ACK可疑(dubious) ,那么通过tcp_fastretrans_alert()进入快速重传(fast retransmit).

tcp_fast_retransmit()

tcp_fast_retransmit_alert()只由tcp_ack()在特定条件下调用.为了更好的理解这些特定条件,我们必须对
NewReno/SACK/FACK/ECN状态有深入的认识.注意这个TCP状态机本身没有什么关系,在这里连接状态几乎可以确定是TCP_ESTABLISHED.

拥塞控制状态有:

• “Open” – 正常状态,无可疑事件,属于快速路径(fast path).
• “Disorder” -当发送方检测到DACK(重复确认)或者SACK(selective ACK带选择的ACK, 见http://simohayha.iteye.com/blog/578744)时会进入该状态,它可以看成是Open状态,之所以会将”DisOrder”从”Open”中分离出来,主要是为了将某些处理从快速路径(fast path)移到慢速路径(slow one). (译注: 在这个状态,拥塞窗口不会被调整,每一次新的输入数据包都会触发一个新的端的传输)
• “CWR”(拥塞窗口减小) – 某些拥塞通知事件(Congestion Notification event)将减小CWND(译注: 即congestion window拥塞窗口). 这些事件包括ECN(Explicit Congestion Notification显式拥塞通知,见http://en.wikipedia.org/wiki/Explicit_Congestion_Notification), ICMP远端抑制(ICMP source quench, 见http://en.wikipedia.org/wiki/ICMP_Source_Quench)和本机设备的拥塞.(译注:当接收到一个拥塞通知时,发送方并不立刻减小拥塞窗口,而是每隔一个新收到的ACK减小一段知道拥塞窗口大小减半为止,发送方在减小拥塞窗口的过程中不会有明显的重传. CWR状态可以被Recovery或Loss状态中断.)
• “Recovery” – 该状态下CWND被减小,正在快速重传(fast-retransmitting). (译注: 默认情况下,进入Recovery状态的条件是三个连续的重复ACK.在Recovery状态期间,拥塞窗口的大小每隔一个新到的确认减少一个段,这和CWR状态类似.窗口减小直到刚进入Recovery状态时窗口大小的一半为止.拥塞窗口在恢复状态期间不增大,发送方重传那些被标记为丢失的段,或者根据包守恒原则在新数据上标记前向传输.发送方保持Recovery状态直到所有进入Recovery状态时正在发送的数据段都成功地被确认,之后该发送方恢复Open状态.重传超时有可能中断Recovery状态.)
• “Loss” – 当RTO到期(RTO timeout)或者SACK拒绝(SACK reneging, 译注: 表示接收到的ACK的确认已经被先前的SACK确认过),发送方进入Loss状态.CWDN减小而后增大. (译注: Loss状态下所有正在发送的数据段标记为loss,拥塞窗口重置为1,发送方然后按慢启动算法增大拥塞窗口.Loss和Recovery状态的一个主要区别是: 在Loss状态,拥塞窗口在发送方重置为一个段后增大,而Recovery状态下拥塞窗口只能被减小. Loss状态不能被其他的状态中断,因此,发送方只能在所有Loss开始时正在传输的数据都成功得到确认ack后,才能回到Open状态,例如, 快速重传(fast retransmitting)不能在Loss状态期间被触发)

这些状态保存于tp->ca_state,对应值分别是TCP_CA_Open, TCP_CA_Disorder, TCP_CA_Cwr, TCP_CA_Recover 和 TCP_CA_Loss.

当收到ACK时状态不为Open,或者收到了奇怪的ACK(如SACK, DUPACK ECN ECE),内核会调用tcp_fastretrans_alert(). (译注: 此函数非常重要,它负责拥塞控制的处理,包括处理显式拥塞通知,判断SACK是否虚假,拥塞时记录的SND,NXT被确认时进行撤销,以及当前状态的处理等.详细见http://research.csc.ncsu.edu/netsrv/sites/default/files/hystart_techreport_2008.pdf)

fast path

在TCP处理过程中,receiver比较简单,因此它经常进入快速路径.

SACKs

Linux TCP协议栈完整实现了SACKS(带选择的ACK).SACK信息存储于tp->sack_ok field.

quickacks

某些情况下,receiver进入quickack模式,也就是说,延时确认机制(delayed ACK)被禁用.在quickack模式下,连接开始时,tc_rcv_sysent_state_process()将调用tcp_enter_quick_ack_mode().

Timeouts

定时器对TCP的正确工作起到了至关重要的作用.比如说,借助定时器,TCP可以判断packet是否在网络中丢失.

当发送一个packet时,其重传定时器(retransmit timer)会被设置. tcp_push_pending_frames()通过tcp_check_probe_timer()调度一个软中断(软中断有内核中非网络协议栈相关的代码处理).

定时器的超时事件会产生一个软中断,软中断通过timer_bh()调用run_timer_list(). run_timer_list()将调用timer->function函数指针指向的tcp_wite_timer(). tcp_wite_timer()进而调用tcp_retransmit_timer(),最终, tcp_wite_timer()调用tcp_enter_loss(). tcp_enter_loss()将拥塞控制状态设为CA_Loss,然后由fastretransmit_alert()重传packet.

ECN

ECN(Explicit Congestion Notification,即显式拥塞通知)代码比较简单, 几乎所有的代码都在/include/net目录下的tcp_ecn.h文件中. tcp_ack()调用TCP_ECN_rcv_ecn_echo()来处理ECN packet.

TCP output

这部分代码(主要在tcp_output.c)负责packet(包括sender发送的数据packet和receiver发回的ACK)的发送.

5. UDP

本节简单介绍UDP,它很重要,但比起TCP,其拥塞控制却简单多了.

UDP相关文件:

• net/ipv4/udp.c

当packet通过ip_local_delivery()从IP层到达时,它被传给udp_rcv()(该函数角色类似于TCP的tcp_v4_rcv()). udp_rcv()调用sock_put()将packet压入socket queue.packet的传递就到此结束了.内核然后调用inet_recvmsg()(通过recvmsg()系统调用), inet_recvmsg()调用udp_recvmsg(), 而udp_recvmsg()进一步调用skb_rcv_datagram(). skb_rcv_datagram()函数从队列中获得packet,然后据此packet填充用户态将读取的结构体.

当一个packet从用户态到达时(译注: 也就是说要发送出去),处理就更加简单了. inet_sendmsg()调用udp_sendmsg(), udp_sendmsg()通过从sk结构体获取的信息(这些信息在socket被创建和被绑定(bind调用)时被设置于sk中)填充UDP数据报(UDP datagram).

当UDP数据报填充完成之后,数据报被传给ip_build_xmit(), ip_build_xmit()通过ip_build_xmit_slow()创建IP packet.

IP packet创建完成以后, packet被传给ip_output(),正如4 – Network Layer 介绍的一样, ip_output()将packet发往更低层.

也许很少有高中同学知道,尽管成绩一向不错,但实际上我对数学充满了厌恶.高中3年机械式的训练,让我实在无法忍受,于是高考填报志愿时选了一个文科的方向,自以为从此天高云厚,憧憬着大学生活的我完全没有意识到此后的命运弄人带来的打击会有多大.

一分之差被选择了计算机专业,大学的傻逼生涯就此埋下了伏笔.整个大一都是在迷茫中度过,对于在大学第一学期,本应是最有干劲的新生来说,高等代数62分和数学分析60分已经足以说明了我的自暴自弃,虽然如此,此后的我居然一直没在数学之上挂科,这是很难想象的,唯一可能的答案也许是尚有一点点不甘吧.维系着成绩上的苟延残喘之余,所有的郁闷都被我发泄在读书上,我阅读了各种名人的传记,从曹操到希特勒,从艾森豪威尔到巴顿,从切格瓦拉到卡斯特罗,原来,所有人都在自己的方向一步步的努力,这个发现便是大一最大的收获了.

可惜的是,我找不到我的方向,在学习压力巨大的大二,我仍旧找不到前方.曾经的理想已经远去,未来的大门尚未敞开.这篇文章很好的记下了当时的想法.对于数学,我完全无爱,或许,它唯一能带给我快乐的也就只有右边的这个笑话了.我很想改变些什么,但却有心无力,每天浑浑噩噩,做一天和尚撞一天钟,痛苦,挣扎,便是大二全部的关键词.

上了大三,我恋爱了.正如2010总结所描述的那样,大三的前几个月,我终于找回了已经很久未曾体会过的幸福,逛街,看电影,每一天都是如此轻松,每一秒都是如此难忘,我连谈恋爱的时候都不够,又怎么顾得上去厌恶我的专业呢.沉浸,陶醉,如今回过头来想想,正是这几个月无拘无束的生活,让我对计算机系的感觉焕然一新.代码不再枯燥,编程不再无聊,甚至于,当我鬼使神差的捧起APUE时,细细咀嚼,竟然有了一种与巨匠前贤直面交谈的感觉,那一刻我爱上了Unix,我想这就是所谓的顿悟吧.自此之后,我着了魔,疯狂的想弄明白每一句代码背后的故事,地底三万尺,我愿意去深挖,我愿意去探险,这种感觉实在是太奇异了,我很享受在不同的层次间level up和level down,每一次思维上切换都能带来一种快感,如同高空坠落一般,真实,激烈,持久.

我入了门,虽然有点晚,但还不迟,毕竟better late than never.老丘说,努力就是了,于是,在接下来的几个月里,凭着初生牛犊的冲劲,我啃掉了Unix领域不少的经典图书,在此期间,还不忘回头把计算机,算法,网络等本该早已掌握的知识重新打牢,然后,因为无知,所以无畏,我去面试了.此后的事情如在眼前,我很幸运地得以在腾讯实习了4个多月,深感于才疏学浅,如今一直呆在学校里恶补,直到今天下午看到好友们对于毕业纷纷的感概,一时难以自已,便在这里写着这篇文章.

其实,现在想来,大学四年里我是相当幸运的.首先是学校,虽然我常常不怀好意的称其为中国山寨大学,但实际上,中大是很自由,很轻松的一所大学.即便是某次我很嚣张的质问为什么在google上搜索世界杯一共打多少场比赛都会被重置时,辅导员都没有大动肝火,不过是交份检讨,积极分子除名了事.正是因为学校如此轻松的学风,让我后来可以毫无顾忌的肆意逃课,一心一意学习Linux网络编程.我很幸运,还因为大一时某次邹大牛(yuhan童鞋,尽管你不知道,但就是你了!!)Q群上不经意地说到搞Linux不错,这才让我这菜鸟有了初步印象,时隔两年之后走上了后台开发的道路,而且很幸运地在wenhack童鞋和linuxayn师兄的指点下,找准了入门的方向,从APUE到UNP到TCP/IP到POSA,一路下来,没有经历过多少弯路就越过了门槛.现在想起来,确实有种鬼使神差的感觉.最后,非常感谢给了我实习机会的面试官leo,还有诲人不倦谆谆教诲的导师denny,我真是太幸运了!

如果一定要说在大学中学到了什么,好吧,是视野.以前我从不相信什么天才,但是,一个师弟,一个初中就写过带图形界面的操作系统,汇编,c,算法,网络编程无所不通身上爆发者各种闪光点的孩子让我彻底明白了,天才是存在的,而且就在我身边.无数次震撼极大的扩大了我的视野,天外有天,人外有人,深深愧疚于自己的不足的我,一定要努力,像某人说的那样,做一只癞蛤蟆,不做青蛙.

最后,我想起了右边那个故事,回首4年大学生活,曾经浪费的时光再也找不回,但实际上我没有什么后悔的,年少时的错误正是成长的代价,拒绝了错误,也就拒绝了成长.

回想起在家的这几天,沉重的气氛让人眩晕.肃静,冷清取代了往日的欢声笑语,孤独的夜,暴风雨暗暗积攒着能量,秋风刮出了多少感伤,天昏地暗间,一声吵骂打破了最后的安详,在毫无保留地释放着的,是填不平的怒火与绝望.曾经举案齐眉,如今仇深似海,黑白电影般参差破烂的画片,断断续续的在上演,吱嘎吱嘎,末了,一曲绝唱,几许苍凉.

世间再无比这更让人捶胸顿足,徒呼奈何的悲剧了.手心是爸,手背是妈,手心手背,血浓于水.父母,恨不得也说不得,再多的坚强也是徒劳,再多的努力也将付之东流.我的心,碎了,头皮发麻,四肢乏力,已然内伤.

天啊,我已看不清前方.

“Do not go gentle into that good night. Rage, rage against the dying of the light.” – Dylan Thomas

运行结果如下:

>>> from delicious import *
>>> table=initializeUserDict('programming')
>>> table['myself']={}
>>> fillItems(table) 考虑到国内的网络,冲杯咖啡先吧...
>>> from recommendations import *
# 对用户username推荐n条网页链接
>>> getRecommendations(table,"username")[0:n]
# 输出结果前者为推荐值,后者为链接
[(0.61988282180389409, 'http://html5boilerplate.com/mobile/')]
...

deliciousapi

deliciousapi是非官方的api,用于从delicious上拿数据,它的接口很简洁,作者博客上有相应的demo,这里不废话.

initializeUserDict and fillItems

initializeUserDict(tag, count)首先通过deliciousapi.DeliciousAPI().get_urls(‘tag’)获得某个tag下的count链接,然后通过.get_url(‘url’)获取该链接相关的信息,e.g. bookmarks,tags.最后收集bookmarks对应的用户到字典user_dict,将其返回.代码如下:

def initializeUserDict(tag, count=1):
   user_dict={}
   dapi = deliciousapi.DeliciousAPI()

   for url in dapi.get_urls(tag=tag)[0:count]:
      for item in dapi.get_url(url).bookmarks:
         user_dict[item[0]]={}
   return user_dict

fillIteams(user_dict)遍历字典user_dict,通过.get_user(user)获取user收集的bookmarks.如果某个url被所有user收藏,那么将user_dict[user][url]置位,否则清零.代码如下:

def fillItems(user_dict):
   all_items={}
   dapi = deliciousapi.DeliciousAPI()

   for user in user_dict:
      for i in range(3):
         try:
            posts=dapi.get_user(user)
            break
         except:
            print "Fail user "+user+", retrying"
            time.sleep(4)
      for item in posts.bookmarks:
      	 url=item[0]
      	 user_dict[user][url]=1.0
      	 all_items[url]=1

   for ratings in user_dict.values():
      for item in all_items:
         if item not in ratings:
         	ratings[item]=0.0

经过initializeUserDict()和fillItems()两步后,得到的user_dict形如:

{'username': {'http://url': 0.0}, {'http://lru': 1.0},
 'nameuser': {'http://url': 0.0}, {'http://lru': 1.0},
  ...
}

getRecommendations

现在看看最核心的推荐算法,其实很简单:

def sim_distance(prefs, person1, person2):
   si={}
   for item in prefs[person1]:
      if item in prefs[person2]:
           si[item]=1

   if len(si)==0: return 0

   sum_of_squares=sum([pow(prefs[person1][item]-prefs[person2][item], 2)
                     for item in prefs[person1] if item in prefs[person2]])

   return 1/(1+sqrt(sum_of_squares))

# gets recommendations for a person by using a weighted average
# of every other user's rankings
def getRecommendations(prefs, person, similarity=sim_distance):
   totals={}
   simSums={}

   for other in prefs:
      if other==person: continue
      sim=similarity(prefs,person,other)

      if sim<=0: continue

      for item in prefs[other]:
         # only score those haven't seen yet
         if item not in prefs[person] or prefs[person][item]==0:
            #similarity * score
            totals.setdefault(item,0)
            totals[item]+=prefs[other][item]*sim
            # sum of similarities
            simSums.setdefault(item,0)
            simSums[item]+=sim

   #create the normolized list
   rankings=[(total/simSums[item],item) for item,total in totals.items()]

   # return the sorted list
   rankings.sort()
   rankings.reverse()
   return rankings

参数person表示被推荐人,而参数similarity表示计算Correlation and dependence的函数,默认值为sim_distance,其实也就是个Euclidean Distance.

Conclusion and next steps

小模型很简单,有空时可以完善一下算法.( 如果让C程序员看见如此大的稀疏矩阵,那得有多纠结 :( )

毕业之前的这段时间我都打算在学校里度过了.为了抓住时间,定个小计划吧:

• 学习Linux内核,主要是网络协议栈.
• 读完lighttpd代码,之后再读点其他代码.
• 写一个httpd.
• 彻底入门python.
• boost? design pattern?

为了SMART一点,我要多写博客,多努力.

最后,多放松,只剩下最后这点自由的日子了,唉~.

evhttp

evhttp库有几个主要的结构体,它们之间的联系非常龌龊:

其中,结构体event, min_heap, evsignal_info, eventop, event_base在前面几篇文章中已经介绍过了,这里不再啰嗦.

evbuffer

evbuffer用于读或写缓冲,图示为:

和evbuffer有关的外露接口主要是:

//从文件读数据到缓冲,读取量为max(howmuch, 4096)
int evbuffer_read(struct evbuffer *buf, int fd, int howmuch);

//把缓冲写出文件
int evbuffer_write(struct evbuffer *buffer, int fd)

evbuffer比较简单,不多介绍.

evhttp, evhttp_connection, evhttp_request

libevent对成员的命名不太在意,其实evhttp可以看做是echttpsever,它绑定到某个特定端口和地址(socket(), bind()),保存访问该server的连接(通过成员connections,).evhttp_connection是保存连接信息的结构体, evhttp_request表示请求.

看看http库的使用流程:

void http_handler(struct evhttp_request *req, void *arg)
{
    struct evbuffer *buf;
    buf = evbuffer_new();

    // 分析请求
    char *decode_uri = strdup((char*) evhttp_request_uri(req));
    struct evkeyvalq http_query;
    evhttp_parse_query(decode_uri, &http_query);
    free(decode_uri);

    // 从http头中获取参数
    const char *request_value = evhttp_find_header(&http_query, "data");

    // 返回HTTP头部
    evhttp_add_header(req->output_headers, "Content-Type", "text/html; charset=UTF-8");
    evhttp_add_header(req->output_headers, "Server", "my_httpd");
    //evhttp_add_header(req->output_headers, "Connection", "keep-alive");

    evhttp_add_header(req->output_headers, "Connection", "close");

    // 将要输出的值写入输出缓存
    if(request_value != NULL) {
        evbuffer_add_printf(buf, "%s", request_value);
    } else {
        evbuffer_add_printf(buf, "%s", "no error.");
    }

    // 输出
    evhttp_send_reply(req, HTTP_OK, "OK", buf);

    // 内存释放
    evhttp_clear_headers(&http_query);
    evbuffer_free(buf);
}

int main(int argc, char **argv)
{
    char *host_ip = "0.0.0.0";
    int host_port = 8080;
    int timeout = 3;

    struct evhttp *httpd;

    event_init();

    //根据host_ip和host_port创建一个addrinfo结构体,然后创建一个socket,绑定到这个socket后,
    //根据这些信息得到得到一个event(回调函数设置为accept_socket),然后将这个event关联到对应的event_base,
    //之后插入到&http->sockets队列中,然后返回&http
    httpd = evhttp_start(host_ip, host_port);

    if (httpd == NULL) {
        fprintf(stderr, "Error: Unable to listen on %s:%d\n\n", host_ip, host_port);
        exit(1);
    }

    // 设置请求超时时间
    evhttp_set_timeout(httpd, timeout);

    // 设置请求的处理函数
    evhttp_set_gencb(httpd, http_handler, NULL);

    event_dispatch();

    evhttp_free(httpd);

    return 0;
}

[1] 首先看看evhttp_start():

//创建一个evhttp,绑定到端口和地址
struct evhttp * evhttp_start(const char *address, u_short port)
{
	struct evhttp *http = evhttp_new_object();
	evhttp_bind_socket(http, address, port);
	return (http);
}

函数evhttp_bind_socket()代码如下:

//根据address和port创建一个非阻塞的socket,
//将其bind后的fd创建一个event(在这里设置好回调函数)后添加到&http->sockets
int evhttp_bind_socket(struct evhttp *http, const char *address, u_short port)
{
	int fd;
	int res;

	//绑定一个socket
	fd = bind_socket(address, port, 1 /*reuse*/);

	//根据fd创建一个event,设置好回调函数,
        //然后将这个event关联到对应的event_base,并将它插入到&http->sockets中.
	res = evhttp_accept_socket(http, fd);

	return (res);
}

在这里,函数bing_socket()的作用是根据地址和端口创建一个socket,返回bind()后的文件描述符.函数evhttp_accept_socket()的作用在注释中也说明了,其代码如下:

int evhttp_accept_socket(struct evhttp *http, int fd)
{
	struct evhttp_bound_socket *bound;
	struct event *ev;
	int res;

	bound = malloc(sizeof(struct evhttp_bound_socket));
	ev = &bound->bind_ev;

	/* Schedule the socket for accepting */
	//设置这个ev,回调函数为accept_socket,针对的文件描述符为fd
	event_set(ev, fd, EV_READ | EV_PERSIST, accept_socket, http);

	//将ev关联到&http->base
	EVHTTP_BASE_SET(http, ev);

	//将ev添加进&http->base
	res = event_add(ev, NULL);

	//将bound插入到&http->sockets
	TAILQ_INSERT_TAIL(&http->sockets, bound, next);
}

需要指出的是,在这个函数中,struct event *ev可以看成是服务器struct evhttp的代理,evhttp通过这个ev是否可读来注意到是否有新的连接.(后文会分析.)

[2] 函数evhttp_set_timeout()和evhttp_set_gencb()逻辑比较简单,分别设置超时时间和回调函数.

[3]重头戏来了,函数event_dispatch()负责分发,在前面的文章已经介绍过了,它最终会调用event_base_loop(),分别查看定时器最小堆,信号队列和I/O队列.在http库中,当有一个新的连接时,[1]中已加入到event_base已注册事件队列的事件ev->fd将变成可读,它被移入已就绪事件队列,然后由函数event_process_active()调用ev的回调函数accept_socket()(回调函数在evhttp_accept_socket()函数中设置).

需要说明的是,以下的内容都是在event_base_loop()死循环中被处理的.

现在看一下回调函数accept_socket()的代码:

//作为回调函数,accept 一个 socket
static void accept_socket(int fd, short what, void *arg)
{
	struct evhttp *http = arg;
	struct sockaddr_storage ss;
	socklen_t addrlen = sizeof(ss);
	int nfd;

        //获得accept()后的文件描述符
        nfd = accept(fd, (struct sockaddr *)&ss, &addrlen);

        //设置为非阻塞
	evutil_make_socket_nonblocking(nfd);

        //获得连接
	evhttp_get_request(http, nfd, (struct sockaddr *)&ss, addrlen);
}

代码很好懂,看看evhttp_get_request()函数:

//在回调函数accept_socket中被调用.
//这里传入的参数fd是accept()后返回的描述符
void evhttp_get_request(struct evhttp *http, int fd, struct sockaddr *sa, socklen_t salen)
{
	struct evhttp_connection *evcon;

	//根据fd和sa创建一个evhttp_connection,并将它关联到http->base.
	evcon = evhttp_get_request_connection(http, fd, sa, salen);

	if (http->timeout != -1)
		//watch out!!!在这里evcon会被设置超时时间.
		evhttp_connection_set_timeout(evcon, http->timeout);

	 //将evcon关联到http
	evcon->http_server = http;

	//将evcon插入到&http->connections
	TAILQ_INSERT_TAIL(&http->connections, evcon, next);

	evhttp_associate_new_request_with_connection(evcon);
}

跟踪下去看看evhttp_associate_new_request_with_connection()函数:

//初始化一个绑定到evcon的evhttp_request
static int evhttp_associate_new_request_with_connection(struct evhttp_connection *evcon)
{
	struct evhttp *http = evcon->http_server;
	struct evhttp_request *req;

        //在这里会设置该req的回调函数evhttp_handle_request(),此函数很重要..
	req = evhttp_request_new(evhttp_handle_request, http);

	req->evcon = evcon;
	req->flags |= EVHTTP_REQ_OWN_CONNECTION;

	TAILQ_INSERT_TAIL(&evcon->requests, req, next);

	req->kind = EVHTTP_REQUEST;

	req->remote_host = strdup(evcon->address);

	req->remote_port = evcon->port;

	evhttp_start_read(evcon);

	return (0);
}

经过这么多层次的函数调用,终于要读数据了,evhttp_start_read()代码:

void evhttp_start_read(struct evhttp_connection *evcon)
{
	/* Set up an event to read the headers */
	if (event_initialized(&evcon->ev))
		event_del(&evcon->ev);

	//根据这些参数设置好evcon->ev.回调函数为evhttp_read()
	event_set(&evcon->ev, evcon->fd, EV_READ, evhttp_read, evcon);

        //关联到event_base中
	EVHTTP_BASE_SET(evcon, &evcon->ev);

	//将该ev插入到event_base中

	//watch out!!!!
	//在这里会设置这个event的超时时间,它将被加入到定时器最小堆中
	//超时之后,该事件会被event_active(),插入到就绪队列中,然后执行其回调函数.

	//evcon->timeout是在evhttp_get_request()被设置的
	evhttp_add_event(&evcon->ev, evcon->timeout, HTTP_READ_TIMEOUT);
	evcon->state = EVCON_READING_FIRSTLINE;
}

可以看到,对于这个连接,evhttp_connection结构体evcon是通过内部成员event *ev来处理的.函数evhttp_start_read()对&evcon->ev设置好超时时间和回调函数后将它插入到event_base中.

直到这里,回调函数accept_socket()的功能终于完成了.

(3.2) 上一段提到accept_socket()函数最终会调用evhttp_start_read()来设置连接对应的event(&evcon->ev)的超时时间和回调函数,并将它插入已激活事件队列进行schedule.

在&evcon->ev超时之后,它会被函数timeout_process()从已激活事件队列移入已就绪事件队列,然后由函数event_process_active()调用它的回调函数,也即是evhttp_read()(此回调函数在函数evhttp_start_read()中设置).代码如下:

//读数据
void evhttp_read(int fd, short what, void *arg)
{
	struct evhttp_connection *evcon = arg;
	//拿到第一个req
	struct evhttp_request *req = TAILQ_FIRST(&evcon->requests);
	struct evbuffer *buf = evcon->input_buffer;
	int n, len;

	if (what == EV_TIMEOUT) {
		evhttp_connection_fail(evcon, EVCON_HTTP_TIMEOUT);
		return;
	}

	//从fd读数据到buf
	n = evbuffer_read(buf, fd, -1);
	len = EVBUFFER_LENGTH(buf);

	if (n == -1) {
		if (errno != EINTR && errno != EAGAIN) {
			event_debug(("%s: evbuffer_read", __func__));
			evhttp_connection_fail(evcon, EVCON_HTTP_EOF);
		} else {
			evhttp_add_event(&evcon->ev, evcon->timeout,
			    HTTP_READ_TIMEOUT);
		}
		return;
	} else if (n == 0) {
		/* Connection closed */
		evhttp_connection_done(evcon);
		return;
	}

	switch (evcon->state) {
	case EVCON_READING_FIRSTLINE:
		evhttp_read_firstline(evcon, req);
		break;
	case EVCON_READING_HEADERS:
		evhttp_read_header(evcon, req);
		break;
	case EVCON_READING_BODY:
		evhttp_read_body(evcon, req);
		break;
	case EVCON_READING_TRAILER:
		evhttp_read_trailer(evcon, req);
		break;
	case EVCON_DISCONNECTED:
	case EVCON_CONNECTING:
	case EVCON_IDLE:
	case EVCON_WRITING:
	default:
		event_errx(1, "%s: illegal connection state %d",
			   __func__, evcon->state);
	}
}

代码中的fd其实是evcon->fd,也就是accept()后返回的文件描述符..

函数evhttp_read()就这么一直读数据下去(可能经过了多次循环,因为在evhttp_accept_socket()函数中被设置了EV_PERSIST标志,所以它不会从已注册时间队列中被移除,而是不断的超时,不断地被调用其回调函数),直到数据读完了(这里经过了好多状态,非常让人不爽的是,libevent官网上连个FSM图都没有,这种体力活我也不会干的,哈哈~),就调用evhttp_connection_done(),代码如下:

//累个半死终于读完啦
static void evhttp_connection_done(struct evhttp_connection *evcon)
{
	...//省略

        //调用req的回调函数
	(*req->cb)(req, req->cb_arg);

}

在这里,会调用req的回调函数,也就是在函数evhttp_associate_new_request_with_connection()中设置的evhttp_handle_request(),此回调函数代码为:

//处理请求,在这里会调用http的回调函数http->gencb
static void evhttp_handle_request(struct evhttp_request *req, void *arg)
{
        ...//一堆无用的噪音

        //由用户指定的回调函数终于显灵了.
	if (http->gencb) {
		(*http->gencb)(req, http->gencbarg);
		return;
	}

}

在数据全都读入后,libevent终于终于终于调用了用户指定的回调函数(*http->gencb).在本文一开始的小例子中,也就是函数http_handler(),要达到这一步可真不容易啊,撒花..

由上文提到的种种的繁琐的过程可以看出,libevent对于user来说是很友善的,几句代码就可以实现一个httpd,可以对于developer来说就太恶心了..

Timer事件

反应堆event_base包含了一个最小堆min_heap结构体的实例,以此维护注册到这个反应堆实例的定时器事件:

struct event_base {
        //其他成员
	struct min_heap timeheap;
};

回顾一下最小堆min_heap:

typedef struct min_heap
{
    //p指向一个动态分配的数组,数组元素是event指针.
    struct event** p;
    unsigned n, a; // n表示目前保存了多少元素,a表示p指向的内存能够存储event指针的个数
} min_heap_t;

可以看到,它包含一个连续的内存块用于存储定时器事件.针对min_heap的操作主要有:

static inline int min_heap_push(min_heap_t* s, struct event* e);
static inline struct event*  min_heap_pop(min_heap_t* s);

其中,min_heap_push()用于插入节点,min_heap_pop()用于弹出节点.其内部逻辑很简单,不必描述了.

现在看看libevent处理定时器事件的例子:

static void timeout_cb(int fd, short event, void *arg) {...}

int main (int argc, char **argv)
{
	struct event timeout;
	struct timeval tv;

        event_init();

	evtimer_set(&timeout, timeout_cb, &timeout);

	evutil_timerclear(&tv);
	tv.tv_sec = 2;
	event_add(&timeout, &tv);

	lasttime = time(NULL);

	event_dispatch();
}

首先,和上篇文章例子一样的,event_init()初始化一个event_base(反应堆实例),然后由evtimer_set()设置定时器事件的回调函数,接着event_add()把定时器事件加入反应堆实例中.最后进入event_dispatch()主循环.

在这里,evtimer_set定义如下:

#define evtimer_set(ev, cb, arg)	event_set(ev, -1, 0, cb, arg)

至于event_set(),没有什么好说的,就是对一个event结构体做初始化罢了.

上一篇文章已经从I/O事件的角度介绍了event_add(),这里看看它是如何处理定时器事件的:

int event_add(struct event *ev, const struct timeval *tv)
{
    struct event_base *base = ev->ev_base;

    ....//处理IO事件或者信号事件的逻辑.

    //如果tv不为0
    if (tv != NULL)
    {
        event_queue_insert(base, ev, EVLIST_TIMEOUT);
    }
}

可以看到,event_add()会把一个定时器事件压入到其对应的反应堆实例下的定时器最小堆timeheap中(&ev->base.timeheap).

回到event_dispatch(),它会调用event_base_loop(),此函数对定时器事件处理如下:

//事件主循环
int
event_base_loop(struct event_base *base, int flags)
{
    ...//不必多虑的其他代码

    done = 0;
    while (!done)
    {
	//检查heap中的timer events,将就绪的timer event从heap上删除,并插入到激活链表中,
	//这意味着base->event_count_active会增加
        timeout_process(base);

	//有就绪事件了
        if (base->event_count_active)
        {
            //处理就绪事件吧.
            event_process_active(base);
        }
    }
}

其中,timeout_process()会将已超时的定时器事件插入到反应堆实例下的已就绪事件队列中,接着由event_process_active()处理已就绪事件.event_process_active()代码在上一篇文章中已经介绍过了,这里看一下timeout_process():

/时间到~~~
//开始处理base里面的定时器堆里的事件鸟.
//检查heap中的timer events,将就绪的timer event从heap上删除,并插入到激活链表中
void timeout_process(struct event_base *base)
{
    struct timeval now;
    struct event *ev;

   while ((ev = min_heap_top(&base->timeheap)))
    {
    	//ev超时时间的比现在的时间大,也就是说,这个ev还没有超时,那么while循环结束
        if (evutil_timercmp(&ev->ev_timeout, &now, >))
            break;

	//else 意味着 evutil_timercmp(&ev->ev_timeout, &now, <=)为真
	//也就说明定时器最小堆的根超时了

        //从定时器堆删除
        event_del(ev);

	//把它插到激活链表吧.
        event_active(ev, EV_TIMEOUT, 1);
    }
}

Signal事件

signal事件的处理时libevent中比较难懂的地方,前人之述不详,本文重点讲解之.

反应堆event_base包含了一个evsignal_info结构体的实例,来维护注册到这个反应堆实例的信号事件:

struct event_base {
        //其他成员
	struct evsignal_info sig;
};

这里仔细研究一下evsignal_info结构体的定义:

struct evsignal_info {

	//为 socket pair 的读 socket向 event_base 注册读事件时使用的 event 结构体
	//这个是所有信号事件共用的.
	struct event ev_signal; 

	//这个也是所有信号事件共用的.
	int ev_signal_pair[2]; 

	//记录ev_signal 事件是否已经注册了
	int ev_signal_added;

	//是否有信号发生的标记
	//只在evsignal_handler()中被修改为1
	volatile sig_atomic_t evsignal_caught;

	//evsigevents[signo]表示注册到信号 signo 的事件链表
	struct event_list evsigevents[NSIG];

	//具体记录每个信号触发的次数,evsigcaught[signo]是记录信号signo被触发的次数
	sig_atomic_t evsigcaught[NSIG];

	//记录了原来的signal处理函数指针,当信号signo注册的event被清空时,需要重新设置其处理函数
	struct sigaction **sh_old;
};

要了解evsignal_info为何是这样设计的,首先需要明白int ev_signal_pair[2];的作用.它实际上表示两个文件描述符,在libevent中一个用于写,一个用于读,它们在event_init()是被初始化.好吧,其实更确切点说,event_init()会调用event_base_new(),而event_base_new()调用封装好I/O多路复用技术的结构体eventop实例(&event_base->evsel)的init函数(&event_base->evsel),这个init函数会初始化eventop实例的内部数据结构,然后调用evsignal_init()对evsignal_info结构体实例(&event_base->sig)做初始化.而在初始化实例的过程中,对其内部的ev_signal_pair[2]数组的初始化是通过调用evutil_socketpair()函数来实现的.够了,上面这段话已经够恶心了,图示如下:

看看evutil_socketpair()代码:

int
evutil_socketpair(int family, int type, int protocol, int fd[2])
{
#ifndef WIN32
	return socketpair(family, type, protocol, fd);
#else
       ...//山寨一个socketpair函数
}

它使用socketpair系统调用创建一对全双工管道(如果有时间的话,可以读一下evutil_socketpair()后半部分的代码,它在WIN32环境下如何山寨了一个socketpair函数,熟悉之可以加深不少理解.).这个全双工管道有什么用呢? 这里先卖个关子,我们看看evsignal_info结构体下的成员struct event ev_signal是如何被初始化的.

evsignal_init()调用event_set()函数,event_set()将&event_base->sig.ev_signal.ev_fd设置为&event_base->sig.ev_signal_pair[1],其回调函数为evsignal_cb(). ([1]).

至此,铺垫基本上做好了.我们看一个使用libevent处理信号事件的例子吧:

static void signal_cb(int fd, short event, void *arg) {...}

int main (int argc, char **argv)
{
	/* Initalize the event library */
        event_init();

	struct event signal_int;
	event_set(&signal_int, SIGINT, EV_SIGNAL|EV_PERSIST, signal_cb, &signal_int);

	event_add(&signal_int, NULL);

	event_dispatch();
}

首先是由event_init()创建一个反应堆实例(在此背后,对维护信号事件的结构体evsigal_info的实例(&event_base.sig)如何被初始化在上文已经做了介绍了.),然后由event_set()设置一个事件,将其标志&signal_int.events设为EV_SIGNAL|EV_PERSIST,文件描述符&signal_int.ev_fd设置对应的信号(在例子中是SIGIN,即中断信号,中断下可以用ctrl-c触发).然后设置好这个信号事件对应的回调函数 ([2]注意,回调函数对应的是信号事件,而非信号.注意与[3]的不同.).

之后,调用event_add()将信号事件注册到反应堆实例中,event_add()对信号事件的处理如下:

int event_add(struct event *ev, const struct timeval *tv)
{
    struct event_base *base = ev->ev_base;
    const struct eventop *evsel = base->evsel;
    void *evbase = base->evbase;
    int res = 0;

    //ev->ev_events表示事件类型
    //如果ev->ev_events是 读/写/信号 事件,而且ev不在 已注册链表 或 已激活链表,那么调用evbase注册ev事件
    if ((ev->ev_events & (EV_READ|EV_WRITE|EV_SIGNAL)) &&
            !(ev->ev_flags & (EVLIST_INSERTED|EVLIST_ACTIVE)))
    {
	//实际执行操作的是evbase
        res = evsel->add(evbase, ev);

        if (res != -1) //注册成功,把事件ev插入 已注册链表 中
            event_queue_insert(base, ev, EVLIST_INSERTED);
    }
}

为了描述方便,我们假定libevent使用的I/O多路复用技术是select,看看select_add()代码吧:

static int select_add(void *arg, struct event *ev)
{
	if (ev->ev_events & EV_SIGNAL)
		return (evsignal_add(ev));
}

对于信号事件,它转手给evsignal_add()函数处理,evsignal_add()代码如下:

//将信号事件ev下的描述符ev_fd(也就是信号)添加到&ev->ev_base->sig->evsigevents[ev_fd]队列中
int evsignal_add(struct event *ev)
{
    int evsignal;
    struct event_base *base = ev->ev_base;
    struct evsignal_info *sig = &ev->ev_base->sig;

    //拿到event下的信号标号
    evsignal = EVENT_SIGNAL(ev);

    if (TAILQ_EMPTY(&sig->evsigevents[evsignal]))
    {
		//设置这个事件对应的信号对应的处理函数

		//watch out!!!!针对的是信号,不是事件
	if (_evsignal_set_handler(
                    base, evsignal, evsignal_handler) == -1)
            return (-1);

	//这里注册的sig本身,而不是信号事件
	//也就是就是说,sig是在真正有信号事件时才注册的.
        if (!sig->ev_signal_added)
        {
            //注册这个信号对应的事件
            if (event_add(&sig->ev_signal, NULL))
                return (-1);
            sig->ev_signal_added = 1;
        }
    }

    //多个事件可能对应同一信号
    TAILQ_INSERT_TAIL(&sig->evsigevents[evsignal], ev, ev_signal_next);
}

evsignal_add()函数先获得信号事件对应的信号,通过_evsignal_set_handler()函数将此信号相应的信号处理函数设置为evsignal_handler(). ([3]注意,[2]设置的回调函数是针对信号事件的,这里设置的处理函数才是针对信号的.) 接着,evsignal_add()判断sig->ev_signal_added是否为0,为0则将&sig->ev_signal事件注册到反应堆实例中,然后将sig->ev_signal_added置1。;如果不为0,那么跳过这段代码.需要指出的是,sig->ev_signal_added唯一一次被置1就是在这段代码中,这保证了&sig->ev_signal事件只被注册到反应堆实例中一次.其实也就是说,只有在第1次有信号事件需要通过event_add()被注册到反应堆实例时,&sig->ev_signal事件才会被一起注册,这是libevent对&event_base->sig的延后处理.

<hr/>

接下来,貌似应该讲讲event_dispatch()对信号事件的处理了.且慢,我们回头把 [1], [2], [3] 整理一下:

(1) 在调用event_init()新建一个反应堆实例(以base表示)时,evsignal_info结构体(libevent用它来管理信号事件集合) base->sig被初始化,base->sig->ev_signal的回调函数总是被设置为evsignal_cb(),而evsignal_cb()是定义在libevent内部的,对libevent用户完全透明,其代码如下:

static void
evsignal_cb(int fd, short what, void *arg)
{
    recv(fd, signals, sizeof(signals), 0);
}

它从一个文件描述符(后文会看到,这个文件描述符总是&event_base->sig.ev_signal_pair[1])读1比特的数据.

(2) 在已经通过调用event_init()获得一个反应堆实例后,通过event_set()设置一个信号事件signal_int的文件描述符signal_int.ev_fd(其实对于信号事件而言,ev_fd也就是此信号事件对应的信号),event_set()还设置了这个信号事件的回调函数.很明显,对于同一个信号,可以有不同的信号事件,这些信号事件的回调函数也可以完全不同.在这里,回调函数是由用户设计的,表示信号被触发时希望作出的反馈函数.

(3) 为了将一个事件(这个事件可以是I/O事件,也可以是定时器事件,也可以是信号事件)注册到反应堆实例中,我们必须调用event_add(),而event_add()通过重重调用,最终由evsignal_add()来完成将信号事件注册.回顾一下evsignal_add():

它通过_evsignal_set_handler总是将信号事件对应的信号的处理函数设置为evsignal_handler(),evsignal_handler()代码如下:

//通知event_base有信号发生的技巧,往sig.ev_signal_pair[0]写1字节数据
//会设置sig.evsignal_caught = 1,标记有信号产生.
static void evsignal_handler(int sig)
{
    evsignal_base->sig.evsigcaught[sig]++;
    evsignal_base->sig.evsignal_caught = 1; //将信号发生标志至1

    send(evsignal_base->sig.ev_signal_pair[0], "a", 1, 0);
}

它将信号发生标志evsignal_base->sig.evsignal_caught置1,以此通过libevent有信号发生.然后往&event_base->sig.ev_signal_pair[0]写1比特数据.

<hr/>

好吧,现在终于可以看看libevent是如何处理信号事件的了:

libevent先进入event_base_loop()主循环,等待已经准备好(可读可写或异常)的事件(通过select_dispatch找出已准备好的文件描述符).当有一个信号产生时,由于这个信号的信号处理函数(总是evsignal_handler())总是会往&event_base->sig.ev_signal_pair[0]写1比特数据(这是由操作系统调用的,对libevent是透明的,对libevent的用户就更加透明了).此时,根据前面的描述,由于ev_signal_pair[0]与ev_signal_pair[1]是一对全双工管道,所以,ev_signal_pair[1]将变得可读.而&event_base->sig.ev_signal事件的文件描述符正是ev_signal_pair[1],所以libevent可以知道&event_base->sig.ev_signal事件准备好了.为此,&event_base->sig.ev_signal事件被移入反应堆实例下的已就绪事件队列.接着在event_base_loop()的后续部分代码中被处理,通过event_process_active()调用其回调函数,也就是evsignal_cb(),从&event_base->sig.ev_signal_pair[1])读1比特的数据.[4]我们把信号被捕捉到的这个while()循环记为第1次while()循环.

写到这里,仍然有一个疑惑没有解开,上面都是讲libevent内部定义的&event_base->sig.ev_signal如何如何,可是我们希望的是自己定义的信号事件signal_int如何如何啊.

答案是,正如(3)描述的那样,在操作系统调用信号处理函数evsignal_handler()时,它会将信号发生标志置1.然后将evsignal_info结构体中用于记录信号被捕捉次数的evsigcaught[id]++,id也就是这个信号.

在第2此while()循环时(参考[4]),它还是调用select_dispatch(),这时,由于信号发生标志为1,所以select_dispatch()会调用函数evsignal_process().select_dispatch()相关代码如下:

static int
select_dispatch(struct event_base *base, void *arg, struct timeval *tv)
{
        if (base->sig.evsignal_caught){
		evsignal_process(base);
}

evsignal_process()代码如下:

void evsignal_process(struct event_base *base)
{
    struct evsignal_info *sig = &base->sig;
    struct event *ev, *next_ev;
    sig_atomic_t ncalls;
    int i;

    base->sig.evsignal_caught = 0;
    for (i = 1; i < NSIG; ++i)
    {
        ncalls = sig->evsigcaught[i];
        if (ncalls == 0)
            continue;
        sig->evsigcaught[i] -= ncalls;

        for (ev = TAILQ_FIRST(&sig->evsigevents[i]);
                ev != NULL; ev = next_ev)
        {
            next_ev = TAILQ_NEXT(ev, ev_signal_next);
            if (!(ev->ev_events & EV_PERSIST))
                event_del(ev);

	    //移到已就绪事件队列,ncalls回调函数将会被调用多少次
            event_active(ev, EV_SIGNAL, ncalls);
        }
    }
}

总结一下,反应堆结构体event_base有一个数据成员evsignal_info结构体,它维护信号事件集.之所以evsignal_info会有一个event事件成员ev_signal,是因为libevent通过socket pair让操作系统通知自己有信号发生,在信号处理函数中将信号发生标志置1,并使该信号被捕捉的次数自增,然后ev_signal被移到已就绪事件队列,接着被处理.然后libevent检查到信号发生标志已经被置1,遍历所有信号事件,找出信号被捕捉次数不为0的那个信号事件集,将它们移到已就绪事件队列,然后处理之.

以上,就是libevent处理信号事件的逻辑.

例子如下:

static void fifo_read(int fd, short event, void *arg) {...}

int main (int argc, char **argv)
{
	int socket = open ("/tmp/event.fifo", O_RDONLY | O_NONBLOCK, 0);

	fprintf(stdout, "Please write data to %s\n", fifo);	

	event_init();

	struct event evfifo;
	event_set(&evfifo, socket, EV_READ, fifo_read, &evfifo);

	event_add(&evfifo, NULL);

	event_dispatch();
}

libevent库的使用方法大体上就像例子展示的那样,先由event_init()得到一个event_base实例(也就是反应堆实例),然后由 event_set()初始化一个event,接着用event_add()将event绑定到event_base,最后调用event_dispatch()进入时间主循环.

event_init()和event_set()功能都很简单,它们分别对event_base结构体和event结构体做初始化.我们直接看看event_add():

//为了思路清晰,这里分析的是I/O事件,暂不考虑信号和定时器相关处理代码.

//函数将ev注册到ev->ev_base上,事件类型由ev->ev_events指明.如果注册成功,ev将被插入到已注册链表中.
int event_add(struct event *ev, const struct timeval *tv)
{
	//得到ev对应的反应堆实例event_base
    struct event_base *base = ev->ev_base;

	//得到libevent选择的已封装的I/O多路复用技术
    const struct eventop *evsel = base->evsel;

    void *evbase = base->evbase;
    int res = 0;

    //ev->ev_events表示事件类型
    //如果ev->ev_events是 读/写/信号 事件,而且ev不在 已注册队列 或 已就绪队列,
    //那么调用evbase注册ev事件
    if ((ev->ev_events & (EV_READ|EV_WRITE|EV_SIGNAL)) &&
            !(ev->ev_flags & (EVLIST_INSERTED|EVLIST_ACTIVE)))
    {

		//实际执行操作的是evbase
        res = evsel->add(evbase, ev);

		 //注册成功,把事件ev插入已注册队列中
        if (res != -1)
            event_queue_insert(base, ev, EVLIST_INSERTED);
    }

    return (res);
}

注释已经很明了了,如果一个事件不在已注册队列或者已激活队列,而且它是I/O事件或者信号事件,那么调用select_add()将ev插入到selectop的内部数据结构中(本文以select为例,下文不再说明.).select_add()代码如下:

//略去信号处理的相关代码

static int select_add(void *arg, struct event *ev)
{
    struct selectop *sop = arg;

    //如果是读类型事件,把该事件的文件描述符加入到selectop维护的读fd_set集
    //event_readset_in中,并且把该事件插入到读事件队列.
    if (ev->ev_events & EV_READ)
    {
        FD_SET(ev->ev_fd, sop->event_readset_in);
        sop->event_r_by_fd[ev->ev_fd] = ev;
    }

    //略去对写事件的处理
}

小结一下,结合event_add()代码和select_add()代码,可以看出在调用event_add()时,事件将被插入其对应的反应堆实例event_base的已注册事件队列中,而且还会被加入到selectop维护的内部数据结构中进行监视.

现在可以看看event_dispatch()代码了:

//略去信号事件和定时器事件处理的相关代码

int event_dispatch(void)
{
    return (event_loop(0));
}

int event_loop(int flags)
{
    return event_base_loop(current_base, flags);
}

//事件主循环
int event_base_loop(struct event_base *base, int flags)
{
    const struct eventop *evsel = base->evsel;
    void *evbase = base->evbase;
    struct timeval *tv_p;
    int res, done;

    done = 0;
    while (!done)
    {
	//从定时器最小堆中取出根节点,其时间值作为select最大等待时间
	//如果定时器最小堆没有元素,那么select最大等待时间为0
	timeout_next(base, &tv_p);

	//调用select_dispatch(),它会将已经准备好的事件移到已就绪事件队列中
        res = evsel->dispatch(base, evbase, tv_p);

	//有就绪事件了,那就处理就绪事件吧.
        if (base->event_count_active)
            event_process_active(base);
    }
}

event_base_loop()先从定时器最小堆中取出根节点作为select的最大等待时间,然后调用select_dispatch()将已经准备好的事件移到已就绪事件队列中,最后调用event_process_active()处理已就绪事件队列.

//略去信号事件和定时器事件处理的相关代码

static int select_dispatch(struct event_base *base, void *arg, struct timeval *tv)
{
    int res, j;
    struct selectop *sop = arg;

    //根据前面对select_add()的解释,事件fd已被加入到fd_set集中进行监视.
    res = select(sop->event_fds + 1, sop->event_readset_out,
                 sop->event_writeset_out, NULL, tv);

    for (j = 0, res = 0; j <= sop->event_fds; ++j, res = 0)
    {
        struct event *r_ev = NULL, *w_ev = NULL;

       //找出已经准备好读的事件
        if (FD_ISSET(j, sop->event_readset_out))
        {
            r_ev = sop->event_r_by_fd[i];
            res |= EV_READ;
        }

       //将已经准备好读的事件移到已就绪事件队列
        if (r_ev && (res & r_ev->ev_events))
            event_active(r_ev, res & r_ev->ev_events, 1);

	//略去对已经准备好写的事件的处理
    }
}

看看在event_base_loop()中被调用的event_process_active()代码:

static void event_process_active(struct event_base *base)
{
    struct event *ev;
    struct event_list *activeq = NULL;
    int i;
    short ncalls;

    //寻找最高优先级(priority值越小优先级越高)的已就绪事件队列
    for (i = 0; i < base->nactivequeues; ++i)
    {
        if (TAILQ_FIRST(base->activequeues[i]) != NULL)
        {
            activeq = base->activequeues[i];
            break;
        }
    }

    for (ev = TAILQ_FIRST(activeq); ev; ev = TAILQ_FIRST(activeq))
    {
	//如果有persist标志,则只从激活队列中移除此事件,
        if (ev->ev_events & EV_PERSIST)
            event_queue_remove(base, ev, EVLIST_ACTIVE);

        else //否则则从激活事件列表,以及已注册事件中双杀此事件
            event_del(ev);

        ncalls = ev->ev_ncalls;
        ev->ev_pncalls = &ncalls;

	//每个事件的回调函数的调用次数
        while (ncalls)
        {
            ncalls--;
            ev->ev_ncalls = ncalls;

	    //调用回调函数
            (*ev->ev_callback)((int)ev->ev_fd, ev->ev_res, ev->ev_arg);
        }
    }
}

现在,看看这个被阉割的只考虑I/O事件的libevent主循环框架:

event_base_loop:

	while()
	{
		//从定时器最小堆取出select最大等待时间

		//select出已准备事件,将它们移到已就绪事件队列中

		//处理已就绪事件
	}

这真是篇节能环保的文章啊,哈哈.因为libevent代码太恶心了,描述出来都觉得恶心,有空得拿来重构下..下篇文章会讲讲libevent中非常恶心的信号集成处理.

libevent是一个开源的跨平台网络库,属于事件驱动机制,支持多种I/O多路复用技术,从其主页 http://www.monkey.org/~provos/libevent/ 可以看到libevent使用者众多,其中甚至包括 Memcached.

本文参照的版本是主版本号为1的最后一个版本1.4.14(没办法,2.0.1版本代码量都在4W+行以上了, :-(

File Tree

先看一下libevent的文件组织, 源文件数目是:

源代码总行数是:

Structure Call Graph

先送上一张高清无码大图:

[虚线表示包含关系,其label表示是通过哪个成员变量来包含另一个结构体的.]

从上图的虚线指向可以看出, event_base 是绝对的核心,它包含了定时器事件最小堆结构 min_heap ,信号事件队列结构 evsignal_info 和I/O事件队列结构 eventqueue ,也就是说,libevent把定时器,I/O,信号这些事件都统一到event_base管理.另外,既然libevent是事件驱动的,那么事件属性也很自然的自成一个结构体了,就是 event .

最后,结构体 eventop 是拿来封装多种I/O多路复用技术的,主要是起隐藏底层系统机制的作用.

Tail Queue

evsignal_info 和 eventqueue 都是tail queue结构,其定义如下:

A tail queue is headed by a pair of pointers, one to the head of the list and the other to the tail of the list. The elements are doubly linked so that an arbitrary element can be removed without a need to traverse the list. New elements can be added to the list before or after an existing element, at the head of the list, or at the end of the list. A tail queue may be traversed in either direction.

tail queue有两个指针,分别指向头部和尾部.它的元素是双向链接的,所以无须遍历整个序列就可以删除任意一个元素,而且,新的元素也可以在任意位置插入,不管是在一个已存在元素的前后,还是在队列头部,还是尾部.一个tail queue可以双向遍历.

很自然的,一个tail queue有多种实现方式,在libevent中,使用的是linux下的/usr/include/sys/queue.h,我们看看linux的实现(这个纯宏实现了4种数据结构,任何一行除了注释就是宏,非常牛逼.):

#define TAILQ_HEAD(name, type)						\
struct name {								\
	struct type *tqh_first;	/* first element */			\
	struct type **tqh_last;	/* addr of last next element */		\
}

#define TAILQ_ENTRY(type)						\
struct {								\
	struct type *tqe_next;	/* next element */			\
	struct type **tqe_prev;	/* address of previous next element */	\
}

使用方式如下:

struct QUEUE_ITEM //定义节点的结构体
{
	int value; //在这里可以定义一系列的数据
	TAILQ_ENTRY(QUEUE_ITEM) entries; //作为队列入口
};   

//定义一个匿名队列的头部,这个队列的节点结构为 QUEUE_ITEM
TAILQ_HEAD(,TAILQ_ITEM) queue_head;

从上面对这些宏的使用可以看出,节点的数据结构是自由定义的(废话),但是一定得包含有这个节点相应于队列的入口.当然,我们很容易就可以将一个节点扩展为对应多个队列,只要在这个节点的定义中有多个队列入口成员就可以了.下文将会讲到,事件结构体event就做了这种扩展.

这篇文章 对tail queue有比较详细的介绍,强烈建议仔细看完,因为Tail Queue在libevent中几乎是无处不在的.

event

首先看看event的成员:

//event提供了函数接口,供Reactor在事件发生时调用,以执行相应的事件处理,
//通常它会绑定一个有效的句柄(ev_fd)做为回调函数的参数.
struct event {

	//已注册事件队列入口
	TAILQ_ENTRY (event) ev_next;

	//已激活事件队列入口
	TAILQ_ENTRY (event) ev_active_next;

	//信号事件队列入口
	TAILQ_ENTRY (event) ev_signal_next;

	//表示该event在定时器事件最小堆min_heap的索引
	unsigned int min_heap_idx;	/* for managing timeouts */

	//该事件所属的反应堆实例
	struct event_base *ev_base;

	//对于I/O事件,是绑定的文件描述符; 对于signal事件,是绑定的信号.
	int ev_fd;

	//表示事件类型: I/O,定时器或者信号
	short ev_events;

	//事件就绪执行时,将要调用ev_callback 的次数,通常为1
	short ev_ncalls;

	//该事件的超时时间,在定时器最小堆min_heap操作中作为节点值进行比较.
	struct timeval ev_timeout;

	//该事件的优先级,越小越优先.
	int ev_pri;		/* smaller numbers are higher priority */

	//该事件被激活时的回调函数
	void (*ev_callback)(int, short, void *arg);

	//该事件的标记信息,表示其当前的状态,即它在哪个链表中
	int ev_flags;

	... //其他成员.
};

可以看到,一个事件是可以插入到多个队列的,当它与一个反应堆实例(event_base)关联时,这个事件被插入到反应堆实例下的已注册事件队列 event_base -> eventqueue ,当它处于就绪状态时,会被插入到反应堆实例下的已激活事件队列 event_base -> activequeues[id], id = event -> ev_pri .同时,如果此事件是信号事件,那么它会被插入到反应堆结构体下的信号事件结构体下的信号队列 event_base -> evsignal_info -> evsigevents[id], id = event -> ev_fd .

需要指出的,每个事件都保持了一个成员 struct event_base *ev_base; ,它表示该事件属于哪个反应堆实例.

还有一个成员需要注意, short ev_events; ,它表明此事件的事件类型,libevent正是基于此实现对I/O,信号,定时 3种事件的封装的.

min_heap

min_heap是存储定时事件的最小堆,它应该是libevent里最简单的结构体了:

typedef struct min_heap
{
    struct event** p; //p指向一个动态分配的数组,数组元素是event指针.
    unsigned n, a; // n表示目前保存了多少元素,a表示p指向的内存能够存储event指针的个数.
} min_heap_t;

之所以会有这个结构体,是因为I/O多路复用机制,比如说select,往往要求一个最大等待时间,而最小堆的根节点表示的就是最小超时时间,所以把根节点时间值传给select作为其最大等待时间就可以了.而在堆中取出根节点复杂度为O(1).

btw,从min_heap的成员p可以看出,libevent使用的是开辟一块连续存储区(即数组)来实现堆的策略.这很容易就可以办到,无非就是shift_up和shift_down操作罢了,但是libevent做了小小的优化,这导致了算法的不清晰,有点得不偿失的感觉,不提为妙.

eventop

eventop实现了对系统I/O多路复用机制的封装,这些机制包括 select poll epoll evport kqueue devpoll (别忘了libevent是跨平台的).

看看eventop的成员吧:

struct eventop {
	const char *name; //表示哪种I/O多路复用机制
	void *(*init)(struct event_base *); //初始化
	int (*add)(void *, struct event *); //注册事件
	int (*del)(void *, struct event *); //删除事件
	int (*dispatch)(struct event_base *, void *, struct timeval *); //事件分发
	void (*dealloc)(struct event_base *, void *); //注销,释放资源

	//是否需要重新初始化
	int need_reinit;
};

可以看到,eventop里面包含了5中操作的函数指针,libevent就是通过这一点来实现封装的.不同的机制定义不同的操作,但这些操作的接口却是保持一致的,以select接口为例:

const struct eventop selectops =
{
    "select",
    select_init,
    select_add,
    select_del,
    select_dispatch,
    select_dealloc,
    0
};

其中,5个select_* 成员都是函数指针,不同机制的函数以static形势封装在不同的文件下 ,举个例子, static void *
select_init(struct event_base *base) 函数的声明和定义在select.c文件下,而epoll机制的初始化函数 static void *
epoll_init(struct event_base *base) 声明和定义在epoll.c文件下.

好了,做好了这些准备,各机制的信息已经隐藏起来了,那么到底该怎样封装呢? libevent借助了一个static数组来保存这些I/O复用机制的结构体指针,代码如下:

#ifdef HAVE_EVENT_PORTS
extern const struct eventop evportops;
#endif
#ifdef HAVE_SELECT
extern const struct eventop selectops;
#endif
...
#ifdef WIN32
extern const struct eventop win32ops;
#endif

static const struct eventop *eventops[] =
{
#ifdef HAVE_EVENT_PORTS
    &evportops,
#endif
#ifdef HAVE_SELECT
    &selectops, //在select.c中
#endif
...
#ifdef WIN32
    &win32ops,
#endif
    NULL
};

其中, HAVE_* 宏是在configure时保存在config.h中的.注意在声明 evportops selectops 等变量时使用的是extern,由此使编译器知道这是外部变量,在别处寻找,或者在链接时寻找其符号名.(在libevent中,是在链接时才寻找到symbol的,封装嘛..)

封装已经ok了,那么程序运行时应该选择哪种I/O多路复用机制呢? libevent很不人性化的一点就在这里,它没有用配置文件或者config.h信息来保证用户可以灵活的选择,而是写死在代码里了(当然,手动修改代码重编译就是唯一的方法了.说到这里,还有一点要吐槽的是,libevent用的autoconf,configure文件和makefile文件难懂异常,在这方面完败于手工编写makefile的nginx.). 代码正是上面的 struct eventop *eventops[] 数组,此数组最后一个有效的元素就是libevent选择的机制.选择代码如下:

//初始化一个反应堆实例
struct event_base *event_base_new(void)
{
    ...
    for (i = 0; eventops[i] && !base->evbase; i++)
    {
        //选定I/O多路复用机制
        base->evsel = eventops[i];
    }
    ...
}

evsignal_info

evsignal_info 是用来管理信号事件的,代码如下:

struct evsignal_info {

	//是否有信号发生的标记
	volatile sig_atomic_t evsignal_caught;

	//evsigevents[signo]表示注册到信号 signo 的事件链表
	struct event_list evsigevents[NSIG];

	//具体记录每个信号触发的次数,evsigcaught[signo]是记录信号signo被触发的次数
	sig_atomic_t evsigcaught[NSIG];

	... //其他成员
};

其中, struct event_list evsigevents[NSIG]; 成员是一个数组,它的元素 evsigevents[id] 表示注册到信号id的事件链表.

关于evsignal_info 还有很多很多要说的,这留给下篇文章,本文对其描述到此为止.

event_base

终于到了最最核心的 event_base 了.秒杀之,代码如下:

struct event_base {

	//保存I/O机制
	const struct eventop *evsel; 

	//有多少个event
	int event_count;		/* counts number of total events */ 

	//有多少个活动的event
	int event_count_active;	/* counts number of active events */ 

	//存储已就绪事件队列的数组
	struct event_list **activequeues;

        //已就绪事件队列数组的元素个数
	int nactivequeues;

	//保存信号事件队列的结构体
	struct evsignal_info sig;

	//已注册事件队列
	struct event_list eventqueue; 

	//这是定时器事件最小堆
	struct min_heap timeheap;

	...//其他成员
};

重要的数据成员的说明已经在注释中给出了.相信我,回头看看前面event的描述吧.

Conclusion and next steps

本文介绍了libevent主要的结构体,接下来会分析事件处理框架或者是信号/定时器如何集成到I/O处理中的.我还没决定呢.