indy多连接文件传输问题!先简单说明一下要实现的功能，和已经完成的功能：
建立一个TCP的长连接，实现发送字符消息,流,文件三大功能，我是将这三种功能定义了三个类，使用delphi的持久化机制直接或者是间接将类保存后进行传输，.我使用的是delphi的TServerSocket和TClientSocket基本功能都已经完成，但是后来发现传输文件时，特别是文件稍大，服务器(Server)端的CPU特别高.做为一个服务器(Server)这样很危险. 后来打处传输文件 ，使用indy来完成.
大概的处理流程：
1. TServerSocket和TClientSocket已经建立起长连接.同时打开了服务器(Server)端TIdTCPServer. （这里服务器(Server)上会打开两个不相同的TCP端口(Port)）
2. TServerSocket发送消息到客户端，准备发送文件.
3. TClientSocket接收到服务器(Server)的通知，使用TIdTCPClient连接服务器(Server)TIdTCPServer.
4. TIdTCPServer接收到到连接，发送文件给客户端. 发送完成后断开TIdTCPServer与TIdTCPClient之间的连接.
通过上面的流程可以完成文件的发送，效果（Effect）还行.
可问题又来了：服务器(Server)TServerSocket会建立上千个连接（服务器(Server)在公网上）， 会同时向所有客户端发送文件（发送的文件都不大）， 这样TIdTCPServer是不是因为就会建立上千个线程？这样做会不怎么会有问题.请大家帮忙.又到项目中后期了，公司老板催的尽，我不想程序(Procedures)(Procedures)功能到有了，到用起时出问题就惨了！--
最开始应该测试您的长连接是否能够达到标准，如果您的客户端很多很多您需要提高您的服务器(Server)的性能来满足这样并发连接的需求---
使用TServerSocket传输文件需要占用大量的资源，换过来使用TIdTCPServer也不怎么会好到哪里去，相反，还可能会增加服务器(Server)的压力，原来可以简单地直接或者是间接进行的文件传输，更加复杂化，更互次数越多，那对于服务器(Server)资源的消耗也就越大，从短时间内来看是可以缓和某一时刻的压力，但是就服务器(Server)而不能是言，长时间运行（以前的文件传输虽然滞后了，但后面还有文件传输需求，如此更加让服务器(Server)难以承受.个人建议，对于这种单纯的文件传输，可以考虑使用Winsock2的TransmitFile来完成，可以大大降低服务器(Server)的消耗.---
谢谢两位朋友的回复.
hongqi162 朋友，您说的“测试您的长连接是否能够达到标准” 这一个已经做过了，是直接或者是间接使用的几台电脑做客户端，连接向公网服务器(Server)，每台电脑创建几百个socket连接,相当于，在同一程序(Procedures)(Procedures)中 ，创建几百个TClientSocket. 两边互发消息，是没问题的.
－－－－－－－－－－－－－－－－－－－
unsigned 朋友，您说的占用大量资源的基本问题，目前看还能接受，传文件也不是时时刻刻都在传， 可能大多数只是空连接在那里什么事情都没做，使用indy,TIdTCPServery主要是解决在传文件那一时间段，CPU不怎么会太高. 而不能是一个服务器(Server)端也只会生成一个TIdTCPServery. 还有您说的 “使用Winsock2的TransmitFile来完成，可以大大降低服务器(Server)的消耗.” 能具体点吗？
---
我是{$WebSiteName}的站长
再说明一下，鄙人写了两个类分别继承的TServerSocket和TClientSocket， 本来是用于局域网的. 后来才用于公网---
要想更多的了解TransmitFile可以到MSDN：http://msdn.microsoft.com/en-us/library/ms740565(VS.85).aspx去了解.不过这里只是提供一个思路，使用他还需要对Winsock2有相当的了解.另外一个可以考虑的就是使用完成端口(Port)（I/O Completion Port，简单称IOCP)，这一个估计也是当前在Windows平台下炒得最火的IO模型.---
当然对于Indy10，就有一套SupperCore，他就支持IOCP，不过是基于早些时期的版本，后续版本基本上不兼容，所以目前虽然Indy10的套件包当中有存在着，却根本没有办法进行使用.---
如果要考虑效率和性能的话，{$WebSiteName}的站长最好使用IOCP，这是最好的解决方案.如果使用Indy的话，您可以限制客户机联接数量，这亲可以很好的保拷服务器(Server)的开销，但是这样的话会产生很多很多的负面问题.---
我们现在的程序(Procedures)(Procedures)通信绝大部分的都是基于， TServerSocket和TClientSocket 继承下来的完成的，如果要重新更改通信模式的话会不怎么会对已经完成的程序(Procedures)(Procedures)有很大的改动.我对IOCP只知道一点点原理，从来没有做过.
xiaochensu 您说的限制客户机联接数量是什么方式？ 具体怎么做呢---
使用IOCP是一个比较好的选择(Choose)，特别像这种文件传输需要占用大量资源的情况，可以有很大的改善---
如果您原来的程序(Procedures)(Procedures)不是采用阻塞模式的话，转成IOCP是相当简单的.---
新手路过It快活林,进来看看学习---
unsigned 您说的相当简单，让我心动不已！
我确实是用的异步方式. 但没有使用任何线程，所以传输文件时对CPU占用比较大.
我想的是在客户端发起连接时在TServerSocket的Onconnect事件中，对Sokcet句柄绑定到完成端口(Port)上，不知道是否正确.
对于完成端口(Port)，我只知道还要有工作(Work)线程来完成具体的事， 还要有线程池！ 我了解的就这么多.
非常希望得到您进一步的帮助！ ---
使用完成端口(Port)，您不需要使用TServerSocket，并且最好是直接或者是间接使用API，不然的话会碰到其他麻烦.
1.listen Socket，使用Winsock2的WSASocket并支持Overlapped（最后一个参数指定)
2.可以使用传统的accept，也可以使用WSAAccept，来接受连接，这一个跟原来的不变，只需要有一个或者是多个线程在执行accept就可以了.
3.accept成功之后，再与完成端口(Port)关联.所有操作都使用支持Overlapped的函数，譬如WSARecv/WSASend，并且在调用时，带上相关的并且有效的Overlapped结构
4.accept成功，并与完成端口(Port)关联后的connection socket，如果是需要等待客户端发起的请求，就马上发起一个WSARecv
5.完成端口(Port)当中的GetQueuedCompletionStatus处理线程在收到数据(Data)之后（WSARecv返回）先判断是否完整的
协议报文，如果还没有完整，就将收到的数据(Data)进行缓存（譬如使用链表)，并继续发起WSARecv;如果已经接收完成，就可以去处理，处理完之后，再调用WSASend进行发送，然后又回去GetQueuedCompletionStatus等待新的任务.---
您把多个线程去招待GetQueuedCompletionStatus并做后续的处理，那么就是一个很好的线程池.---
我以前的程序(Procedures)(Procedures)绝大部分的都是基于ServerSocket的，要改成您说的iocp太难了.
我现在继承ServerSocket，类部创建一个TidTCPServer传文件 都可以啦，
但我们这一个功能不只传文件 ，还要能传文件夹，太烦了...， 给一个连接传文件夹都好弄，现在是有可能给多个客户端传文件 夹，而不能是且可能传的文件夹还不一样
---
呵呵，事在人为，相信您能做好.---
既然使用了TIdTCPServer与TIdTCPClient, 干吗还要用TServerSocket和TClientSocket?
只用 TIdTCPServer , 服务器(Server)只需开一个端口(Port),
客户端也只使用 TIdTCPClient, 所以我们可以得出结论连接也只有一个, 省去了很多很多麻烦.
这就需要
协议,也就是服务器(Server)发送什么字串时, 客户端就应当如何回应.
由于TIdTCPServer 对每一个连接均采用一个独立的线程, 所以区分"发送什么,发给谁"就很简单了.
但是,服务器(Server)设计通常不能是主动的,而不能是是被动的. 客户端才应当是主动的, 就是我现在的进展, 下一步该向服务器(Server)要求提取什么(如:列出文件列表,下载什么文件).
还有一点, 服务器(Server)的连接即使很多很多,但网络带宽总是有限的(如1G网卡),所以我们可以得出结论,虽然传送的文件很多很多,但CPU不怎么会高(我的经验),这就是 TIdTCPServer 的优点.
