本帖最后由 qweqwsdadsa 于 2014-09-21 09:44:32 编辑

解决方案 »

  1.   

    表示从不用KeepLive操作
      

  2.   

    我也没用过KeepLive,我认为还是自己实现心跳机制,由客户端去发送就可以了,服务端可以专门有一个线程对这些连接进行检测是否超时,比如可以在服务端的UI线程中使用WM_TIMER的机制来检测这个东西。
      

  3.   

    我不知道KeepLive检测到断开是什么样的机制,实际上完成端口上,你投递了操作出去,如果客户端异常断开,也就是不经过正常的closesocket结束时,也就是你说的那种断网,客户端崩溃之类的问题产生时,GetQueuedCompletionStatus都不一定会返回通知,这种情况下,我想,如果依赖SOCKET内部的KeepLive机制的时候,它在内部又是如何去实现判断当前这个SOCKET是否还有效呢,如果它能准确的判断,那直接在GetQueuedCompletionStatus就可以返回通知我们出现异常了,所以嘛,我还是觉得应该自己去判断会好一点,超时的时候我们自己closesocket就好了。
      

  4.   

    这个我用别的IOCP模型进行了,抓包检测,发现在断网之后那个IOCP模型还是会去发送探测数据,从而会重置SOKCET,使之断开。
    而我之前查资料,资料上说“双边设置KeepLive之后,遇到非优雅断开GetQueuedCompletionStatus会返回FALSE”但我现在遇到的情况是,CLient断开之后Server就不去发送探测数据了,GetQueuedCompletionStatus也没有出现触发,SOCKET也不会被重置为断开
      

  5.   


    个人感觉sever端的超时检测机制少不了
    在其他策略处理失效时,这是最后一道防线