Open DDS的那些坑

对使用Open DDS过程发现的问题点或待优化项目，记录如下：

问题点：

1. Windows平台上，vs2005、vs2010编译的dll不能相互调用，出现异常崩溃的问题；Linux平台上，内核差距比较大时，glibc的版本不一致，也可能导致ACE+DDS需要重新编译；
2. debug版和release版的表现，不一致，不能互通用；
3. 某些调用方法，导致内存泄漏；
4. 编译过程中，Windows和Linux系统都可能需要人工干预，如编辑Makefile、拷贝某些不能自动产生的java文件等；
5. 特性支持比较复杂，如dds4ccm_opendds、xerces、QOS_xml；
6. 不同版本间的使用模式有区别，否则会失败或崩溃，如3.8和3.13间的差别；
7. 日志文件只有一个，不支持轮转和文件大小特性；部分日志，可读性不强，不能有效反应整个生命周期的关键线索；
8. 如在MFC、Qt中，不使用ACE_TMAIN时，需要单独调用某个逻辑方法；
9. 多domain的配置文件；
10. UDP的可靠性，不是那么可靠；
11. Windows上单播发现不成功；
12. Linux平台，TCP协议传输时，sub方停止重启不能重建连接；
13. TCP协议，7*24小时发送失败；
14. DW的write失败后，导致内存增长；
15. 组播传输时，多个订阅者有时接收不到数据的问题；

定制项：

1. Qos定制，如BatchDataQos；
2. 大包转小包、小包转大包的传输控制；
3. 云环境的发现和传输；

优化项：

1. Monitor监视内容的丰富和完善（原始monitor功能和RTI差的不是一点半点）；DW的report连轴调用；
2. TCP协议时，解除必须配置host文件的限制；
3. Linux平台下，使用epoll模型；
4. 优化domainparticipate超时后的清理策略——立即清理，而不是以schedule_timer、schedule_cancletimer方式10秒钟延迟清理；