recv() problem, need help!!

Hi,
I'm kind of new for networking programming and need to write some
basic socket connection (in C) using 2 linux machines that do the
following:
The client sends request (query) to the server, then the server needs
to send the query results to the client. So I established the
connection, and the client seems to get the query correctly and send
the results back to the client. The only problem is that the client is
either getting part of the data- when I'm using:
/*********************************************
RECEIVES THE OUTPUT FROM THE SERVER
**********************************************/
strcpy(buf, "");
if ((numbytes=recv(sockfd, buf, MAX-1, 0)) == -1) {
error("recv");
exit(1);
}
buf[numbytes] = '\0';
printf("%s",buf);

or when I'm trying to use a while loop it got stuck forever...:

/*********************************************
RECEIVES THE OUTPUT FROM THE SERVER - loop
**********************************************/
strcpy(buf, "");
while(recv(sockfd, buf, MAX-1, 0) >0) {
printf("%s",buf);
}


as for the server, I'm using:
/**********************************
SENDS THE OUPUT
***********************************/
if (send(new_fd, rdata1, MAX, 0) == -1){
//error
}
close(new_fd);
exit(0);

what is wrong with this? How can I terminate the recv() in such a way
that it should stop after getting all the data back? Any help will be
appreciated.

Thanks.

TCP is streaming so there is no guarantee that the print statement will
print out packets the same way that you sent them. You shouldn't lose
any data, but you might find the lines broken differently.

In article <(E-Mail Removed) .com>,
FLY135 <(E-Mail Removed)> wrote:
>TCP is streaming so there is no guarantee that the print statement will
>print out packets the same way that you sent them. You shouldn't lose
>any data, but you might find the lines broken differently.
>

There is so much wrong with that statement that you were better off
keeping silent. What you probably meant was that it's a buffered
transfer with a block size that might not match the original request, so
received data might not arrive in a single block.

As for the original code,... <sigh> The "loop" example assumes the
recv() request will be satisfied by a null-terminated string. Bad, bad
bad. And please,.. "buffer[0] = '\0'; is SO much better than using
"strcpy(buffer,"");".

--
John Meissen (E-Mail Removed)

(E-Mail Removed) wrote:
> In article <(E-Mail Removed) .com>,
> FLY135 <(E-Mail Removed)> wrote:
>>TCP is streaming so there is no guarantee that the print statement will
>>print out packets the same way that you sent them. You shouldn't lose
>>any data, but you might find the lines broken differently.
>>

> There is so much wrong with that statement that you were better off
> keeping silent. What you probably meant was that it's a buffered
> transfer with a block size that might not match the original request, so
> received data might not arrive in a single block.

However, even if the TCP segment size (aka block) does match the
original request, and one could get lucky, an application programmer
should never work to that, and should indeed treat a TCP connection as
a byte stream and utterly ignore the implementation detail that TCP
sends data in segments. It is quite correct to describe TCP as
providing a byte-stream semantic, and I suspect that is what was meant
to be conveyed by "TCP is streaming"

rick jones
--
firebug n, the idiot who tosses a lit cigarette out his car window
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

(E-Mail Removed) wrote:
> In article <(E-Mail Removed) .com>,
> FLY135 <(E-Mail Removed)> wrote:
> >TCP is streaming so there is no guarantee that the print statement will
> >print out packets the same way that you sent them. You shouldn't lose
> >any data, but you might find the lines broken differently.
> >
>
> There is so much wrong with that statement that you were better off
> keeping silent. What you probably meant was that it's a buffered
> transfer with a block size that might not match the original request, so
> received data might not arrive in a single block.

What's incorrect about FLY135's statement? TCP is indeed streaming.

Steve