Archived

This topic is now archived and is closed to further replies.

recv

This topic is 5540 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Lets say that I''m connection to a HTTP server (using TCP) to retrieve say a jpg file. The server will send out that data to me and I have to call recv to get it. How do I know that I got it all? That is, does the TCP standard guarantee that I will recieve all my data in one call or will I have to assemble it on my end? Like, is it possible for it to send me 4k of a 500k file, and then 5 seconds later, receive another 4k or so? If so, how do I know that I got the whole file without knowing the file formats of everything that I''m downloading?

Share this post


Link to post
Share on other sites
Good question. I want to know the correct answer too. My thought right now is that you do not know about the status of file completion. I believe when a send is done, the server will send a notice at the end of the data. Maybe there is a "\n\n0" at the end of the buffer.

Kuphryn

Share this post


Link to post
Share on other sites
I am pretty sure TCP/IP takes care of all this for you. If you send a file larger than the tcp packet can hold, it automatically breaks it down into more than one packet, send it to the ip, and then constructs it based on the number assigned to the packet.

I think that if you send a large buffer of data and tcp automaticaly breaks it down for you, then you do not have to reconstuct the data yourself, recv will take care of it all.

To even go farther in my hypothesis, recv waits till it recives something like "\n\0" before being complete, the returns its value when it is garenteed done.


I may be wrong however

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
You are wrong
recv() is stream-based and will just return anything that''s in the buffer when you call it. This means you absolutely need to have rules to deal with reconstructing data you are receiving.
In general, it is a good idea to send the size of the file you are sending before you send the actual file so you know how much you are getting. If you''re working with an established protocol, things may be different. I don''t know much about hTTP protocol etc. so i can''t help much there.

Share this post


Link to post
Share on other sites
Hi,

Basically with http it sends all the data and then closes the connection, so you just keep reading data into the buffer untill its closed

you know when the connection is closed because you will have a recv call return 0 bytes read (If you are using non blocking recv calls then you 1st need to check if the socket is ready to recv or it will return 0 data read just because it wasnt ready)

Share this post


Link to post
Share on other sites