Is there a way to use a method like this:
#define YOUR_SOCKET_MSG WM_USER + 100 // WM_USER is a base value for user-defined messages
...
WSAAsyncSelect(theSocket, hwnd, YOUR_SOCKET_MSG, FD_READ | FD_WRITE | FD_CONNECT | ...);
...
in window procedure:
switch (msg) {
case YOUR_SOCKET_MSG:
if (WSAGETSELECTERROR(lParam)) { // If an error occurred,
closesocket(theSocket); // Close the socket
WSACleanup(); // Shutdown Winsock
return NETWORK_ERROR; // Return NETWORK_ERROR, WSAGetLastError(), etc.
}
switch (WSAGETSELECTEVENT(lParam)) { // Differentiate between the events
case FD_READ:
// Receive data
break;
case FD_WRITE:
// Write data
break;
case FD_CONNECT:
// Just connected to server
break;
case ... // Same setup for other flags
break;
}
break;
...
}
in a console application?
WSAEventSelect, AsyncSelect requires a window... I guess you could create a window in your console app... but that's just lame
Both of those require a window?
WSAEventSelect() doesn't, but WSAAsyncSelect() does.
Well, I guess here's my main question I should seek an answer to first.
If, as of right now, my client will most likely only create one socket to bnet at a time. A simple blocking style socket would be efficient enough for this. What if, though, in the future I might need to create a bnftp connection, or a bnls connection or maybe even multiple clients online at once? Should I go ahead an use socket overlapped io instead of a blocking style socket? Even with one connection, would overlapped io still be the best option?
What do you guys think
With blocking sockets, you can handle multiple connections using select() or sepetate threads.
So, in short, what would you do? What's best? Overlapped, or blocking?
I personally just like using multiple threads in few-connection scenarios.
Quote from: warz on March 28, 2006, 12:56 AM
So, in short, what would you do? What's best? Overlapped, or blocking?
On Windows, probably overlapped i/o or i/o completion ports
Quote from: TheMinistered on March 27, 2006, 11:07 PM
WSAEventSelect, AsyncSelect requires a window... I guess you could create a window in your console app... but that's just lame
However, it's probably OK to use a message-only window for this. Message-only windows are created by passing HWND_MESSAGE as the parent when calling CreateWindowExW.
Id use overlapped IO and event handles, use a main loop to wait for the events with WASWaitForMultipleEvents, or considering how WSAEvents are also regular event handles, WaitForMultipleObjects would also work too if you are waiting on things other than sockets aswell. This way you can have an idle function called and be able to run timed events from the main loop. You can also not have to worry about race conditions which threads introduce. The reason I wouldn't use IO completion routines is that you lose the main loop concept which makes designing applications like this, atleast IMO, alot easier.