带交互界面的tcp服务端，要比linux/命令行的服务端要复杂多了

这几天用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=11466600
08-18 08:50:44.500_PackageCount=11466700
08-18 08:50:44.859_PackageCount=11466800
08-18 08:50:45.203_PackageCount=11466900
08-18 08:50:45.578_PackageCount=11467000
08-18 08:50:45.906_PackageCount=11467100
08-18 08:50:46.265_PackageCount=11467200
08-18 08:50:46.609_PackageCount=11467300
08-18 08:50:46.968_PackageCount=11467400
08-18 08:50:47.328_PackageCount=11467500
08-18 08:50:47.671_PackageCount=11467600
08-18 08:50:48.031_PackageCount=11467700
08-18 08:50:48.375_PackageCount=11467800
08-18 08:50:48.703_PackageCount=11467900
08-18 08:50:49.078_PackageCount=11468000
08-18 08:50:49.437_PackageCount=11468100
08-18 08:50:49.765_PackageCount=11468200
08-18 08:50:50.109_PackageCount=11468300
08-18 08:50:50.468_PackageCount=11468400
08-18 08:50:50.828_PackageCount=11468500
08-18 08:50:51.187_PackageCount=11468600
08-18 08:50:51.546_PackageCount=11468700
08-18 08:51:15.843_PackageCount=11475700

——不过，最后清理已经断线的客户端的msg列表时（50多个，短线的客户端数量少没事），还是报了一次错。。。。。。