被两个变态问题整的焦头烂额

文件传输

    程序运行的流程为：其他进程将创建文件传输任务的信息写入文件，FTP程序读取文件，解析，然后创建任务，开启线程完成FTP工作。我老人家每次测试的时候，同时发送个三五个文件，并行跑十来个任务，跑几个钟头，要是没出问题，OK，心满意足，工作圆满结束。把FTP交付给老板后，今天跟我有个bug，说同时发送几百个文件的时候，程序就会出现内存错误。听到后马上心里感觉有些不踏实，因为没有测试过。太TM极端了，谁会同时传几百个文件嘛！

    自己测试了一下，果然有问题，而且问题很严重。严重的原因在于，无法预测发生错误的条件。随机发生的。测试了一个上午，感觉有点点小规律：

1. 连接服务器失败次数过多时，才会发生错误；连接失败次数非常多时，肯定会发生错误；倘若没有发生连接失败问题，几乎不会发生错误（俺没捕获到）；

2. 连接失败次数在200次左右时，是发生错误的高峰期；但也在此之外的，在100以内也发生过，还有几次测试到1500次以上时才发生错误

3. 排除原因：界面资源冲突；文件资源冲突；

肯定与连接失败相关。

猜测可能的原因：

1.数量问题：线程数量，或者建立socket数量过多，导致系统资源不够(连接失败，资源没释放？)
2.资源冲突：线程数量很多时，才会发生这种冲突（？）

太TM抽象了，这问题

可能，很可能，就是某个小细节，没注意到

 

数据通讯

把xmlrpc++库改的是乱七八糟了。

现在，期望让它完成如下功能：

1.对外开放扩展接口：感知客户连接开启/断开，可以捕获网络的原始HTTP数据包，可以捕获处理后的数据，也可以发送自己构造的HTTP数据包；

2.两端同时支持RPC；

3.既可以双端监听，也可以单端监听（服务器端监听或者客户端监听）；可以自由设定；

4.信息异步发送

5.服务器端底层实现消息群发

昨天把消息群发的解决了，想，今天做一下针对指定客户发送数据。本以为是个超简单的东西，加个查找功能，然后针对指定缓冲区发个数据，就OK了。结果，遇到一个变态的问题，就是，当对指定客户发送数据后，整个程序居然悄无声息的死了！靠!不报错，啥问题都没有，整个程序窗口就消失了!shit!群发都可以，发单个就不行了？！靠！还真有点离谱！

一层一层发掘下去，发现在数据写入用户缓冲区之后，写入socket缓冲区之前挂掉的，也就是说，很有可能在监听文件描述符读写的时候出错了，导致整个程序退出，也就是select过程中出了问题。但是，具体啥问题，也还不确定，后天再去看看。TNND，老子还不相信搞不定你!