WSAEventSelect and WSAWaitForMultipleEvents: can events get lost???
Bob Rock
creating a multi socket application using the WSAEventSelect model and
associating a different event object to each created socket I was wondering
if, since WSAWaitForMultipleEvents returns a single event, and having more
events happening at the same exact moment, some of them could get lost (or
not be signaled by WSAWaitForMultipleEvents). Are they eventually buffered
so that an interested application can process all of them?
Regards,
Bob Rock
Alun Jones
If events are lost by the stack, then that would be a bug in the stack.
Obviously, if events are lost by the app, that would be a bug in the app,
unless it meant to lose the events. When WSAWaitForMultipleEvents tells you
an event has been signalled, you should call WSAEnumNetworkEvents to find out
what event(s) is/are signalled.
Alun.
~~~~
[Please don't email posters, if a Usenet response is appropriate.]
--
Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find us at
1602 Harvest Moon Place | http://www.wftpd.com or email al...@texis.com
Cedar Park TX 78613-1419 | VISA/MC accepted. NT-based sites, be sure to
Fax/Voice +1(512)258-9858 | read details of WFTPD Pro for XP/2000/NT.
Bob Rock
> Obviously, if events are lost by the app, that would be a bug in the app,
> unless it meant to lose the events. When WSAWaitForMultipleEvents tells
you
> an event has been signalled, you should call WSAEnumNetworkEvents to find
out
> what event(s) is/are signalled.
>
> Alun.
> ~~~~
>
Alun, are you saying that although WSAWaitForMultipleEvents returns
signalling "events" on a SINGLE object event, events on MORE object events
may have occured thus requiring WSAEnumNetworkEvents to be called on all
object events???? This was the sense of my question: what happens is events
occur at the same exact time on more object events considering that
WSAWaitForMultipleEvents may signal events on only one object event at a
time. Is there a chance to see them lost or are they buffered meaning by
this that the following calls to WSAWaitForMultipleEvents will return
immediately signalling the remaining events on the other object events???
Regards,
Bob Rock
Scott McPhillips
> Alun, are you saying that although WSAWaitForMultipleEvents returns
> signalling "events" on a SINGLE object event, events on MORE object events
> may have occured thus requiring WSAEnumNetworkEvents to be called on all
> object events???? This was the sense of my question: what happens is events
> occur at the same exact time on more object events considering that
> WSAWaitForMultipleEvents may signal events on only one object event at a
> time. Is there a chance to see them lost or are they buffered meaning by
> this that the following calls to WSAWaitForMultipleEvents will return
> immediately signalling the remaining events on the other object events???
>
> Regards,
> Bob Rock
Events remain signaled until they are cleared, and only one at a time
can be cleared. If two or more events are signaled then your second
call to WSAWaitForMultipleEvents will return immediately with one of the
waiting events. This is common sense: the function would be useless if
it "lost" events.
--
Scott McPhillips [VC++ MVP]
Bob Rock
> can be cleared. If two or more events are signaled then your second
> call to WSAWaitForMultipleEvents will return immediately with one of the
> waiting events. This is common sense: the function would be useless if
> it "lost" events.
>
> --
> Scott McPhillips [VC++ MVP]
Yes, this is reasonable, still I wondered how big are these (event and data)
queues.
Bob Rock
Scott McPhillips
Events are not queued. They are like a boolean variable. Your question
seems to imply a concern about being overwhelmed with too much data.
That doesn't happen. FD_READ, for example, is set when data is
available to notify you to read. No more FD_READs occur until after you
read. If you are slow to read and the data buffers become full then the
transmitter is paused until you read the buffered data. The purpose of
FD_READ and FD_WRITE is to notify you when it is your turn in a
well-regulated handshake. If it is properly coded then no data can be
lost - it moves at the speed of the slowest participant.
Alun Jones
wrote:
>Events remain signaled until they are cleared, and only one at a time
>can be cleared. If two or more events are signaled then your second
>call to WSAWaitForMultipleEvents will return immediately with one of the
>waiting events. This is common sense: the function would be useless if
>it "lost" events.
No. One unsignalled-to-signalled event object transition may represent
several network events. Only WSAEnumNetworkEvents will tell you which network
events occurred. If you never call WSAEnumNetworkEvents, you will miss
network events that occur close together.
Alun Jones
>Alun, are you saying that although WSAWaitForMultipleEvents returns
>signalling "events" on a SINGLE object event, events on MORE object events
>may have occured thus requiring WSAEnumNetworkEvents to be called on all
>object events???? This was the sense of my question: what happens is events
>occur at the same exact time on more object events considering that
>WSAWaitForMultipleEvents may signal events on only one object event at a
>time. Is there a chance to see them lost or are they buffered meaning by
>this that the following calls to WSAWaitForMultipleEvents will return
>immediately signalling the remaining events on the other object events???
I couldn't parse that. Sorry.
Part of the problem here is that "event" is a term that is much overused, and
in this case means two things. First, there's the traditional Windows term,
which usually means an "event object", that can be waited on by the *WaitFor*
functions (WaitForSingleObject, MsgWaitForMultipleObjects, etc, etc). Then
there's the Winsock term, for a "network event", which is something like
FD_READ (the socket has data for you to read), FD_WRITE (the socket has buffer
space available for writing into), etc.
When a network_event occurs on a socket that is associated (by WSAEventSelect)
with an event_object, the event_object enters the signalled state. At some
point later, this will cause the *WaitFor* function to return, with whatever
return value indicates that the event_object is in the signalled state. At
this point, you should pass the event_object (and socket) in to
WSAEnumNetworkEvents to get out a list of network_events that occurred since
the last time WSAEnumNetworkEvents was called (because there may have been
several, and the event_object only tells you that one or more has occurred,
not which ones). WSAEnumNetworkEvents also resets the state of the
event_object, so that you don't miss any network_events.
Hope that's clear.
Jim
To one event object (created with a call to CreateEvent) you may associate
more network events (such as FD_READ, FD_WRITE, etc.). What I was asking is
if, when returning from a call such as WSAWaitForMultipleEvents, I need to
check (with a call to WSAEnumNetworkEvents) for event on more event objects
or on only the signalled one.
Bob Rock
Alun Jones
WSAWaitForMultipleEvents returns a single value to indicate which event object
was signalled. You call WSAEnumNetworkEvents on that event object, to find
which network events occurred on the socket(s) monitored by that event object,
then you go back to call WSAWaitForMultipleEvents again.