服务端定义一个UInt64变量计数器,每秒+1客户端也定义一个UInt64变量计数器,也是每秒+1客户端十秒发送一次心跳,发送的时候把客户端自己的UInt64变量的值发送给服务端。服务端收到之后,把客户端发送来的值记录下来。服务端每30秒循环一下 客户端LIST列表,把他们的值提取出来。对比服务端自己的计数器:服务端计数器的值 减去 客户端发送心跳包时的值,如果结果大于 30,说明客户端至少有两次没有发送心跳了  就判定客户端掉线了---------------------------------------还有没有更好的心跳包方法?

解决方案 »

  1.   

    UDP发心跳包,没有太大意义。UDP是不可靠面向无连接的协议,也就是说客户端发了心跳服务端也不一定收得到,采用TCP就可以。
      

  2.   

    tcp
    用一个定时器 来发心跳包撒
      

  3.   

    UDP 发心跳是为了保证穿透路由器 保持NAT 。也就是打洞
    楼主描述那种 双发都能发起通信,不知道是否是业务需要。不过 不管是否双发都能主动通信 心跳部分 还是客户端发起 服务端收到心跳后 记录该客户端 最后一次与服务器通信时间。服务端只需要判断客户端最后一次通信时间超过多长时间阀值 才认为客户端掉线。如果心跳=1分钟。那么这个阀值定义成3分钟 就是说连续3次心跳没收到 就任务该客户端掉线。还有你在测试的时候 靠自身的程序来记录收发 不一定可靠。你可以用抓包工具抓客户端和服务器的数据收发 看看是否有掉包的情况
      

  4.   

    就楼主提的问题第一反应想到的逻辑优化如下:不用UInt64那么大的变量,uint16就成,如果超时时间是30秒的话也不用1秒一次的来浪费时间片,创建一个uint16计数器变量的list,程序设置10秒一次,每次list中所有的计数器变量自加1且每次自加完成后判断计数器的值,如果大于等于3(理论不会大于)则说明掉线,将此超时的计数器从list中移除后执行掉线相关的操作;而客户端则1秒一次的定期发送心跳包,服务器监听端收到客户端心跳包时先判断list中有无此心跳包相应的客户端的计时器,有则清零无则向list中添加新的值为0的计数器