阻塞套接字的缺点显而易见，这里就不多说了。对于服务器端，有人提到使用多线程来处理每个连接的套接字。
这种方式有两种缺陷：
1.扩展性极差
2.有大量连接时，线程太多，资源消耗过大第二点很好理解，但是对于第一点，我不太理解扩展性差的原因，查了一些老帖，提到，在有多个套接字的场合扩展性就差了，小弟实在没有理解到内涵，还请各位朋友能讲下，这种所谓的扩展性差体现在什么地方了。这种问题可能很无趣，因为现在基本没人这样用了，只是小弟最近看书有点钻牛角尖了，就是想不明白，谢谢了
这种方式有两种缺陷：
1.扩展性极差
2.有大量连接时，线程太多，资源消耗过大第二点很好理解，但是对于第一点，我不太理解扩展性差的原因，查了一些老帖，提到，在有多个套接字的场合扩展性就差了，小弟实在没有理解到内涵，还请各位朋友能讲下，这种所谓的扩展性差体现在什么地方了。这种问题可能很无趣，因为现在基本没人这样用了，只是小弟最近看书有点钻牛角尖了，就是想不明白，谢谢了
1. 服务器每接受一个连接, 则开启一个线程对这个SOCKET进行阻塞接收
2. 客户端发送数据完成后, 等待回复.
3. 线程发现接收到的数据已经完整时, 加入到待处理业务链表, 让外部业务处理查询并处理数据, 线程在此退出, 把SOCKET归还.
4. 外部业务处理线程在处理时, 根据数据块所属的客户端, 用其SOCKET来回复处理结果.
采用上述的方式, 依旧可以实现功能和业务的分离. 没有任何不妥当的地方的, 只要实现功能和业务的分离, 软件就自然会有扩展性. 混在一起才没有扩展性.