Sign in to follow this  

Winsock: ioctlsocket vs. WSAEventSelect/WSAWaitForMultipleEvents/WSAEnumNetworkEvents

This topic is 4866 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Apologies in advance for anything that sounds stupid, as I am new to this. I'm currently learning about all the possible ways to implement a multiconnection server so that I can be familiar with what's out there. I know about the WSAAsynchSelect and multithreaded methods of multiple connections, but let's assume this is a console application with low traffic and few clients where debugging ease is the top priority (so single-threaded). That leaves me with the option to either make my sockets nonblocking via ioctlsocket or use the winsock model that centers around WSAEventSelect, WSAWaitForMultipleEvents, and WSAEnumNetworkEvents... where WSAWaitForMultipleEvents is optional because WSAEnumNetworkEvents will still be effective reguardless of whether WSAWaitForMultipleEvents was used. My question: Why would I use WSAEventSelect, WSAWaitForMultipleEvents, and WSAEnumNetworkEvents instead of setting my sockets to be non-blocking by using 'ioctlsocket' and then handling the logic for connections myself? WSAWaitForMultipleEvents blocks the thread, so it would be just as bad as using a naked send or recv call in a thread for a blocking socket. So... blocking issues are not eliminated. WSAEnumNetworkEvents can be called after a call to WSAWaitForMultipleEvents or it can be used to poll for events. So... polling issues are not eliminated. So I'm either going to block or poll anyway, and I thought the whole idea behind the WSA methods described in this post was to make message handling event-based to eliminate blocking or polling... sort of like how WSAAsynchSelect works. Am I seeing this the wrong way? [Edited by - Bystander on August 21, 2004 12:42:07 AM]

Share this post


Link to post
Share on other sites
There is no wrong way to do things, just unoptimal use of CPU & bandwidth. In the case you are describing (low traffic, few users), any method will do. Since you value debugging at a premium, I'd suggest you pick non-blocking even if this means your CPU will spin in a tight loop. Once you get that running, then you can upgrade your server with thread-blocking or wait-blocking strategies.

> WSAWaitForMultipleEvents

The dwDelay parameter can be set to a value other than INFINITE so that you can break out of the wait and do useful work if nothing is to be done with the socket.

-cb

Share this post


Link to post
Share on other sites

This topic is 4866 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this