我们通常用Poll和线程池来处理具有大量客户端的服务请求，比如一个客户发送一个命令给服务端，服务端根据命令字执行相应的动作，执行完后返回给客户端。
问题一：处理模式的问题
    对于命令字不多的情况，服务端一般采用switch/case来处理每个动作。但是，如果有很多很多的命令字（几十或者上百个）通常如何处理？有没有什么比较通用或者权威的解决办法？
问题二：命令流问题
    就是服务器-客户端交互完成一系列动作，只有上一个动作成功执行，那么才继续往下走。如果是面向过程的编程，那么处理起来会方便一些，可以通过发送/返回，一步步得到确认后继续往下执行。但是如果用Poll、select等通过线程池实现，那么每次交互都会通过poll或者select函数分配线程，一系列动作如何协同？如何确认上一次成功才继续下一个动作？

    请各位不吝赐教！

对于问题2，我们的做法是：为每个新连接分配一个struct，作为记录这个连接的执行状态的状态机，放到以其fd为key的hash表里面；每次有新数据到来时候，根据fd取出对应状态机，并且跳转至相应的处理函数。
我们基本没有用到多线程。

如果一个线程能够自始至终的处理一个完整交互，倒是简单一些

如果由多个线程来处理每个事件，那是相当麻烦啊
比如说客户端发送10个字节，这10个字节可能不是一次到达服务端，也许先是2字节，再3字节，再5字节

那这样就先后有3个线程为这10个字节服务，还需要组装成一个完整报文，然后调用交易处理函数..

第二个问题里面:
客户端和服务端的处理思维是不同的，服务端需要对每个客户端保存现场，然后不管是开线程并行也好，还是分时轮询处理也好，都是按照状态来决定下一步处理的
客户端则不同，上一个状态未完成之前，要吗等，要吗超时，需要保持原子操作

第一个问题:
使用数组或者hash表都一样的，关键是把这个命令字执行的命令初始化链接到结构体中，这样一旦查找到命令字就可以直接执行了，免了再去找命令的时间