do you have to use the WSAAsyncSelect() in the winprocedure in order to create an asynchronous socket?
Printable View
do you have to use the WSAAsyncSelect() in the winprocedure in order to create an asynchronous socket?
No. I assume by "async socket" you mean "socket that receives its event notifications asynchronously" - perhaps "overlapped socket" is more MSDN-speak.
WSAAsyncSelect is one way, it says to Winsock: "I want this socket to be async and I want to register for these events to be sent to this window via this window message when said events happen"
You can make a socket async other ways however - WSAEventSelect, which is similar to AsyncSelect, but you specify an Event object to wait on for network events to occur.
Calling CreateIoCompletionPort with the socket handle also makes it a socket overlapped implicitly, and enables you to receive completions via GetQueuedCompletionStatus.
Finally you can make the socket overlapped at creation time with WSASocket - this isn't usually needed because the functions above make it overlapped anyway, but if you want to use completion routines (nb not same as completion ports), you need to do this I think.
but do all of these go in the winproc()?
what do i do in case of listen() and bind()
are'nt these calls blocking?
if i do it like this then will it be ok?:
maybe bind just binds to a socket, but how about listen()Code:
#define MYMESSAGE WM_USER + 100
winproc();
{
// do stuff needen for winsock to function
bind();
listen();
WSAAsyncSelect(MYMESSAGE); //in the msg parameter
switch(msg)
{
case MYMESSAGE:
switch(WSAGETSELECTEVENT(lParam))
{
case FD_ACCEPT:
accept();
return 0;
case FD_WRITE:
send();
return 0;
}
}
}
i cant put these in a case like accept() can i?
thx!
No. You don't even need a windows procedure unless you're using AsyncSelect, since that uses windows messages.
Don't call bind(), listen(), or WSAAsyncSelect() from your WindowProc. At least, not every time it's called!
You'd typically call bind(), listen() and WSAAS() in your initialisation, or whenever your application "goes online".
They only need to be called once - bind to bind the socket to a port, and listen to start the socket listening for connections. You'd also call WSAAsyncSelect then.
ok i think i got it now but how do i do something like
if the user pressed a key only then will the message be sent i tried making a boolean true when user hits key enter(also in winproc) then inthis does not work, how do i do this?Code:case FD_WRITE:
if(isok==TRUE)
send();
return 0;
Do you mean that you want stuff to only be sent after you press the enter key in your own application?
Incidentally, FD_WRITE(at least from what I read) simply alerts you to the fact that you can write to the socket. You can simply add a keylistener which first checks that it can write (i.e. set a boolean in FD_WRITE so we know its ok) and then after someone hits enter, then do a send.
The sending part probably should not be in the FD_WRITE section at all because unless you simply want to send data every time the socket is ok to write to, you cannot do too much. Well not exactly, but for simplicity's sake I can't think of anything which would need that offhand..but, anyway, you would want to handle that in a key message somewhere else, so you can accumulate whatever you need then when the user hits enter or the like you can just do a send.
Hopefully that helps and makes sense to you.
Note to Pode: You still have to handle (WSA)EWOULDBLOCK even if you've received an FD_WRITE, because you're not guaranteed to have buffer space at some later time after FD_WRITE, and additionally your data might be too large for Winsock to accept at that time.Quote:
Incidentally, FD_WRITE(at least from what I read) simply alerts you to the fact that you can write to the socket. You can simply add a keylistener which first checks that it can write (i.e. set a boolean in FD_WRITE so we know its ok) and then after someone hits enter, then do a send.
Of coruse if you do receive a WOULDBLOCK then Winsock will give you another FD_WRITE when there's space again.
Hehe I knew I would forget something :( thanks aztechd, it is important to always check for WSAEWOULDBLOCK as I forgot to mention. Otherwise everything else should be ok.