TCP服务（保活、定时批量发出命令、接收前端数据请求）

TCP服务（保活、定时批量下发命令、接收前端数据请求）
对TCP/IP编程非常生疏，现在要做一个TCP服务端与前端的采集设备（作为客户端）通信，一方面要定时的确认客户端发送来的心跳检测帧，一方面要定时的向前端设备批量下发数据请求命令，还要不定时的接收WEB的请求并向前端采集设备转发WEB请求命令，并向WEB端返回结果。服务端大致有上述三类任务需要处理，目前服务及其不稳定，结果有时能获取有时不能。主要难点在三类任务的逻辑处理上，而且对于socket的控制不清晰，导致几个线程接收同一个soceket的recv运行比较混乱，求好的建议方案。大致的设计思路等等等等
------解决方案--------------------

引用:

对TCP/IP编程非常生疏，现在要做一个TCP服务端与前端的采集设备（作为客户端）通信，一方面要定时的确认客户端发送来的心跳检测帧，一方面要定时的向前端设备批量下发数据请求命令，还要不定时的接收WEB的请求并向前端采集设备转发WEB请求命令，并向WEB端返回结果。服务端大致有上述三类任务需要处理，目前服务及其不稳定，结果有时能获取有时不能。主要难点在三类任务的逻辑处理上，而且对于socket的控制不清晰，导致几个线程接收同一个soceket的recv运行比较混乱，求好的建议方案。大致的设计思路等等等等

对于除web服务器这样的高并发server，通常采用单线程模型，即网络操作只用一个线程来完成（至于你用什么完成端口、重叠io这种不是重点），总之，业务和网络分开，至多两个线程。

记住，所有的不稳定和处理的复杂源于多线程。不是我们禁止多线程，而是在你对线程的交互框架理解很浅的时候，你写不出稳定的多线程程序，当你理解的很透彻了，会发现，多线程的意义根本不在于那些置顶贴里讨论的那样。

如果要深入学习，推荐阅读google chrome的源码。linux的话，libevent的框架是个不错的参考。
------解决方案--------------------
1.感觉是几个线程间的互斥没处理好
2.如果做得简单点，就不能把这三个功能分开用不同的socket来处理？