Hi all,

Please forgive me about the question am about to ask regarding networking since I am a newbie to it. Anyway my question would be can I use a socket and make use of blocking functions and later I make use of non-blocking functions? Also if Thomas do read this post, I do hope that he continues working on his tutorial. I can't wait for his next tutorial :grin:


Posted on 2004-02-18 06:44:04 by roticv
As far as I know, you can use the setsockopt() (is that what it's called?), to change from blocking to non-blocking and back... I've never tried it myself, but I suppose it's worth a shot to see if it actually works, it probably will.
Posted on 2004-02-18 07:17:57 by Henk-Jan
AFAIK there's no reason why you can't use any socket in blocking mode at any time - asynch (non-blocking) sockets is just a messaging mechanism which allows functions to return immediately with an indefinite response and flag a full response later, rather like overlapped file i/o.. the exact nature of the messaging mechanism being determined by our implementation of nonblocking sockets, ie our choice of api functions.. for example, WSAAsynchSelect makes winsock send socket messages as WM's to a window of our choice, whereas WSAWaitForMultipleObjects and similar operate on socket arrays and use event objects for messaging.
Posted on 2004-02-18 07:18:08 by Homer

The first part of my code makes use of blocking mode to login to the server. Thereafter the login is completed, I wish to make use of non-blocking mode so as to handle messages from the server easily(still using the same socket)... So is it a feasible idea? Or do I have to recode so that my login part would make use of non-blocking mode?
Posted on 2004-02-18 07:54:44 by roticv
As descibed in WinSock API:
function ioctlsocket is used to change the socket from blocking(default) to non-blocking state
1 param = socket handle
2 param = FIONBIO command (it's just a constant)
3 param = pointer to unsigned long that must be 0 to set blocking mode or non 0 to set non-blocking

The WSAAsyncSelect or WSAEventSelect routine automatically sets a socket to nonblocking mode
I think threre is no issures to set blocking or non-blocking mode in any time
Posted on 2004-02-18 09:24:23 by Elohim Meth
roticv, it's probably better to recode to full async - if not for anything else, then to get into the async mindset. Somehow code written for sync sockets often have a lot of assumptions, like "we will get correctly formatted data", "we will receive the amount of data we need", "there won't be timeout or socket errors" et cetera - but of course this is just some unquantified crap :).

I think it *is* possible to do what you want - iirc http://tangentsoft.net/wskfaq/ mentions it somewhere, and has something along the lines of "and a lots of people abuse this and they should be shot" :-)
Posted on 2004-02-18 09:24:31 by f0dder
Yep, here's one example: when you are ready to switch your socket to non-blocking (asynch) mode,simply make a call to WSAAsynchSelect to register a custom WM that will be sent to a window of your choice. This WM contains information about a "socket event", ie FD_CONNECT, FD_READ, FD_CLOSE etc.
Your socket will remain operating in asynch mode until you stop it.
I agree with f0dder here, it's not clever to switch a CONNECTED socket from asynch to synch, does the session stay alive after authentication, or are you meant to make a secondary connection after authentication? If the answer is the former, I'd definitely write the whole thing using an asynch model. Just add a "state flag" to describe the current state of the socket, and define a few equates like "Not Connected" , "Connecting", "Authenticating", "Idle" (where Idle=authenticated, connected, and just waiting for something to happen)
Posted on 2004-02-18 22:22:46 by Homer
Yet another newbie question :grin:

Is there a winsock function that allows you to handle FD_READ and FD_WRITE without using a windows callback (I do not want to mess with the gui part of my code) or Events (Events seem to be sucky idea to me from what I make out).

Also to answer Homer's question, I will still make use of the same socket after the login part.

Seriously in my opinion, it is better to make it using blocking mode for the login part, because if it is done that way, it is easy to read and understand that part of the code (I might be messed up after a few weeks).
Posted on 2004-02-19 09:17:50 by roticv
So how do you want to know about you sent or recieved something?

As an alternative to WSAEventSelect and WSAAsyncSelect in Winsock2 API there is Overlapped IO support.
Winsock 2 API functions WSASend and WSARecieve allow you to specify
pointer to WSAOVERLAPPED structure in their sixth parameter.
In this structure there is hEvent member that informs you about Winsock completes your request.
Also you can use 7-th parameter lpCompletionRoutine. It's callback procedure and called also when
Winsock completes your request.
Posted on 2004-02-19 09:45:29 by Elohim Meth
Personally I dislike the WSAAsyncSelect / WM socket notification method because once you start using multiple sockets, it starts to generate too many WM's which becomes an issue unto itself - the GUI will begin to freeze and you find yourself implementing multithreading to get around it, then you find you can't associate worker threads with sockets easily using the WM notification method since the threads generally don't own windows... sigh.
Do look at WSAWaitForMultipleEvents (which I ended up using) and WSAGetOverlappedResult (which I've not used yet) and the aforementioned overlapped io based functions.
Event objects and overlapped io are similar in one major respect: both require polling by you, they don't trigger anything by themselves, just flags. The reason why I like the Wait style funcs is that I when I use them in a thread-based socket handler, the thread basically GOES TO SLEEP until an actual network event occurs, then wakes up and handles it. There's almost no cost, and no need to loop, polling on a flag, and no messy WM's to choke the msg queue of the parent app :)
Posted on 2004-02-19 21:51:55 by Homer
Hm, why do you think Events are sucky? If you're going to do threaded coded anyway, they're pretty efficient (while the FD_whatever message passing scales horribly).

Seriously in my opinion, it is better to make it using blocking mode for the login part, because if it is done that way, it is easy to read and understand that part of the code (I might be messed up after a few weeks).

As long as you don't think you can just send(), recv(), parse() - you have to handle incomplete sends and receives, socket errors, etc.
Posted on 2004-02-20 07:21:40 by f0dder