Recv() return values

[kewlerkid3]

Hello,

This topic has been discussed multiple times but I'm still not understanding something about it.

So I'm receiving data from a source in different chunks and the buffer
I have deals with that nicely but then when all data is received it just
hangs.

My understanding was that recv returns with a -1 when there is no more
data to be read? Can someone help me out?

Thanks.

int leng = 1024;

while(leng!=0)
{

leng = recv(sockfd, buf, 1024-1, 0);

if(leng == 0 || leng == WSAECONNRESET)
{
MessageBox(NULL,"Connection was closed~Exiting",NULL,0);
exit(0);
}

if (leng < 0)
break;

//Output Here

}

[drewdaman]

no.. recv returns -1 on a socket error (as do a lot of winsock functions!), not when it is done...

maybe you should take a look at one of my old posts where i annoyed teh **** out of everyone!
http://www.codeguru.com/forum/showthread.php?t=326558

recv returns the number of bytes that were received. if you know how many bytes to receive, you should use that as an exit condition. so recv in a while loop.. keep incrementing by what is returned by recv and exit the loop when done... here is some sample recv code:


int samplereceivecode(char * data,int bytestorcv){
int nRet=0;
int bytesrecvd=0;

while (bytesrecvd<bytestorcv){
nRet=recv(theClient,data+bytesrecvd,bytestorcv-bytesrecvd,0);
//do error checking here!!

bytesrecvd=bytesrecvd+nRet;
}
return 0;
}

[kewlerkid3]

My problem is i don't know how many bytes i'm going to be receiving.

Any other thoughts?

[drewdaman]

is it a live stream or something? if so.. i have the same problem as you!

if not (and you're sending something "static"- like a file or a data structure), i'm sure you can determine how many bytes you want to send before actually sending, send a single packet (of a pre-determined number of bytes) to the receiving end with teh length of the data it should expect. that's how i'm dealing with file transfers...

actually, if even if it is a live stream, you could probably send the size of each frame or whatever unit before actually sending the data... i'm not sure if this is the best way.. but it is one way for sure!

[kewlerkid3]

It is live stream and I never know how large the data will be exactly as I'm not controlling what the server sends me.

My only hunch is to use select() and check to see if data is still waiting to be received.

But i don't exactly understand how that function works.

[kewlerkid3]

Got it working using a simple time out with select();

See Andreas Masur's post:

http://www.codeguru.com/forum/showthread.php?t=321860&highlight=SO_RCVTIMEO

[drewdaman]

yeah.. i think select might work too! but don't ask me about it! its something i have avoided for a long time (sorry gurus!)!! i aksed the exact same question in a recent post of mine.... tho i'm sure i will have to use select sooner or later... probably quite soon!

[kewlerkid3]

yeah.. i think select might work too! but don't ask me about it! its something i have avoided for a long time (sorry gurus!)!! i aksed the exact same question in a recent post of mine.... tho i'm sure i will have to use select sooner or later... probably quite soon!

Like many things, its easy once you first use it and begin to understand it.

[RichJGould77]

I have a similar problem, although slightly reversed.

My call to recv() returns -1 instantly, even before I have sent any data from the client to the server through the socket.
But when I call WSAGetLastError() that returns 0, which leads me to think that nothing has gone wrong.

I am confused. I have not specified a non-blocking socket, so I would have not expected it to return until the client has sent data.

Can anyone help thie newbie out??

[MikeAThon]

...My call to recv() returns -1 instantly, even before I have sent any data from the client to the server through the socket. But when I call WSAGetLastError() that returns 0, which leads me to think that nothing has gone wrong....
Do you call WSAGetLastError() immediately after the call to recv()? WSAGetLastError() is a global function, so the placement of the call sometimes makes a difference.

Mike