平时不咋搞socket 所以对这方面 不是很了解 只知道 单纯的发送数据而已
目前我的做法是
客户端起一个线程倒计时10秒 然后一个线程接受数据 如果在10秒内受到来自服务端的数据 那么重新倒计时 如果10秒到了 没有收到来自服务器的数据 那么就表示与服务器失去了连接  当然接受数据的同时每5秒向服务器发送一个数据过去
然后服务端
服务端每5秒循环的为在线的每一个客户端发送一个数据过去 不过发送前判断一下该客户端上一次发来的数据的时间与现在的时间差 超过10秒 表示客户端挂了   当然也有一个线程在接受数据 接收到一个客户端数据的时候 将该客户端的数据发来的时间重新标记
但是我咋总觉得 我的做法很二 然后我又YY了一下
如果像我这样做 对于单独的一个客服端来说到没啥问题   如果 服务端当前有N多 比如百万个客户端  那么也每个一段时间 循环的向每个客户端发送数据?发送前还要判断时间差?而且同时 还要不停的接受来自百万个客户端发来的数据?那得了啊?、、如果是udp还好  要是在某种不得已的情况下 要tcp去连接客户端 然后却又不巧的 所有客户端都意外断开 没有像服务器发送离开请求 那么服务器 连接的时候 不是还要超时等待?就算开一个线程来等待 那么 同一时刻 起百万个线程去超时等待?、、
YY不下去了、、、、好吧 我承认 我很菜 没接触过这方面的编程、、

解决方案 »

  1.   


    貌似 最近 socket 很流行   看到好多人都再问 关于socket的问题 、、
      

  2.   

    起什么线程阻塞啊?假设正在异步处理一个消息,那么可能占用一个线程。处理完消息,方法就结束了。难道还要去写什么while循环去阻塞自己?假设有1万个客户端与服务器通讯,可能有几十个线程就足以并行(而不是排队)通讯了。谁告诉你说要“起1万个线程”?
      

  3.   

    而假设服务器每隔几分钟给客户端轮流发送一个消息,它就遍历一下依此发个消息,然后就结束了。难道还要while循环阻塞自己?难道还有2个以上线程?
      

  4.   

    我说起线程那个是 在用tcp的情况下
    如果在某种条件下 服务端要和客户端用tcp的连接的情况下 而且又不巧的 一批客户端意外的断线了 那么tcp连接的时候 不是得超时等待?
      

  5.   

    你困惑的很到位,假设1万个在线用户,服务器光循环心跳的线程就需要1万个,每个线程占2MB,就是20GB,32位机起码会歇菜了,即使强制设256KB也需要2.5GB,结论是此路不通。建议你研究研究异步通信,推荐个老帖子给你:
    http://bbs.csdn.net/topics/370133409
      

  6.   

    socket有keeplive属性,可自动保持服务器和客户端的心跳检测,不能连接的时候服务器端和客户端都会报错,处理错误即可,另外心跳时间也是可以设置的
      

  7.   

    在Internet上采用TCP进行通信的系统,都会遇到一个令人头疼的问题,就是“掉线”。而“TCP掉线”这个问题远比我们通常所能想象的要复杂的多 —— 网络拓扑纷繁复杂、而从始节点A到终节点B之间可能要经过N多的交换机、路由器、防火墙等等硬件设备,每个硬件设备的相关设定也不统一,再加上网络中可能出现的拥塞、延迟等,使得我们在编程时,处理掉线也非常棘手。
    这里有篇blog详细讲心跳机制的,可以参考一下
      

  8.   

    客户端定时想服务端发送心跳封包就是。。服务端的 socket 上面设置 receive timeout。。过了固定时间没有动静就会自动踢掉。
      

  9.   

    不是UDP的话,心跳有啥用?徒增开销