tcp网络编程框架设计请教
要编一个多点客户端对一个服务端，本人大白，谢谢详解。
1，是不是需要登录账号验证的软件，都要一直tcp长连接的，并心跳检测的连接是否断开的？否则每次建立tcp连接都要重新验证账号密码？
2，软件收费计费，需严谨的通讯方式，怎么防止别人抓数据包发送到服务端进行欺骗？软件的通讯系统又是怎么保证发送者的身份不会混肴？
3，
客户端登录，不定时会需要发送字符串到服务端，每次提交数据前，写入到客户端“已提交数据”列表中，等待服务端返回结果，待返回结果后写入到数据库记录；
服务端接收到数据，写入字符串到“临时列表”中等待处理，服务器多线程去处理列表中的数据，服务端要需要5-10秒时间处理每条字符串，再返回给客户端是否处理成功；
客户端数量如果很多，整个通讯流程怎么设定保证效率和稳定？（多线程同步？异步？长连接？短链接？）
两边都写入临时列表是怕突然出了意外，也知道提交了没有，处理了没有，到了哪个步骤，因为每次处理都是收费扣点的，另外服务器也有了数据缓存，等处理后在返回结果，
------解决方案--------------------
1.是否用户登陆，这个取决于你的需求，多少情况会的，这样可以控制每个客户的权限功能等，长连接和短链接，要看你获取数据的方式，如果是频繁连续的数据，交互比较多，要长连接，对于长连接，要心跳判断是否状态正常
2.绝对防止抓包，基本不可能，只能加密数据，制造点困难
3.对于每个动作，最好是有协议约定，否则不知道对方的状态，容易造成混乱
------解决方案--------------------

引用:

1，是不是需要登录账号验证的软件，都要一直tcp长连接的，并心跳检测的连接是否断开的？否则每次建立tcp连接都要重新验证账号密码？

客户端软件设计不会与协议设计纠结在一起。如果重登录就重登录，如果不重登录就不用重新登录，反正也不会要求用户重新数据（因为都记录在内存中）。

引用:

2，软件收费计费，需严谨的通讯方式，怎么防止别人抓数据包发送到服务端进行欺骗？软件的通讯系统又是怎么保证发送者的身份不会混肴？

前半部分，你可以进行加密。你可以先使用RSA加密进行（例如）AES密码协商，然后通过AES通讯。并且每隔30分钟重新协商一次。但是实际上，基本上所有的软件，都是先不去加密，先运行1年以后，等你有几百个或者几千个每周活跃的用户以后，再考虑。你做这种设计肯定要有分寸地一步一步“跳跃”，不要一下子把自己“摔坏了”。

后半部分，这就是任何通讯协议必定包括的部分。任何消息都要知道这个消息属于哪一个授权凭据（服务器为会话分配的会话编号，例如可以采取一个guid形式的会话编号）。

引用:

3，
客户端登录，不定时会需要发送字符串到服务端，每次提交数据前，写入到客户端“已提交数据”列表中，等待服务端返回结果，待返回结果后写入到数据库记录；
服务端接收到数据，写入字符串到“临时列表”中等待处理，服务器多线程去处理列表中的数据，服务端要需要5-10秒时间处理每条字符串，再返回给客户端是否处理成功；

服务器通常用几个毫秒或者是十几个毫秒就返回数据了，而且各个消息的处理都是高度异步并发的，用不着排什么队。如果需要刻意去排队，那么其实此时就应该禁止新的客户端接入（重定向到别的服务器上去）。

引用:

客户端数量如果很多，整个通讯流程怎么设定保证效率和稳定？（多线程同步？异步？长连接？短链接？）
两边都写入临时列表是怕突然出了意外，也知道提交了没有，处理了没有，到了哪个步骤，因为每次处理都是收费扣点的，另外服务器也有了数据缓存，等处理后在返回结果，

这里你堆了一些名词儿概念，我觉得没有多大意义。你既然选择长连接，那么就长连接。多线程时除非不得已否则还刻意搞什么“同步”？所谓临时列表，不过是内存中的一个对象数组（或者是对象集合），你担心什么意外？收费是基于日志另外去统计的（甚至可以每个月地让你的老婆用她自己的电脑、用Excel做几小时统计表），跟系统本身的设计基本上没有什么关系，就好像做整容手术的医师都知道要在术前后都拍照，这个牌照并不会影响医师的手术技术水平。而你把服务器相像成了一个装了一大堆各种乱七八糟相互干扰的软件的pc机，而不是专机专用的服务器。
------解决方案--------------------
1，
完全可以使用session机制跟踪会话状态，而没有必要保持长连接。
2，
很简单，使用证书对数据加密。这样监听到的数据都是密文而已
3，
你应该在应用层保证这种可靠性。你完全没有概念，一直纠结在通讯层上。