怎样实现断线重连和意外消息判断

[tianmao111]

1:一个服务端，一个客户端，服务端会保存一个已连接的客户端的session，当客户端意外断掉，并且再某个时间内重新连接后，可不可以让这个客户端重新连接并且仍然使用这个session，怎样连接呢？

2：每次客户端启动都要连接上服务端，才能进行下一步用户名密码输入验证，这样，服务端每次都要开辟一些对象和连接给这个客户端，就算这个客户端立即离开，服务端也不会立即销毁这些开销，这样的问题怎么解决？

3：还有，被加密和序列化的数据无法判断是不是业务需要的接口，只能先解密，反序列化才能再判断，但是，如果有大量无用数据，就会大量消耗cpu和线程来接收这些无用数据，怎样才能避免这些开销呢？

[shawn_yang]

BS架构吗?

[tianmao111]

cs架构，tcp协议

[gomoku]

1、理论上没有问题。客户要保持session id，重新连接协商时，把session id发给服务器以便重新分配session。 2、一般“会立即销毁”不是问题，只要他们最好都能得到销毁。（而且，这个目标和目标一冲突）。 3、一般只有验证过的客户才被允许发送数据，逻辑上验证客户发送的都应该是业务相关数据。如果有不同的业务，则应该用不同的端点来服务。

[tianmao111]

其实第2第3个问题都是想解决怎样解决大量无用连接请求的问题，就是怎样判断无用连接请求的 还有就是如果真的知道用户名和密码，并且用自定义的程序连上了，还发一些无用数据怎么办

[tianmao111]

2:我假设已经连上了，但是我就是不输入密码和账号，如果这样的用户特别多，是不是一直都得保存大量的链接？怎么办，即使是判断用户超时无动作踢掉，好像也不能解决问题，这个超时也不能太短了，太长了，用户一多也不行 3：知道用户名密码，也未必是属于我自己的正常客户端吧，你说的对，如果有大量这样的数据发过来，我都需要解码才能判断无用，这是不是会浪费我的资源呢，如果我故意这么做个测试呢，结果收来的全是无用的数据，那有用的就没时间去处理了吧

[tianmao111]

gc的速度能赶上创建会话的速度么，如果有人故意这么搞

[gomoku]

引用 7 楼 tianmao111 的回复:

gc的速度能赶上创建会话的速度么，如果有人故意这么搞

1、如果只是发起连接，而不能通过验证，这种攻击叫DOS(Denial of Service)，软件层面是不能防备的。 2、如果是验证用户故意这么搞，那么，要么是密码泄露，要么是对方的违背合同责任或诚信职责。你可以把用户放入黑名单等。 至于GC，gc跟上的触发条件之一就是内存紧张，内存紧张了，gc就跟上。如果你内存不紧张，何必关心gc的速度？

[catchdream]

2.客户端离开后（logout或者断线），如果实现心跳包机制，一般服务器端会受到异常，释放资源等待GC就行，这中间可能有一点延缓，不过一般不是大问题。 3.现在有Session ID，不是能确定只在Session里面的客户端你才接受数据；如果真知道用户名和密码，你肯定要解码了，要不你怎么知道是无用数据。

[tianmao111]

恩好的比较有道理