一个灵活的可复用网络库

写一个服务器并不算太难，但是写一个可复用性极强的网络库还是有一些难度的。

 

首先，我先总结一下在工作中遇到的需求。

 

在一个大型的服务器中，IO必然应该是多线程的，但是连接并不应该是在这些IO线程中平均分配的，因为连接的特性不同，某种连接就需要单独的占用一个IO线程，而某些连接则又应该共享同一个IO线程。例如：与数据库前端服务器相连的连接，一般情况下，这种连接的数据量比起单个与客户端连接的数据量的数个数量级倍，如果将其也和很多客户端连接放在同一个线程，那么连接的速度可想而知，不是与数据库的连接读写速度被客户端的所拖累，就是客户端连接得到服务的机会变少，这样都是不好的。

 

连接的寻址问题，每个连接在逻辑层，都应该有一个独一无二的连接ID与其对应，并且我认为用过的连接ID永远不应该重复使用，至少应该再很长一段时间内都不能重复使用。这样可以在逻辑上避免很多让人困惑的问题。由于连接都是分布在不同的线程之中，因此我认为连接的ID可以通过（线程ID，连接ID）这个元组进行寻址，因此，每个线程中ID都可以从1开始一直到unsigned long long的最大值，这个大小，如果每毫秒建立一个连接的话，也可以使用584942417年，所以完全不用考虑重复的问题。在逻辑中，都是将连接的功能ID和连接的寻址ID绑定

 

效率的问题，影响服务器效率的因素很多，但单从网络库这里来说的话，那么就只有两点，一个是IO速度，一个是与逻辑线程之间交互的效率。这些问题目前已经得到了还能接受的程度。

 

还有就是为上层提供什么样的接口，这点我想详细说一下我的观点：

开始的时候，我一直觉得，IO层应该尽可能的分担一些逻辑层的事情，比如断包，做一些连接对象的绑定控制，握手控制等。后来我发现，这样事实上大大的降低了底层的可扩展性，由于协议的载体不同，每次新增一个不同类型的连接，就要又扩展一个底层的实现类型。。。感觉好累。。。所以这次，我要把他们都放到逻辑层去。。。

 

还有，就是，需要做到所有参数，逻辑层都要是可控制的，包括开辟新的IO线程，设置连接的发送接收限速等等这些，都要逻辑层可控，IO线程只要做到能快速的接收数据和把数据发出去就行了

 

先写吧，争取下星期之前写完