Winsock blocking/non-blocking modes

I have some sample code written using the Winsock API which is 'connect'ing using non-blocking mode, but is then in blocking mode for all 'send' and 'recv' calls.

I am not very familiar with Winsock and am just wondering why the programmer has done this? Why not use either blocking or non-blocking mode the whole way through?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Initially, he intended to write a non-blocked code. But then, after hard work on 'connect'ing, he decided to make his life easier and switched to blocked sockets.
I think it could be becouse "connect" probably takes longer than send or receive.
MichaelS is probably right.  "connect" can even take an entire minute.  For example I have a program that is making a local connection, in another words both the server socket and the client socket are on the same machine; on one computer it takes just over 30 seconds and on another under 2 seconds.  You can see that if something is going to take 30 seconds and possible more a user may think the program is hung if it were in blocking mode.  By making it non-blocking repainting the window and other activities can continue thus assuring the user that the app is fine.  Making "send" and "recv" blocking probably works just fine as long as the connection is being made across a local network.  If the connection is actually across the internet where it might take a long time for the data to actually get from the send socket to the recv socket then again the user may feel the program is hung.  Alternativly even if the connection is local but a transaction may take time blocking may again give the appearance of begin hung.  What I mean by this is for example the client sends something to the server and then immediatly does a recv waiting for the server to respond.  But if the server is busy handling other requests and takes some time to respond the client will appear hung.
This all of course assumes that the thread handling the socket is the main thread handling the GUI.  Other than that it's being a bit lazy because if something gets hung up in a blocked call you can't gracefully quit.
Cloud Class® Course: MCSA MCSE Windows Server 2012

This course teaches how to install and configure Windows Server 2012 R2.  It is the first step on your path to becoming a Microsoft Certified Solutions Expert (MCSE).

Are you really serious?

Take a look on your explorer. Connect takes few seconds may be, but downloading of the page/file (recv/send)takes sometime hours!
paulburnsAuthor Commented:
thanks for the replies.

So will there be any problems with this design? i.e can the send and recv calls block indefinitely?

Basically i need to know this... in a very simple TCP/IP application (send some data, wait for an acknowledgement code, repeat until no more data to send) operating over a LAN which is the more appropriate to use; blocking or non-blocking?

recv/send will not block forever, but they can take some time to complete.

Suppose, you write GUI program (windows, etc). If you will use the blocking sockets, you program will stop responding while blocking calls (user will not be able to move window, open menus, window will not reapint itself...). Even if blocking call will take 0,5 sec it's annoying enough.

But blocking sockets are simpler to use.

Use can use blocking sockets with GUI if you will perform socket i/o in a separate (second) thread. First (primary) thread will handle GUI, and user will not notice any delay.

If your program has no UI, use blocking sockets.
If your program has UI (user interface) and has 1 thread only, use non-blocked sockets.
If your program has several threads, you can use both types, but move blocking calls to a separate thread.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
paulburnsAuthor Commented:
ok, you can have the points, but could you clear up one last thing - if i am a client and call recv (in blocking mode) but the server never responds will recv eventually return?, and what determines the time-out?
If you specify, say, 10 bytes to read, but server sent only 9, then recv() will block until all data is received or until connection exists.
In this case recv() will block "forever".

You can set timeout for recv (if I'm not wrong, it works on WinSock2):

SOCKET socket;
int timeout = 1000;   // Desired timeout in milliseconds
   retval = setsockopt (socket,

I never used blocked connect(), but it seems there is no way to specify a timeout (I'm not 100% sure). Anyway, you can write your program as unknown programmer from your original question does - non-blocking connect() and blocking others.
Answer to NickRepin,

Yes I'm serious.  Even though downloading a file may take hours, I can't beleive any programmer would try to send or receive the entire file in one send and recv.  Instead the calls to send and recv probably use anywhere between 256bytes to 1024bytes at a time, maybe more; but I very serously doubt anyone would use somthing like 16MB or something.

Also if you use blocking sockets in a non-GUI thread or application you can't gracefully tell the thread to terminate, unless you use a timeout, but even then your program will have to wait for that time out and then check if the thread is to be terminated.
<<probably use anywhere between 256bytes to 1024bytes>>

Sure, but anyway you have to pump GUI messages between calls to recv(). And anyway even 256 bytes can take significant (for GUI) time on a slow connection.

With blocking sockets, you can use WSACancelBlockingCall from the primary thread to terminate the socket thread.

Of course, I don't suggest to use blocking sockets. I'm talking about the possibility to use them.

As to me, I use non-blocked sockets for Winsock1 and overlapped for Winsock2.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Development

From novice to tech pro — start learning today.