Jump to content
  • Advertisement
Sign in to follow this  
johnnyBravo

winsock, is it ok to share the same msg value for listen and connect sockets?

This topic is 4233 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

In winsock, I have the listenSocket which obviously just listens for connections WSAAsyncSelect(listenSocket, Window::getHandle(), WM_WSAASYNC, FD_READ|FD_WRITE|FD_ACCEPT|FD_CLOSE); But if I have another socket that I want to connect to someone with eg connectToSocket is it ok to use the same msg (WSAASYNC) value used by the listenSocket? eg: WSAAsyncSelect(connectToSocket, Window::getHandle(), WM_WSAASYNC, FD_READ|FD_WRITE|FD_CONNECT|FD_CLOSE); Thanks

Share this post


Link to post
Share on other sites
Advertisement
Sure, as long as your code separates the sources when it receives the message.

However, I would suggest that async sockets do not perform very well, and there's a limit to the number of async sockets you can have in your program. It's also not portable. Last, there are several pitfalls, mostly having to do with trying to call WinSock back from within the message notification (don't do it!).

If none of that is of concern to you, then async sockets can work well in a regular windows-only application. If you do care about many open sockets, or scalability, or portability, then another approach (using select(), or using overlapped I/O on sockets with I/O Completion Ports) might be better.

Share this post


Link to post
Share on other sites
I'd have to strongly second the suggestion to use non-blocking sockets or (if you really need it) select. Asynchronous sockets are far more trouble than they're worth, and equivalent (but superior) functionality is available in many other ways.

Share this post


Link to post
Share on other sites
Yep, no problem; all you do is read off the socket/write to the socket when you want. You can do this any time during your regular game loop with no problems. The OS will take care of buffering the actual communicated data behind the scenes and holding on to it until you read it off the socket. The main point of a non-blocking socket is that you can completely control the timing of socket operations (since they never block) within a single thread.

The only thing you have to be careful with is the potential for the socket to immediately fail an operation because it's in a busy state (EWOULDBLOCK). Usually it's enough to just hold on to whatever data you have until the next frame/game loop iteration, and try again. (This also works for reading off a socket - if you get EWOULDBLOCK when you try to read, just try again next time through the loop and it should be fine.)

As a bonus, non-blocking BSD-compatible sockets are portable to every major platform in use, so you have a solid reusable skill under your belt.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!