Creating Asynchronous Winsockets

Started by
2 comments, last by bose 22 years, 4 months ago
Hi! I need help with using Asynchronous sockets. From what i''ve seen, creating a socket object class is a great idea, but I can''t figure out how to specify message handling for different objects! Do I need to call WSAAsyncSelect() for every socket object I create? And when a message is sent in a server application with many open client sockets, how can I figure out which socket object is performing the message? I mean I know commands contain the SOCKET object in the wParam variable, but if I have a socket class, how would I be able to figure out which SOCKET object being called goes to which socket CLASS? I am stumped! If anyone knows of a good asynchronous tutorial (there was one on gamedev but it left out most of the code I need to figure out) or some sample code, I would greatly appreciate it. Thanks
Advertisement
quote:Do I need to call WSAAsyncSelect() for every socket object I create?

Yes.

quote:if I have a socket class, how would I be able to figure out which SOCKET object being called goes to which socket CLASS ?

Keep a table indexing your socket objects according to their file descriptor (SOCKET).
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan
You don''t necessarily have to use WSAAsyncSelect to use sockets in Windows. In fact, if you are ever thinking of porting to Linux or some other platform, it''s probably best that you don''t!

The problem with WSAAsyncSelect is that is requires a window to send messages to. This makes it more complicated to integrate into other projects in the future.

If you stick to the lower level socket API''s you can use the select function (BSD compatible) which will tell you when a socket has data waiting etc. This way, you don''t need to worry about which object is associated with which message because each socket object can be totally self-contained.

This also makes it easier to add the option of a blocking socket if you so desire.
"Absorb what is useful, reject what is useless, and add what is specifically your own." - Lee Jun Fan
If you want to stick to windows only, you could give the class a static HWND and a function for initialising it. (Like CSocketClass::InitSocketClass())

In this function you would create an invisible window with the only purpose of sending and receiving messages related to the sockets of the class. Now every instance would use this window, you''d just need some kind of mapping to relate a socket to its instance.

Of course you would also need a cleanup function.
Kill mages first!

This topic is closed to new replies.

Advertisement