WSAAsyncselect winsock problem
-
i am using the function WSAAsyncSelect() to make a socket send a windows message to the message queu of my program when data is ready to be received, like this: WSAAsyncSelect(sd, hwnd, WM_SOCKET, FD_READ); it sends the WM_SOCKET message and all works well ... but i also want a message to be sent when the connection is closed, thus the message WM_LOST. but when i just add: WSAAsyncSelect(sd, hwnd, WM_LOST, FD_CLOSE); the function seems to overide the previous and it doesn't respond to received data anymore. how do i make it respond to both with a different message, or is it possible to say something like: WSAAsyncSelect(sd, hwnd, WM_SOCKET, FD_READ | FD_CLOSE); and see the difference in the message handler...? Thanks :cool: Kuniva
-
i am using the function WSAAsyncSelect() to make a socket send a windows message to the message queu of my program when data is ready to be received, like this: WSAAsyncSelect(sd, hwnd, WM_SOCKET, FD_READ); it sends the WM_SOCKET message and all works well ... but i also want a message to be sent when the connection is closed, thus the message WM_LOST. but when i just add: WSAAsyncSelect(sd, hwnd, WM_LOST, FD_CLOSE); the function seems to overide the previous and it doesn't respond to received data anymore. how do i make it respond to both with a different message, or is it possible to say something like: WSAAsyncSelect(sd, hwnd, WM_SOCKET, FD_READ | FD_CLOSE); and see the difference in the message handler...? Thanks :cool: Kuniva
Yes, the WSAAyncSelect maintains a single state for a socket, each call overrides the previous and the flags are indeed a bit map you can or. Always call your recv until you get a WOULDBLOCK error, then wait for the message.
-
Yes, the WSAAyncSelect maintains a single state for a socket, each call overrides the previous and the flags are indeed a bit map you can or. Always call your recv until you get a WOULDBLOCK error, then wait for the message.
um sorry i dont get that. how can i see if the message WSAAsyncselect() sends is triggered by FD_READ or FD_CLOSE ??? i also need to know how i can see if there's an incoming connection request and how to accept it because i just added FD_ACCEPT to WSAAsyncselect() and i made the socket listen but it just accepted the connection without i used the accept() function... i think its weird... (i saw the connection was accepted because i ran netstat and it said under connection status "ESTABLISHED") Kuniva
-
um sorry i dont get that. how can i see if the message WSAAsyncselect() sends is triggered by FD_READ or FD_CLOSE ??? i also need to know how i can see if there's an incoming connection request and how to accept it because i just added FD_ACCEPT to WSAAsyncselect() and i made the socket listen but it just accepted the connection without i used the accept() function... i think its weird... (i saw the connection was accepted because i ran netstat and it said under connection status "ESTABLISHED") Kuniva
i will make this more practical to imagine by telling u what program it is. It is supposed to be a multithreaded echo server, i mean, its supposed to accept any incoming connection request AND (the special bit) when 1 client sends something to the server, the server needs to send this back exactly as it came to ALL (i repeat ALL) connected clients. hope this helps? Thanks for the help Kuniva
-
um sorry i dont get that. how can i see if the message WSAAsyncselect() sends is triggered by FD_READ or FD_CLOSE ??? i also need to know how i can see if there's an incoming connection request and how to accept it because i just added FD_ACCEPT to WSAAsyncselect() and i made the socket listen but it just accepted the connection without i used the accept() function... i think its weird... (i saw the connection was accepted because i ran netstat and it said under connection status "ESTABLISHED") Kuniva
The top half of the long value in the window message (from memory) contains the FD_ flags for the event(s) that trigger the message. In general, however, I use AsyncSelect like this:
- I make a winsock call.
- If the call returns the WOULDBLOCK result I wait for AsyncSelect to send a message.
- I make the same call again. This time I should get a real result (should I get a WOULDBLOCK I'll wait again).
When I get these messages I generally just look for an error code , or a FD_CLOSE. Otherwise I check the status by making the winsock calls. So, for example, you do a listen. You call accept and it will normally give you a WOULDBLOCK (if it doesn't it means a call is already waiting and you can take it). Then you wait for a message from asynselect to tell you there's a connection waiting. Then you make that accept call again and it gives you the new socket. The only exception to this pattern is the connect call which you only make once. In the case of the connect call once your FD_CONNECT comes back you're connected. You don't make the connect call again (an annoying inconsistency to my mind).