Printable View
Hi everybody,
During file receiving via recv(), is there any posibility that data received will lose?
I am trying to receive a bitmap file via recv(), but the bitmap file I received seems to be corrupted and having different file size from original bitmap file, but I am able to receive txt file successfully without file corrupted issue.
Can anybody help me solve this kind of problem?
Sure, post your code so that we can take a look.
Provided that you are sending and recving properly over a TCP connection, there is no chance that the data will be corrupted, missing or arriving out-of-order.
But, you might not receive the data in one block. You need to do consecutively recv's until you know you received all of the data that has been sent to you.
That's right. It is because TCP is a stream protocol and don't preserve message boundaries. We have FAQs on the subject and how to avoid it.
Actually you normally would want an application level protocol to work on top of the TCP/IP protocol stack. That is, you must define a protocol (or implement an already defined protocol) to recognize message boundaries.Quote:
Originally Posted by Mathew Joy
I'll give you some application level protocols:
1) Trivial length prefixed: the first four bytes of every message are always the size of the message body.
2) Trivial with end flag: use some special char sequence (flag) to end the message. Of course, what would happen if that flag appears in the middle of the message? Well, you'll need to define an alternative sequence (escape) and do the following:
a) If a (flag) appears in middle of the message put an (escape) before it.
b) If an (escape) appears in middle of the message put an (escape) before it.
When reading the message read until you receive a (flag) preceded by zero or an even number of (escape) sequences.
Of course this is harder to implement but has no max size limit (in practice I doubt this is worth the effort).
3) HTTP: a real life protocol. If uses a Content-Length: <body size> header, then a "\r\n\r\n" flag and then <body size> bytes of contents.
I hope this clarifies a little.