To make a socket as non-blocking socket:
u_long cmd_option = 1; //Non-blocking socket.
//Set socket in non-blocking mode
ioctlsocket(mastersd, FIONBIO, &cmd_option);
// rest of your code...
Then socket will be in non-blocking mode and the recv will return
immediatly by reading the available data in the socket at that
particular time.
I think you are calling select with a timeout value. If you are passing
NULL then it will be a blocking socket.
Also please check this: http://tangentsoft.net/wskfaq/newbie.html
This is from Internet I will paste the relevant portion here.
How can I change the timeout for a Winsock function?
Some of the blocking Winsock functions (e.g. connect()) have a timeout
embedded into them. The theory behind this is that only the stack has
all the information necessary to set a proper timeout. Yet, some people
find that the value the stack uses is too long for their application; it
can be a minute or longer.
Under Winsock 2, you can set the SO_SNDTIMEO and SO_RCVTIMEO options
with setsockopt() to change the timeouts for send() and recv().
Unfortunately, the Winsock spec does not document a way to change many
other timeout values, and the above advice doesn't apply to Winsock 1.1.
The solution is to avoid blocking sockets altogether. All of the
non-blocking socket methods lend themselves to timeouts:
* Non-blocking sockets with select() The fifth parameter to the
select() function is a timeout value.
* Asynchronous sockets Use the Windows API SetTimer().
* Event objects WSAWaitForMultipleEvents() has a timeout parameter.
* Waitable Timers These are a new feature in Windows 98 and NT 4.0
SP3 and higher. A waitable timer is an object like a semaphore, except
that the OS signals it at a future time that you specify. You create
them with the Win32 function CreateWaitableTimers(). So, you could wait
on a 5-second timer as well as your event objects; if nothing happens on
the sockets within 5 seconds, Windows will signal the timer, thus
breaking you out of the WaitForMultipleObjects() call.
Note that with asynchronous and non-blocking sockets, you may be able to
avoid handling timeouts altogether. Your program continues working even
while Winsock is busy. So, you can leave it up to the user to cancel an
operation that's taking too long, or just let Winsock's natural timeout
expire rather than taking over this functionality in your code.
Cheers
Sreeram
Post by Chris CooperHere's what I'm doing. I call select() until there is data available for
reading, and then call recv() to get a small chunk of data (max 16k). If
recv() didn't return zero (which would indicate that the socket is closed) I
go back and call select() again. I can go through this loop hundreds of
times without problems, but if the total time the socket is receiving data
is more than 30 seconds, recv() returns zero even though there is more data
to be read.
What's strange, is that it's not that any single call is taking more than 30
seconds, it's if the total duration of the receive takes more than 30
seconds.
I'm assuming that by calling select() first, it's effectively a non-blocking
socket?
Post by SreeramAre you using WinSock 2? SO_SNDTIMEO and SO_RCVTIMEO options are
available in Winsock 2.
or you can make it a as a non-blocking socket and do the timeout
calculation manually instead of using this SetSockOpt function.
Sreeram
Post by Chris CooperI'm using Windows sockets to connect to a web site and download a file
via
Post by SreeramPost by Chris CooperHTTP. All works beautifully until I try to download a file that is
large
Post by SreeramPost by Chris Cooper(4M). The socket times out after 30 seconds, even though all of the
data is
Post by SreeramPost by Chris Cooperstill flowing.
I tried setting the SO_RCVTIMEO and SO_SNDTIMEO options to large
numbers,
Post by SreeramPost by Chris Cooperand it seemed to work (setsockopt returned 0 and getsockopt returned the
value I had just passed it) but the socket still closes itself after 30
seconds.
Is there another timeout value somewhere I need to set?
Thanks!
Chris