这几天用delphi写了一个tcp的服务端，感觉比linux/命令行的服务端要复杂多了一个tcp服务程序的开发└选择tcp服务器控件 ├Ttcpserver └Tserversocket ├以前一个服务程序使用它，效果还行，就是偶尔会有socket突然会失效 ├blocking │└因为服务端工作比较简单：接收字符串，按ini取得操作信息，修改一个image或一些内存状态，然后返回字符串 │ └使用一个线程跟踪全程似乎有点大惊小怪 └non-blocking ├以前一个服务程序就是使用非阻塞的 ├但是这一次，在OnRead里先取4个字节的长度信息，再取此长度的数据；然后返回原字符串 │└发现服务器卡的很厉害！ ├是不是不能在OnRead里进行Send操作的？ │└如果这样，需要修改机制：OnRead里只读取，放到一个任务队列；另外的线程或定时事件取任务处理再Send操作 ├还有一个问题，OnRead里又取又处理又发回。如果期间该客户端断了 │└使用该socket前需要每次都判断一下是否还有效；如何判断 │ └if socket.connected then还可以发送 └还有一个问题，经常出现一个客户端被响应时，就连续响应它；10多秒钟内不会响应别的客户端
每个FrameApp对客户端命令的响应可能需要一个时间，为了期间不影响接收、响应其它客户端的命令 采用了一个命令队列，接收时统一加到此队列（添加） 由定时事件扫描此队列进行处理、返回、删除
比较简单的工作，由于有连接列表，某个客户端断线后，需要及时在列表里反映 事情变得复杂了：除了在列表里反映，还需要删除任务队列里属于此客户端的任务（删除）
这与定时器事件扫描有冲突了！
采用Tthreadlist仍然会冲突！？ 定时器事件 和 断线事件 都是 Tthreadlist.locklist 才处理的。。。。。。。
连接列表CheckListBox.items TabSheet FrameApp Thread socket Tasklist(使用了线程，就不用了) 任何一个要能方便找到对应的其它
后来不得不彻底放弃控件，改用api
然后还有一个主界面(MainForm以及各个FrameClient)和各个线程的交互问题
感觉这种带交互界面的服务端，要比linux/命令行的服务端要复杂多了
tcp服务端放弃子线程直接操作界面，而是改为子线程把收集到的数据包放到自己的toFrame结构，然后等待对应的toClt结构被填充，由主界面定时轮询取走toFrame的数据，处理完放到对应的toClt。
这样就很和谐了——昨晚在linux下开50个背景进程（./tcpclt wait=0 > /dev/null &），效果非常好：win的网络流量稳定在0.95%（100M的网卡）：
时间---------------来往包数（每包约100多字符）08-18 08:50:44.140_PackageCount=1146660008-18 08:50:44.500_PackageCount=1146670008-18 08:50:44.859_PackageCount=1146680008-18 08:50:45.203_PackageCount=1146690008-18 08:50:45.578_PackageCount=1146700008-18 08:50:45.906_PackageCount=1146710008-18 08:50:46.265_PackageCount=1146720008-18 08:50:46.609_PackageCount=1146730008-18 08:50:46.968_PackageCount=1146740008-18 08:50:47.328_PackageCount=1146750008-18 08:50:47.671_PackageCount=1146760008-18 08:50:48.031_PackageCount=1146770008-18 08:50:48.375_PackageCount=1146780008-18 08:50:48.703_PackageCount=1146790008-18 08:50:49.078_PackageCount=1146800008-18 08:50:49.437_PackageCount=1146810008-18 08:50:49.765_PackageCount=1146820008-18 08:50:50.109_PackageCount=1146830008-18 08:50:50.468_PackageCount=1146840008-18 08:50:50.828_PackageCount=1146850008-18 08:50:51.187_PackageCount=1146860008-18 08:50:51.546_PackageCount=1146870008-18 08:51:15.843_PackageCount=11475700
——不过，最后清理已经断线的客户端的msg列表时（50多个，短线的客户端数量少没事），还是报了一次错。。。。。。
