Review The C10K Problem - Part 1
今天又重新读了 The C10K Problam，决定好好写份摘要记录下学到的内容。
文章主要探讨了如何配置操作系统或者编写相应的程序可以支持10K数量级以上的客户端。目前有不少IO框架可供选择使用，譬如重量级的ACE，轻量级的libevent等。
I/O 策略
开发网络应用一般有一些好的I/O策略可以参考：
- 是否以及如何在单线程里面处理多I/O调用
- 完全不使用阻塞和同步调用，尽可能使用多进程和多线程实现并发
- 使用非阻塞(non-blocking)调用开始I/O操作(write()系统调用设置O_NONBLOCK参数)，使用readiness notification(poll或者/dev/poll)来确定何时启动下一个I/O通道。当然这只能在网络I/O环境下有效。
- 使用异步调用(如aio_write())开始I/O操作，使用completion notification(信号或者completion ports)来获取I/O完成的时间。在网络I/O和磁盘I/O都有好处。
- 如何编写服务客户端的代码
- 为每一个客户端准备一个进程(自1980年以来经典的ＵNIX方式)
- 每个OS级别的线程服务多客户端，每个客户端收以下方式控制：
- user-level 用户级别线程(例如GUN state线程，经典的Java绿色线程)
- 状态机
- continuation
- 为每个客户端准备一个OS级别线程(例如native方式的Java线程)
- 为每个活跃客户端准备一个OS级别线程(例如使用Apache做前端的Tomcat，NT completion ports，线程池)
- 是否使用标准的I/O服务，或者将一些代码移至内核(例如自定义驱动，内核模块或者VxD)
Level triggered & Edge triggered
采用哪种通知机制非常关键，主要有两种readiness notification类型，基于level-triggered的方式有传统的select()和poll()系统调用，level-triggered针对file descriptors的condition改变进行通知，一旦condition出现变化，那么用select()系统调用会检测到。而edge-triggered这个概念在BSDCON 2000大会上关于kqueue()的论文里面由Jonathon Lemon提出的，和level-triggered不同的是，这种通知不取决于condition的改变，而是取决于事件源的活动。
下面是引自 Kqueue 这篇论文里面的说明：
Events will normally considered to be “level-triggered”, as opposed to “edge-triggered”. Another way of putting this is to say that an event is be reported as long as a specified condition holds, rather than when activity is actually detected from the event source. The given condition could be as simple as “there is unread data in the buffer”, or it could be more complex. This approach handles the scenario described above, and allows the application to perform a partial read on a buffer, yet still be notified of an event the next time it calls the API. This corresponds to the existing semantics provided by poll() and select().
