[DRAFT]关于网络服务器编程模式（未完成）

1. 同步线程模式 (Synchronous Thread Model)
1.1 实现机制
同步线程模式大家都应该很熟悉了，它也可以称为“拥塞模式”（The Blocking Model）或者是同步方法调用模式（Synchronous Method Call）。在这种网络I/O模式中没有使用任何异步操作，所有I/O相关的Socket操作，如accept、send、recv等，均将拥塞至操作成功或出错方返回。STM采用为每一个客户连接Spawn均一个会话线程(Session Thread)的方式来实现服务器的可扩展性。

1.2 简要分析——“一窝蜂拉客的向导们” 与 “旅行社”
STM又可以分为A、B两种基本类型。在方式A中，服务器端同时启动n个会话线程，这些会话线程既要负责客户端的连接接入(accept)，又要负责完成每个客户会话处理的全过程(send/processing/recv)；各线程均拥塞在accept调用中实现接入同步。打个比方，见过某乡下旅游景点入口处一窝蜂拉客的向导们么？假定游客是一个一个进入景点的，而每个向导（会话线程）都要自己拉客（accept），同时也只能从始至终为一个游客（客户端）服务(交互及信息处理)。这种“一窝蜂抢生意”的向导式服务方式本质上和最基本的STM是一致的。

在方式A中，其会话线程甚至连“接入”和“交互”的功能性职责都未加区分，尽管这非常有利于粗放型多线程实现，但无疑是低效的。因此，我们可采用另外一种方式B来实现STM，即“旅行社”模式（或“大厅－服务员”模式），由专人负责接待客人，并且为每一位客人专门指派一名导游。亦即，由服务器端开辟一个accept专用线程，每接入一个会话便为其Spawn一个新线程，会话线程只管交互，不管接入，单个会话结束之后直接退出。

同步线程模式最大的优点在于单一会话处理逻辑非常集中，容易实现，便于调试；较之方式A，方式B的好处在于其启动及运行时会话线程数相对较少，接入及处理的逻辑结构划分清晰；而A与B所共有的弊端则在于：首先，可扩展性很差，线程数目随会话连接数同步增加，CPU上下文切换的开销将逐渐变得不可忽略，进而成为服务器端沉重的负担；其次，平台兼容性不佳，在某些不支持线程的平台上难以得到应用和移植。

针对上述缺陷，比较流行的改进方法莫过于线程池(Thread Pooling)了，通过人为设置并发会话数量上限、重复利用已创建线程的方式来抑制上下文切换所导致的性能损耗，同时节省新线程的创建开销。但这只是一种被动的解决方案而已，它只能部分缓解拥塞模式所面临的扩展性问题，而并不能根治这一困难。