winsock - multiple sockets WndProc user defined pointer
Author
Hi,
Situation:
1) have multiple asynchronous (non-blocking) sockets
2) each socket is wrapped in a class (CSocket)
3) all messages (FD_READ, FD_WRITE etc) enter through WndProc
4) in WndProc, wParam is the socket handle
Now, I'd like to forward the incoming messages in WndProc to each corresponding socket class instance.
Can I set a user defined pointer somewhere (on socket itself or passed as extra parameter send by WinSock to WndProc) so I can directly identify to which instance the message should go?
Right now I'm looping through all CSockets and compare the socket handle with wParam, if it matches, pass the message to that class. I'd like to improve this a bit.
Alternatively, I could create a table that maps socket to instance, but that is a bit bug prone.
Thanks.
Most straightforward is to use a hash table (for example, std::hash_map) from socket ID to CSocket pointer.
However, in general, I would suggest not using asynchronous sockets, because they are ill behaved, and Windows specific. For example, you're suggested to not actually call into WinSock within the WndProc callback, but instead you're supposed to set a flag, and then actually do the work when the WndProc has returned. One way of getting around that is using Windows APC.
However, in general, I would suggest not using asynchronous sockets, because they are ill behaved, and Windows specific. For example, you're suggested to not actually call into WinSock within the WndProc callback, but instead you're supposed to set a flag, and then actually do the work when the WndProc has returned. One way of getting around that is using Windows APC.
Author
Thanks, I'll look into the hash_map thing you suggested.
Concerning your second point, that's interesting. I think I have read to many conflicting articles on (non-blocking) WinSocket use. Has left me a bit confused and uncertain.
Could you tell me or point me someplace that explains what the advantages/disadvantages of each setup are, preferably without opinions?
(In the context of a simple first-person-shooter networking?)
Concerning your second point, that's interesting. I think I have read to many conflicting articles on (non-blocking) WinSocket use. Has left me a bit confused and uncertain.
Could you tell me or point me someplace that explains what the advantages/disadvantages of each setup are, preferably without opinions?
(In the context of a simple first-person-shooter networking?)
Quote:Original post by hplus0603
(for example, std::hash_map)
In MSVS 2003 and 2005, I believe that hash_map is in the stdext namespace.
Non-blocking and asynchronous are different concepts.
Asynchronous sockets are sockets you set up with WSAAsyncSelect(), and which post messages to your WndProc.
Non-blocking sockets are sockets that will never block when you call send() or recv() on them, and can be used in whatever way you want (using select(), polling, etc).
Asynchronous sockets are sockets you set up with WSAAsyncSelect(), and which post messages to your WndProc.
Non-blocking sockets are sockets that will never block when you call send() or recv() on them, and can be used in whatever way you want (using select(), polling, etc).
Author
Ahaa, I thought they where the same. I guess that explains my confusion...I'll re-read my resources and see if it makes more sense now.
Quote:Original post by hplus0603
For example, you're suggested to not actually call into WinSock within the WndProc callback, but instead you're supposed to set a flag, and then actually do the work when the WndProc has returned.
Why?
Because of re-entrancy, ordering and correctness issues.
Basically, the WinSock implementation of asynchronous sockets isn't very robust.
Basically, the WinSock implementation of asynchronous sockets isn't very robust.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
