如何解决DataSnap支持的Tcp长连接数受限的问题？

方案一：

    采用代理服务器方式，基本流程为：

    1、客户先连接代理服务器；2、获取可用的服务器IP和端口；3、关闭与代理服务器之间的连接；4、建立与可用服务器之间的连接。而且在第2步中可以实现负载均衡的配置与实现。博主最近对一个机房管理系统升级采用的就是此方案，学校（某一高新）公共机房现有机房50间左右，每间机房60台机器（标准配置），现有客户端3000台左右，以后肯定还要扩容更新的，故以5000个客户端为正常容量。因为要实时检测学生的的状态，如是否是在上课期间（机房号、时间、节次、周次、节假日等）、自费时间（实现计算帐户余额等）、接收和处理管理机的消息、接受管理机的监控等，故只能采用长连接的方式。

方案二：

    采用多进程方式：

    对于实时采集数据的项目，应用场景比如是这样的：5000客户端，每个客户端每隔500MS要给服务器上传一次数据。大家知道，像INDY这种阻塞型的通信控件，所能支持的TCP长连接的一般地不能超过1000的数量（如果想要维持稳定运行的话）。原因是大家都晓得的，阻塞方式会为每一个SOCKET连接创建一个新的线程为之服务，而WINDOWS单个进程理论上允许最多的线程数量是2048个，实际当中要少得多才行。有人说可以用WINDOWS的IOCP通信模型解决，诚然！但IOCP编程过于复杂。有人说，可以用INDY，使用短连接的方式解决。鉴于每隔500MS就要上传一次数据的频率，短连接其实不适合用，因为短连接每次都要建立和断开SOCKET连接，而建立和断开SOCKET连接是特别耗时的，所以使用TCP长连接的方式。

有人说为什么想着阻塞的方式，答案是：因为阻塞的编程是最简单的。其实对于5000长连接的客户端，INDY一样可以有办法实现。既然单个进程只能支持1000个左右的长连接，那开5个进程不是就可以支持5000个长连接了吗？有人说，阻塞的5000个连接就意味着WINDOWS要开5000个线程，如此多的线程，WINDOWS受得了吗？于是马上动手实验，一个进程开1500个线程，一共开了4个进程，每个线程每隔100ms,执行FOR I:=1 TO 100 DO，WINDOWS任务管理器显示，每一个进程占用40.4M的内存，CPU使用率才百分之零点几，总的CPU使用率才百分之几，内存使用率也只有20%，WINDOWS调度没有一点儿问题。这种方案只需要一个公网IP，分别为不同的进程绑定不同的端口。

    而且这也是咏南兄的中间件曾提出并使用过的方案。这一方案的优点就是结构简单，部署方便，如果客户端的数量和应用不是特别巨大的话，一台服务器机器就能搞定。当然其缺点是只能使用一台服务器（因为采用了消息机制），不可做多服务器集群和负载均衡，扩展受到了一定限制。