methods of handling multiple connections as lwip

这里分享一些一个服务handle多client连接的经验。 (1) 多线程/进程方法 每accept并创建一个新连接之后，就create一个task来处理这个连接的事务。linux使用fork()来创建分支线程。freertos 不支持fork方法，只能创建新的线程来管理连接。此方法内存开销较大。 (2) non-blocking socket 和 select 此方法由单线程处理并发事务，即最原始的轮询方式。在系统不支持fork()的情况下经常用到。首先，accpet/recv函数都必须的non-blocking的，需立即返回，否则其它任务就得不到轮询。这种模式在跑单片机裸机程序时经常是这样的，另外在labview里面也经常是这样的轮询的方式。这个例程可以在lwip 1.4.1 contrib下app demo:chargen 里可以学习到。这种方式会占用很多cpu资源，这样的任务优先级要放低，并设置一定的轮询间隔(类比在labview里，while循环通常会插入一个等待时间)。否则 freertos 中低优先级任务就得不到运行，同优先级的任务也只能分时间片轮流运行。 这里简单总结下 select方法。 协议栈内核在每次有accept 或 recv事件到达后都会调用 event_callback(); 增加一个事件记录。在上层接收后都会减掉一个记录。select 函数通过查询socket的对应event来置位fd_set对应的比特位。本质就类似查询一个计数信号量。 (3) 使用 raw api， 基于事件触发(基于回调)方式。 此方式适合编写只进行简单处理的应用，每次接收到包就会调用相应的回调函数。多连接是由协议栈的active_pcb_lists直接管理，每个连接都创建属于自己的state argument。如果需要运算量比较大占用时间较长的服务则不适合此方式，会影响的协议栈对其它服务的响应速度。 后记，从事务的角度来看，一个tcp连接代表一个session，一句udp 请求也代表一个session。一个session从接收到返回就是一条事务线。若不能一气呵成，则就必须用一条线程去管理它，或者说维护一个工作现场，等待它的后台任务完成再回来应答这个事务。一条线程就对应一个事务现场，多任务操作系统就是在不同的工作现场的中交替工作，模拟多个人工作的情况，每一个工作现场都保存的对应工作事务的进展情况和所有需要用到的工具。 或者还有一种做法，就是一件事做完一部分后丢给后台，让它处理完之后调用我给它的办法帮我把剩下的事处理完，节省了任务之间信息传递和任务切换带来的开销。 其实一个session对应一个任务确实有点浪费，我想一般handle几百上千万个连接的服务应该不会这样做的，每个连接只需将它当前的状态变量连同数据包传给每个部门来做就可以了，毕竟每个连接的状态的数据量不是很多，没必要开辟一个专门的任务去Handle.