客户端软件设计不会与协议设计纠结在一起。如果重登录就重登录，如果不重登录就不用重新登录，反正也不会要求用户重新数据（因为都记录在内存中）。
前半部分，你可以进行加密。你可以先使用RSA加密进行（例如）AES密码协商，然后通过AES通讯。并且每隔30分钟重新协商一次。但是实际上，基本上所有的软件，都是先不去加密，先运行1年以后，等你有几百个或者几千个每周活跃的用户以后，再考虑。你做这种设计肯定要有分寸地一步一步“跳跃”，不要一下子把自己“摔坏了”。后半部分，这就是任何通讯协议必定包括的部分。任何消息都要知道这个消息属于哪一个授权凭据（服务器为会话分配的会话编号，例如可以采取一个guid形式的会话编号）。服务器通常用几个毫秒或者是十几个毫秒就返回数据了，而且各个消息的处理都是高度异步并发的，用不着排什么队。如果需要刻意去排队，那么其实此时就应该禁止新的客户端接入（重定向到别的服务器上去）。
这里你堆了一些名词儿概念，我觉得没有多大意义。你既然选择长连接，那么就长连接。多线程时除非不得已否则还刻意搞什么“同步”？所谓临时列表，不过是内存中的一个对象数组（或者是对象集合），你担心什么意外？收费是基于日志另外去统计的（甚至可以每个月地让你的老婆用她自己的电脑、用Excel做几小时统计表），跟系统本身的设计基本上没有什么关系，就好像做整容手术的医师都知道要在术前后都拍照，这个牌照并不会影响医师的手术技术水平。而你把服务器相像成了一个装了一大堆各种乱七八糟相互干扰的软件的pc机，而不是专机专用的服务器。
前半部分，你可以进行加密。你可以先使用RSA加密进行（例如）AES密码协商，然后通过AES通讯。并且每隔30分钟重新协商一次。但是实际上，基本上所有的软件，都是先不去加密，先运行1年以后，等你有几百个或者几千个每周活跃的用户以后，再考虑。你做这种设计肯定要有分寸地一步一步“跳跃”，不要一下子把自己“摔坏了”。后半部分，这就是任何通讯协议必定包括的部分。任何消息都要知道这个消息属于哪一个授权凭据（服务器为会话分配的会话编号，例如可以采取一个guid形式的会话编号）。服务器通常用几个毫秒或者是十几个毫秒就返回数据了，而且各个消息的处理都是高度异步并发的，用不着排什么队。如果需要刻意去排队，那么其实此时就应该禁止新的客户端接入（重定向到别的服务器上去）。
这里你堆了一些名词儿概念，我觉得没有多大意义。你既然选择长连接，那么就长连接。多线程时除非不得已否则还刻意搞什么“同步”？所谓临时列表，不过是内存中的一个对象数组（或者是对象集合），你担心什么意外？收费是基于日志另外去统计的（甚至可以每个月地让你的老婆用她自己的电脑、用Excel做几小时统计表），跟系统本身的设计基本上没有什么关系，就好像做整容手术的医师都知道要在术前后都拍照，这个牌照并不会影响医师的手术技术水平。而你把服务器相像成了一个装了一大堆各种乱七八糟相互干扰的软件的pc机，而不是专机专用的服务器。
完全可以使用session机制跟踪会话状态，而没有必要保持长连接。
2，
很简单，使用证书对数据加密。这样监听到的数据都是密文而已
3，
你应该在应用层保证这种可靠性。你完全没有概念，一直纠结在通讯层上。
补充下：
2，现在想法是，密码MD5发送，通过的话就生成当次临时加密密匙并发送给客户端通知进行加密（每次通过登录验证都重新生成一次）
3，因为是支付类，即时扣钱，主要是怕软件不稳定，中途卡死，就不知道客户端已提交了多少，未处理的有多少，要有记录，重启要自动继续处理。
因为没技术，不知道怎么更效率和稳定，一堆理论更乱，真心希望有人指点明路，少走弯路