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?

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

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

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.