1. recv() will NOT necessarily receive all the bytes sent in one call. You will have to loop it. Since recv() returns the number of bytes received, what you can do is have the sender always put an integer at the start of each message specifying the length of the message so that the receiver knows when to stop looping for that message. In addition, the same problem exists for the sender - send() is not guaranteed to send all the bytes requested in one call to send(), so you must loop that as well. It is probably best to make functions like recv_all() and send_all() that do this for you automatically so that you don't have to keep writing loops and checking sizes every time you want to send or receive a message.

2. If the client has called recv() and the server closes the socket, the client's recv() will return -1 signifying this. If the server closes the socket and the client tries to send() it will also receive an error. So either way the server can just close the connection and you can program the client to deal with this. You should program the client to handle this situation anyway in the case that the server crashes or something, so that the client doesn't crash as a result.

I do add the length of the message in the start of message, and thats what I want to read in recv (8 bytes)! I was wondering if its really necessary to loop just for 8 bytes.

As far as my interpretation of send( ) in MSDN goes, I believe send will send all the data if it succeeds for blocking, stream oriented sockets, which is what I'm using. The extract from MSDN:

If the connection is closed by the other end (using closesocket), recv returns 0 (indicating a graceful shutdown). I guess the client can interpret that to mean it has been timed out.