res = recv(current_client,buf,sizeof(buf),0); // recv cmds
if(res == 0)
The data that you're waiting for in the second recv() could have turned up in the first recv() and may be already be in buf. In fact, that's likely unless sizeof(buf) is the exact length of fixed length commands (which I don't think is the case).
Also, recv() can fail and return -1.
And finally, why wait for 10ms before handling the error case?
sizeof does work, you're just not using it correctly. When you say sizeof(buf) you get either 4 (you're using a char pointer), or you get the entire size of the array 'buf'. You declared buf to be size 100, so sizeof(buf) = 100. So you're going to receive up to 100 bytes with that call of recv. As kbw mentioned, you're likely receiving title information in buf on your first call to recv.
Picture this scenario:
Client send: "mib SomeTitle"
Server recv 100 bytes in buf: "mib SomeTitle" <-- because you used sizeof(buf)
Server: finds "mib" in array 'buf'
Server: tries to recv title; no information in queue to recv.
When you tell a socket to recv 100 bytes, it's going to read everything in the queue up to 100 bytes. It can fall shorter, but not larger than that amount.
You need to either A: make all of your commands a uniform length, or B: loop and receive one byte at a time and break when you receive a white space. (not sure how efficient that will be,) or C: (my favorite) just search for the title in buf, and don't worry about calling recv again.
If you're trying to output the full length of the array, you're going to get weird characters because there are empty space-holders for characters you didn't receive, so they just take on whatever value was already in that memory space. Try using the function ZeroMemory(Destination, length) on the buffers to write zeroes to all the memory it holds before you receive anything into them. That should eliminate your weird character problem. http://msdn.microsoft.com/en-us/library/windows/desktop/aa366920(v=vs.85).aspx
You're not checking your return codes from send() and recv().
You should realise that the number of send() calls does not match the number of recv() calls. What matters is the amount of data transfered.
It is entirely possible for all those small sends to be read by a single recv() call, so both sides have to agree on what is sent, how much is sent and when it's sent (that's call a protocol). The number of send/recv calls doesn't really matter.