why when writting more than once to socket, it blocks?

Question

hi

I am facing a problem with socket and I would be glad if you could help ...
The problem is that when I send data more than once it blocks, e.g:

//--- client ---  
//..
send(sock, buf_1, sizeof(buf_1), 0);  

for (x10){   
//...  
send(sock, buf_2, sizeof(buf_2), 0);    
if (recv(sock, buf_2, sizeof(buf_2), 0)<0) printf("recv_2() failed");   
//...   
}  

for (x20){   
//...  
send(sock, buf_3, sizeof(buf_3), 0);     
if (recv(sock, buf_3, sizeof(buf_3), 0)<0) printf("recv_3() failed");   
//...    
}  
//...          

//--- server---   
//...  
if (recv(sock, buf_1, sizeof(buf_1), 0)<0) printf("recv_1() failed"); 

for (x10){     
if (recv(sock, buf_2, sizeof(buf_2), 0)<0) printf("recv_2() failed");    
//...    
send(sock, buf_2, sizeof(buf_2), 0);     
}     

for (x20){   
if (recv(sock, buf_3, sizeof(buf_3), 0)<0) printf("recv_3() failed");   
//...    
send(sock, buf_3, sizeof(buf_3), 0);     
}     
//...   

the exchange blocks just after the first send(), is there any idea?
Does udp support also multiple sendto()?

Thanks for your answer -

Answer 1

Both send and recv are blocking in this case. You need to set the asynchronous flag ( O_NONBLOCK I think - see docs for fnctl ) on the socket. But this can be tricky to get right. If you dont send/get all the data you have to keep calling send/recv until you've got it all, and doing this efficiently means you're going to have to use the select system call on your sockets.

Now all this is quite feasible, but not much fun and painful to debug. I recommend you try the boost::asio (asynchronous io) library rather than playing with raw sockets. http://www.boost.org/doc/libs/1_41_0/doc/html/boost_asio.html

Answer 2

UDP or TCP?

If TCP; how big is the data that you are sending. What is the client doing? Is the client actually receiving and processing the first block of data? What MAY be happening is that the second send call is blocking because your client's receive window is full and the TCP stacks have engaged in flow control which is causing your synchronous send to block pending the peer reading enough data so that the recv window isn't full and the flow control situation has passed...

• http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Flow_control - TCP flow control

Note also that if you're dealing with TCP then the recv calls CAN and WILL return any number of bytes between 1 and the number of bytes that you have been sent; you should always loop to accumulate the number of bytes that your message framing tells you that you need...

You mention, at the end of your question, about UDP and multiple sendTos, how does this relate to your question? Are you, in fact, using UDP sockets here?