current community

your communities

more stack exchange communities

Stack Exchange
tour help
careers 2.0
Take the 2-minute tour ×
Stack Overflow is a question and answer site for professional and enthusiast programmers. It's 100% free, no registration required.
up vote 1 down vote favorite

I am developing a simple Client/Server project which moves a chunk of data from client to server. I use TCP/IP.

The server sets up a listening socket and the client connects. First a short 16 byte "header" is transmitted containing some information including the amount of data to be transmitted after. Afterwards the big chunk is transmitted (around 2MB), namely

send( socketDesc, (void *) myBuffer, bigChunkSize, 0 );

and

recv( socketDescPeer, (void *) myBuffer, bigChunkSize, 0 )

First i implemented the client side under windows using winsock2, which works without problems. I now tried to port this implementation to linux, in which case the server side never returns from the recv() call (the "header" however is transmitted correctly). I then tried to send the data in smaller chunks of fixed size like this

unsigned int byteSent = 0;
while( byteSent < bigChunkSize ) {
    int result = send( socketDesc, (void *) myBuffer, smallChunkSize, 0 );
    if ( result < 0 ) {...} else { byteSent += result; }
}

Now, the server receives the first few number of chunks but then again, blocks.

Any ideas? Keep in mind that transmission works without problems using winsock2! Thanks a lot!

share|improve this question
    
Are your sure the header is transmitted correctly, and with this the chunk's size? Is it send in binary format? –  alk Jun 12 at 16:15
    
The header is transmitted as 4 ints. I also tried to hardcode the chunk size. –  madmax1 Jun 12 at 16:20
    
Did you run the code in a debugger, and explicitly observed the call to recv()/read() not returning? –  alk Jun 12 at 16:22
    
However read()/recv() only blocks (on an blocking socket) if nothing is around to be read/received and the sender did not shut down the connection. –  alk Jun 12 at 16:29
    
You need to check for a zero return as well, and break if you get it. At present you will just spin at end of stream. –  EJP Jun 13 at 0:26
add comment

1 Answer 1

up vote 1 down vote

Did you check the return code of send to check, how many bytes were really send? Neither send nor recv are guaranteed to send/receive the given number of bytes. They can handle less and you have to call send/recv again to handle the rest.

So if you actually send less bytes than expected it explains, why the recv will block waiting for more data (which were not send).

share|improve this answer
    
It wouldn't block if all data should be received with one call. It would return then having read as much bytes as there were sent. And if the OP's code does loop around the send(), I do not expect his/her code to loop around the recv(). –  alk Jun 12 at 16:25
    
Yes i checked the return values. For both the and small chunk size the amount if bytes sent is as expected. In the case of small chunks, the first few received chunks before the block also have the correct size. –  madmax1 Jun 12 at 16:27
1  
@madmax1: it's really hard to get from the description, what you are really doing. Please do a small complete example of your problem so that one can analyze it. Given your description of what you do the example would probably small enough to post here. I just guess that the problem lies in code you did not show here. –  Steffen Ullrich Jun 12 at 16:31
    
@alk You are incorrect. recv() isn't obliged to transfer more than one byte, in blocking mode. It makes no attempt to fill the buffer. You have to loop. –  EJP Jun 13 at 0:27
    
@EJP I fully agree and I did not want to express that recv() would block. However it seems I expressed my self unclear, as you might draw from my 2nd comment to the OP. –  alk Jun 13 at 4:44
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.