Click here to Skip to main content
13,141,576 members (50,748 online)
Rate this:
Please Sign up or sign in to vote.
See more:

I am bit confused about following lines from MSDN to related connect API:

"With a nonblocking socket, the connection attempt cannot be completed immediately. In this case, connect will return SOCKET_ERROR"

I have following doubt
1) If connect is not able to make connection than it will immediately return error SOCKET_ERROR or after some time?

2)How can I know that it is blocking or non blocking call?

Posted 3-Dec-10 9:41am
Espen Harlinn 5-Jan-11 7:45am
You could probably benefit from using a framework like ACE:

This is an open source project with e very liberal license. It's used by many demanding projects:

Good luck
Rate this: bad
Please Sign up or sign in to vote.

Solution 2

You can decide if you want to use the socket as blocking, or nonblocking. Here is the code that switches between the 2 modes:
inline bool SetSocketBlocking(SOCKET sock, bool blocking)
    unsigned long nonblocking_long = blocking ? 0 : 1;
    if (ioctlsocket(sock, FIONBIO, &nonblocking_long) == SOCKET_ERROR)
        return false;
    return true;

If you use 1 listener/accepter thread in your server program and 1 thread per client with simple protocol, then its much easier to use blocking sockets I think. If you want an IO model where there are no threads per client but rather there is a "reactor" design pattern implementation where 1 thread (or sometimes more) serves a lot of sockets, then its easier to use non-blocking sockets.
For blocking sockets all recv/send/connect/accept operations are blocking until the operation either failes or succeeds. For nonblocking sockets its more complicated, but none of the previously mentioned functions block. With nonblocking sockets you usually do the read/write operations by waiting for sockets to become readable or writeable by using APIs like the crossplatform select() method, or the windows specific WSAEventSelect() or some IO completion ports if you want an MMO server. :) For example if the socket becomes writeable you call send() on it, and send() will return how many bytes was it able to write out. If it was able to write all bytes, you can call it again until it returns with error. In case of an error you have to check WSAGetLastError() if its WSAEWOULDBLOCK, because it means that this isn't really an error, only the send buffer of the socket (within the OS) is full, and you should wait again for the socket to become writeable. You have to check for this with almost every socket operations in case of nonblocking sockets. Connecting and accepting are also returning immediately with nonblocking sockets. In case of connection you have to wait for the socket to become writeable with select() (if you use the berkeley API) to detect when the connection becomes complete, or it will return with an exception flag set from select() in case of error. Or you can use the windows specific WSAEventSelect() that has a specific flag for connection detection. Same with accept, you have to wait for the listen socket to become readable with select(), or if you prefer windows specific API then WSAEventSelect() has special flags for testing the "accept ready" state. Maybe the select() is easier to use for the first time that the other APIs, and its also cross-platform.

Socket programming/debugging can become very-very complicated... Good luck, and ask again is something isn't clear or goes wrong! :D
Vishal Kumar Soni 4-Dec-10 2:06am
Thanks very much pasztorpisti for such a detail reply but if I dont call SetSocketBlocking before connect than by default it will be blocking or non blocking like in following code:
socket = socket( family, sockType, protoType );
if( m_socket == INVALID_SOCKET )

throw exception;

address.sin_family = family;
address.sin_port = port;
address.sin_addr.s_addr = address;

if( sockType == SOCK_STREAM || SOCK_DGRAM == sockType && IPPROTO_UDP == protoType )
// Establishes a connection to a specified socket.
if( connect( m_socket,m_address, sizeof( m_address ) ) == SOCKET_ERROR )
throw exception;
pasztorpisti 4-Dec-10 3:47am
Its blocking by default, so connect will block. Its a good practice to memset(&address, 0, sizeof(address)) before filling it especially if you are making crossplatform prog.
Espen Harlinn 5-Jan-11 7:40am
5+ Good answer
Vishal Kumar Soni 6-Jan-11 0:18am
Thanks pasztorpisti!

Rate this: bad
Please Sign up or sign in to vote.

Solution 1

1. The connect (of a non blocking socket) should return immediately.
2. When the connect fails with SOCKET_ERROR, you may call WSAGetLastError function, it will return WSAEWOULDBLOCK for non-blocking sockets.
Vishal Kumar Soni 4-Dec-10 2:01am
Thanks Cpallini

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
Top Experts
Last 24hrsThis month

Advertise | Privacy |
Web04 | 2.8.170915.1 | Last Updated 5 Jan 2011
Copyright © CodeProject, 1999-2017
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100