A couple of questions:

[miteshpandey]

Question No.1
I have included the winsock2.h file but i am still getting some compile errors.
I assume that these errors are because I have not included the Ws2_32.lib file.
I am using Vicual C++ 7.0. I could not find where to include the Ws2_32.lib file.
Can somebody explain how to do this.

Question No.2
How to create a non-blocking(asynchronous) socket.

When I use (socket(...)) or (WSASocket(...)) this function to create a socket I do not see parameters to specify if the socket is blocking or non-blocking.

Question No.3
what's the difference betwen using the two sets of functions:

socket(...) WSAcounterpart
accept(...) ""
recv(...) ""
send(...) ""
select(...) ""
etc..

[kuphryn]

The last parameter of WSASocket() allows you to pass in the socket's attribute. An overlapped flag indicates a non-blocking socket.

Kuphryn

[MikeAThon]

For Question 1, are you getting compile errors or link errors. Failure to link to a .lib file might cause a link error, but it would not cause compile errors.

For Question 2, in addition to what Kuphryn said, look at the WSAIoctl() and/or ioctlsocket() functions.

Mike

[Mathew Joy]

Question No.2
How to create a non-blocking(asynchronous) socket.blocking/non-blocking is one thing, synchronous/asynchronous is another thing. The former is related to the socket while the latter is related to IO. Hence it is perfectly possible to use blocking socket for asynchronous IO.

As for the second part or the qestion,

DWORD ul=1;
ret=ioctlsocket(cliSock,FIONBIO,&ul);
if(ret== SOCKET_ERROR)
{
//handle the error
}

Question No.3
what's the difference betwen using the two sets of functions:

socket(...) WSAcounterpart
accept(...) ""
recv(...) ""
send(...) ""
select(...) ""This basically attains two thing. One is the naming convention and the other is a migration to a newer version of Winsock. Naming convention (WinSock API) is what we see in GetLastError() and WSAGetLastError(). Both the same; Internally WSAGetLastError() is mapped to GetLastError(). Similarly recv() and WSARecv(), you can do just the same thing. Here internally, recv() is mapped to WSARecv(). So when the new Winsock version arrived, recv() is kept for compatibility and easier migrance from BSD style code to that of Winsock.

Additionally, there are lots of new thing you can do with Winsock2; the WSAXX() varient. Ranging for just a few additional parameters to complex, highly efficient kernel mode calls.

[Mathew Joy]

An overlapped flag indicates a non-blocking socket.This is absolutely wrong!! Overlapped flag means you can do overlapped IO using the socket and has nothing to do with blocking or non-blocking.

[miteshpandey]

Mathew Joy blocking/non-blocking is one thing, synchronous/asynchronous is another thing. The former is related to the socket while the latter is related to IO. Hence it is perfectly possible to use blocking socket for asynchronous IO.

Thank you very much for resolving a great mis-conception of mine.

The mis-conception is not completely resolved since I am tempted to ask the following question:

For blocking sockets is it safe to assume that that all the data of the buffer specified by the buffer length in calls to function recv(...) and send(...) will be received or sent repectively in one go?

In other words do I have to check the length byte returned by recv(...) and send(...) functions to know if the total length of the packet is either received or sent respectively?

As regarding my question No. 1, the errors I was receiving were link errors and it is solved now.

[Mathew Joy]

For blocking sockets is it safe to assume that that all the data of the buffer specified by the buffer length in calls to function recv(...) and send(...) will be received or sent repectively in one go? Again this behavior has nothing to do blocking/non-blocking sockets. This behavior is attributed to the fact that TCP is a a stream based protocol; it does not preserver message boundaries. We have detailed discussion of the above question in the folowing faq.

Does one call to 'send()' result in one call to 'recv()'? (http://www.codeguru.com/forum/showthread.php?s=&threadid=296198)

When does 'send()' return? (http://www.codeguru.com/forum/showthread.php?s=&threadid=296875)

When does 'recv()' return? (http://www.codeguru.com/forum/showthread.php?t=303078)
Because of the above behavior, it is usually necessary to build a packet over the TCP. You can find one method in the folowing faq

How do I impose a packet scheme? (http://www.codeguru.com/forum/showthread.php?t=306399)

[kuphryn]

Technically, ioctlsocket() sets the socket's blocking mode. In practice, setting the socket's attribute to overlapping is non-blocking mode.

Kuphryn

[miteshpandey]

Thank for the links provided. I went throught all the articles in the link and also in MSDN but I am still confused.

The following statements from MSDN is misleading me.

MSDNIf no error occurs, send returns the total number of bytes sent, which can be less than the number indicated by len for nonblocking sockets.

MSDNOn nonblocking stream oriented sockets, the number of bytes written can be between 1 and the requested length, depending on buffer availability on both client and server computers.

From the above two statements I imply that blocking sockets only return when all the bytes specifed by the buffer length is sent. The return value equals the buffer length.

My head's going in circles. Please help.

[kuphryn]

Socket takes time to familiarize with, so keep at it.

Kuphryn

[Mathew Joy]

Technically, ioctlsocket() sets the socket's blocking mode.This is true both in theory and pactice. In practice, setting the socket's attribute to overlapping is non-blocking mode.Setting a socket's attribute to overlapping does not make it non-blocking. You can verify it by yourself. However there are other methods than using ioctlsocket() call explicitly, to make it non-blocking. If you are using non-blocking socket for accept() then the returned socket will also be non-blocking. Also functions like WSAAsyncSelect() and WSAEventSelect() sets the socket to non-blocking automatically. A socket created with socket() has the WSA_FLAG_OVERLAPPED implied.

[Mathew Joy]

From the above two statements I imply that blocking sockets only return when all the bytes specifed by the buffer length is sent. The return value equals the buffer length.Apart from the above quoted from the MSDN we have For nonoverlapped sockets, the last two parameters (lpOverlapped, lpCompletionRoutine) are ignored and WSASend adopts the same blocking semantics as send. Data is copied from the supplied buffer(s) into the transport's buffer. If the socket is nonblocking and stream oriented, and there is not sufficient space in the transport's buffer, WSASend will return with only part of the application's buffers having been consumed. Given the same buffer situation and a blocking socket, WSASend will block until all of the application's buffer contents have been consumed.So going according to MSDN it seems safe to assume that all the data will be sent in the case of blocking sockets(Not for recv). But experts, including those who were involved in writing Winsock spec for windows, say it is better and safe to look at the return value to see if all of the data has been send. Probabaly it may have something to do with the intermediate layer, that can be inserted by third party SW, between the winsock dll and the actual base provider. OK let me see if any further reference can be obtained.

Meanwhile...Expert comments about blocking send (http://tangentsoft.net/wskfaq/ARTICLES/lame-list.html)
Quoting from the above link
This means that with any call to send() or recv(), the Winsock implementation may transfer any number of bytes less than the buffer length specified. and Whether you use a blocking or non-blocking socket, on success you should always compare the return from send() or recv() with the value you expected.
Anyway, it is not hard (not much complexities) to check if send() has send the expected no of bytes. So my suggestion is check.