关于WSAEventSelect的可靠性

茅延安

WSAEventSelect机制将网络事件绑定到event上，当网络事件发生时，event被触发。
但event只有两种状态，当网络事件多次发生时，event并不能标识出事件发生的次数，只能表明事件发生过
那么在有些情况下，负责wait该事件的应用线程会丢失一些事件。
这种说法成立么？
如果成立，那么WSAEventSelect就是一种不可靠的机制

winston

没听说过会丢失。微软的这套网络接口实现，早都有源代码泄漏出来了。我甚至追踪了不少代码，解决了很多以往的困惑。你可以追踪一下这个API的实现。

ztenv

不需要知道发生多少次，只需要知道发生了即可。你说的丢失事件是指网络包的到达事件还是？

freeeyes

不会发生你说的情况，如果数据阻塞到一定程度，tcp会通知远程进入阻塞状态。（在TCP模式下）， UDP另外一回事，具体可以看TCP IP 卷二

茅延安

ztenv 发表于 2013-9-26 09:16
不需要知道发生多少次，只需要知道发生了即可。你说的丢失事件是指网络包的到达事件还是？ ...

是指“数据到达”事件。
TCP下或许不需要关注“数据到达了多少次”，因为总能一次读出来，再进行拆包。
UDP呢？

ztenv

茅延安 发表于 2013-10-18 08:10
是指“数据到达”事件。
TCP下或许不需要关注“数据到达了多少次”，因为总能一次读出来，再进行拆包。
U ...

UDP压根不需要使用这个吧？使用这个意义何在？

另外：即使使用这个关系也不大，因为当你收一次数据后，没有收完，还会继续触发事件，当然当你接的慢，发的快了，肯定会丢包的。

茅延安

ztenv 发表于 2013-10-18 09:40
UDP压根不需要使用这个吧？使用这个意义何在？

另外：即使使用这个关系也不大，因为当你收一次数据后， ...

理论上讲，事件/通知方式好于轮询。
版主的意思是不是这样，TCP下有N个通道（取决于客户数量），轮询效率低；UDP下只有一个通道，一个线程死循环读也无伤大雅？

假定UDP也使用WSAEventSelect机制，那么绑定的事件是水平触发的？只要检测有未读的数据，就会不时的触发事件？那感情好了，永远不丢