Well, first off let me say this is my first article that I am posting here so please
forgive any terrible errors that I make. I scanned over many of the articles in the networking
section of the Code Project and couldn't find any that were relevant
to using Winsock2 Network Events.
Unfortunately this came at a time when I was looking to implement some
functionality in my program that used them.
That being the case, I bit the bullet and cracked open
the books. (Along with faithful MSDN of course.)
There are some assumptions that I am making about the readers of this article. They are:
- Familiar with MFC 4.2 and VC. (These are obviously a must)
- Understand the difference between synchronous and asynchronous
- A basic understanding of socket programming. Nothing extremely heavy is required but
you should already know how to set up a socket and about the different
states it can be in, etc...
Why Network Events?
When I first examined the problem I was faced with, I had three different options to use.
The first was to use regular socket calls under
Winsock 1.1. The next approach I came across, which I might add only lasted as
long as it took me to read it, was to use notification of network "events"
through windows messages. This poised a very big problem considering the program I was
integrating this code into had no message pump. This brings us to the
solution: Notification through WSA Events.
How do they Work?
The idea is that there are a limited number of things that most people do
on a certain socket. You send data, receive data, connect to another
socket, accept incoming connect requests and you close a socket. There
are perhaps a couple more but we will only focus on the major ones
for this article. When one of these things occurs, an event you associated
with it will signal and you do what ever is necessary. The
network events that can be handled are as follows (again, these are only the
ones we are going to be discussing):
Lets set up a small sample to demonstrate. The first thing you need
to do is initialize the winsock2 library. There is probably more than one way to do this
but here is how I go about it.
LPFN_WSASTARTUP lpf =
The initialization can be done anywhere, as far as I know, provided
that it is done before you use any calls to
winsock functions. The next important thing to do is to create the event
we want to use to determine when one of network
events takes place. To do this, use the Winsock2 API call
After the event is created
it must be associated with the socket that the events will
occur on and which events it is to handle. That will be done
. For the following we
are setting up an event to signal on the arrival of a request
to connect. This is usually done on a listening socket.
For us, this socket is
It will look like this:
WSAEVENT hEvent = WSA_INVALID_EVENT;
hEvent = WSACreateEvent();
::WSAEventSelect(m_listen, hEvent, FD_ACCEPT);
If the socket in question was our data transfer socket,
say for example,
SOCKET m_socket, that it would more
look like this:
WSAEVENT hDataEvent = WSA_INVALID_EVENT;
hDataEvent = WSACreateEvent();
::WSAEventSelect(m_socket, hDataEvent, FD_WRITE | FD_READ | FD_CLOSE);
It should be noted that it is not possible to use two
different event objects to listen for different network events
on the same socket. You cannot do the following:
WSAEVENT hEvent1 = WSA_INVALID_EVENT;
WSAEVENT hEvent2 = WSA_INVALID_EVENT;
hEvent1 = WSACreateEvent();
hEvent2 = WSACreateEvent();
::WSAEventSelect(m_socket, hEvent1, FD_READ);
::WSAEventSelect(m_socket, hEvent2, FD_WRITE);
Handling the Event Notifications
Now that the events we are going to use are set up,
we need a way of waiting on and handling them. The events are actually just regular
Win32 events which makes them a
The function we can use to wait for these events to occur
function will just cause the thread it is in to sleep
until a network event that we are handling
occurs. An example of this would be:
WSAEVENT hEvent1 = WSACreateEvent();
WSAEVENT hEvent2 = WSACreateEvent();
::WSAEventSelect(m_listen, hEvent1, FD_ACCEPT);
::WSAEventSelect(m_data, hEvent2, FD_READ | FD_CLOSE);
WSAEVENT* pEvents = (WSAEVENT*)::calloc(2, WSAEVENT);
pEvents = hEvent1;
pEvents = hEvent2;
int nReturnCode = ::WSAWaitForMultipleEvents(2, pEvents,
FALSE, INFINITE, FALSE);
If waiting for only one event the same function can be used.
Just alter it to look something like:
int nReturnCode = ::WSAWaitForMultipleEvents(1, &hEvent1,
FALSE, INFINITE, FALSE);
The first parameter is the number of events that you want to wait on.
The second is a pointer to an array of the events you want to
wait on. The third event is a
BOOL value that determines whether or not the wait
function should continue to sleep until all events have signaled.
This usually will be
false but you may find some need to wait on all events.
The fourth parameter is how long you want to wait. Since I usually put
this functionality in another thread I leave it at infinite. If
you have this in your main thread, you may want to limit it to 5 seconds
or some other timeout that relates to your application. The fourth
parameter is whether or not you want it to be
alertable. Now once an event fires there should be something that handles each event.
The first thing that needs to be done is to figure out exactly which
event fired. For this we can use the function
One of the parameters for this function is a structure
. Moving along with the code
we had above, we would proceed to do the following:
::WSAEnumNetworkEvents(m_listen, hConnectEvent, &wsaConnectEvents);
::WSAEnumNetworkEvents(m_data, hProcessEvent, &wsaProcessEvents);
After that has been completed you have the event that
fired on one of the sockets. Now we need to break it down
and handle it per event so that the correct action is taken
for the correct event. This is done as follows:
(wsaConnectEvents.lNetworkEvents & FD_ACCEPT) &&
(wsaConnectEvents.iErrorCode[FD_ACCEPT_BIT] == 0) )
This manner of checking can be done for each
have set up and for each network event that the
WSAEVENT will signal for. All that you must do it to change the
FD_ACCEPT to whatever network event you are handling and
change the error check bit to the appropriate variable.
I hope this helps somebody writing network applications.
I have tried to compact a lot of information into a small article
so I know that it may not answer all questions. Feel free to email me
or post questions below and I will try to answer all that I can.
I would also like to apologize for not having some sort of demo app
to go along with this article but I am very busy right now and all
the source that I currently have that uses network events is owned by my company.