|
Home > Archive > Unix Programming > February 2007 > Trouble sending binary data over Sockets (using C)
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Trouble sending binary data over Sockets (using C)
|
|
| ashish.lohra@gmail.com 2007-02-07, 7:23 pm |
| Hi,
I'm new to unix programming and am trying to create a file transfer
application. The server reads binary data and sends it over to the
client when file download is requested. My problem is that the data
gets through to the client but when I take a look at the file it comes
across garbled. Eg. See the *.java file below:
<REP GET BEGIN>
< OP61Prec3
Diriteclnterr plen\365\270^B^Y^\\377\377\377\273FDSGR~
\376\376\377\201^A^A\377\377\377<REP GET BEGIN>
< OP61Prec3
=============================
On server side:
I'm using an integer array and fread() to read the data from the file
and send() to send the data to client.
On client side:
Again I'm using recv() and integer array to receive the data from the
server and fwrite() to write to a file.
And the file on client side shows up garbled as I showed above.
Please help.
Thanks.
| |
| Jens Thoms Toerring 2007-02-07, 7:23 pm |
| ashish.lohra@gmail.com wrote:
> I'm new to unix programming and am trying to create a file transfer
> application. The server reads binary data and sends it over to the
> client when file download is requested. My problem is that the data
> gets through to the client but when I take a look at the file it comes
> across garbled. Eg. See the *.java file below:
> <REP GET BEGIN>
> < OP61Prec3
> Diriteclnterr plen\365\270^B^Y^\\377\377\377\273FDSGR~
> \376\376\377\201^A^A\377\377\377<REP GET BEGIN>
> < OP61Prec3
> =============================
> On server side:
> I'm using an integer array and fread() to read the data from the file
> and send() to send the data to client.
> On client side:
> Again I'm using recv() and integer array to receive the data from the
> server and fwrite() to write to a file.
> And the file on client side shows up garbled as I showed above.
Not much information to go by - posting the code itself instead of
some rough description might be better. First question: why do you
use an integer array instead of an (insigned char) array? That seems
to be strange. And are you sure that you use the return value of
recv() correctly? It's the number of bytes that you've received,
not the number of integers.
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
| |
| ashish.lohra@gmail.com 2007-02-07, 7:23 pm |
| On Feb 7, 4:25 pm, j...@toerring.de (Jens Thoms Toerring) wrote:
> ashish.lo...@gmail.com wrote:
>
> Not much information to go by - posting the code itself instead of
> some rough description might be better. First question: why do you
> use an integer array instead of an (insigned char) array? That seems
> to be strange. And are you sure that you use the return value of
> recv() correctly? It's the number of bytes that you've received,
> not the number of integers.
> Regards, Jens
> --
> \ Jens Thoms Toerring ___ j...@toerring.de
> \__________________________ http://toerring.de- Hide quoted text -
>
> - Show quoted text -
I earlier was using char array to send over the data and the
application was only able to send .txt, .java .c etc. files. When I
tried sending over jpg or binary or compressed files then it wouldn't
work.
The recv() is working correctly as it returns the number of bytes.
My basic problem is I want to transfer all types of files.
| |
| Pascal Bourguignon 2007-02-07, 7:23 pm |
| ashish.lohra@gmail.com writes:
> I earlier was using char array to send over the data and the
> application was only able to send .txt, .java .c etc. files. When I
> tried sending over jpg or binary or compressed files then it wouldn't
> work.
>
> The recv() is working correctly as it returns the number of bytes.
In C, char is an integer type, so it makes no difference.
Well, if you used a wider integer type, you might get bytesex errors,
but you'd still see the ASCII characters on the other side, only in a
different order.
You could try to use tcpdump to see what's transmitted "on the line".
tcpdump -X -s 4096 port $YOUR_PORT
(or use a bigger size if you use bigger packets).
--
__Pascal Bourguignon__ http://www.informatimago.com/
WARNING: This product warps space and time in its vicinity.
| |
| ashish.lohra@gmail.com 2007-02-07, 7:23 pm |
| Ok I switched back to unsigned char array and again I'm being able to
send *.txt,*.java,*.c etc files ok
For files like *.jpg *.jar etc the data is being sent over but for
some reason it is not being able to send the whole file. Also, when I
open the file I received it look like having content like:
\377\377\377\273FDSGR~
\376\376\377\201^A^A\377\377\377
Why is that happening? Please note that I'm using vi editor.
Any clues why it stops before sending over the whole file?
> In C, char is an integer type, so it makes no difference.
>
> Well, if you used a wider integer type, you might get bytesex errors,
> but you'd still see the ASCII characters on the other side, only in a
> different order.
>
> You could try to use tcpdump to see what's transmitted "on the line".
>
> tcpdump -X -s 4096 port $YOUR_PORT
>
> (or use a bigger size if you use bigger packets).
>
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
>
> WARNING: This product warps space and time in its vicinity.
| |
| Pascal Bourguignon 2007-02-07, 7:23 pm |
| ashish.lohra@gmail.com writes:
> Ok I switched back to unsigned char array and again I'm being able to
> send *.txt,*.java,*.c etc files ok
>
> For files like *.jpg *.jar etc the data is being sent over but for
> some reason it is not being able to send the whole file. Also, when I
> open the file I received it look like having content like:
> \377\377\377\273FDSGR~
> \376\376\377\201^A^A\377\377\377
> Why is that happening? Please note that I'm using vi editor.
>
> Any clues why it stops before sending over the whole file?
No, you're not giving us any clue.
Are you using TCP or UDP?
--
__Pascal Bourguignon__ http://www.informatimago.com/
ATTENTION: Despite any other listing of product contents found
herein, the consumer is advised that, in actuality, this product
consists of 99.9999999999% empty space.
| |
| ashish.lohra@gmail.com 2007-02-07, 7:23 pm |
| I'm using TCP. I tired to use the tcpdump command but I don't have
appropriate permissions for that.
Also, I tried transmitting *.gif file. It is total 3580 bytes. Out of
whihc server is only ebing able to send 2898 and the client receives
1642 bytes.
So I'm trying to see why the whole thing is not getting transmitted
from the server side.
I use recv() and send() to receive and send data and unsigned char
array.
Please advise if possible.
On Feb 7, 6:47 pm, Pascal Bourguignon <p...@informatimago.com> wrote:
> ashish.lo...@gmail.com writes:
>
>
>
> No, you're not giving us any clue.
>
> Are you using TCP or UDP?
>
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
>
> ATTENTION: Despite any other listing of product contents found
> herein, the consumer is advised that, in actuality, this product
> consists of 99.9999999999% empty space.
| |
| Pascal Bourguignon 2007-02-07, 7:23 pm |
| ashish.lohra@gmail.com writes:
> I'm using TCP. I tired to use the tcpdump command but I don't have
> appropriate permissions for that.
It might be a good idea to debug your programs on a system where you
have root access. A solution could be user-mode-linux or Qemu.
> Also, I tried transmitting *.gif file. It is total 3580 bytes. Out of
> whihc server is only ebing able to send 2898 and the client receives
> 1642 bytes.
What do you mean by "the server is only able to send 2898 bytes"?
> So I'm trying to see why the whole thing is not getting transmitted
> from the server side.
>
> I use recv() and send() to receive and send data and unsigned char
> array.
>
> Please advise if possible.
I'd read again man 2 recv and man 2 send
in particular, the RETURN VALUE and the ERRORS sections.
You could make use of perror(3).
--
__Pascal Bourguignon__ http://www.informatimago.com/
ATTENTION: Despite any other listing of product contents found
herein, the consumer is advised that, in actuality, this product
consists of 99.9999999999% empty space.
| |
| Christopher Layne 2007-02-08, 1:29 am |
| ashish.lohra@gmail.com wrote:
> I'm using TCP. I tired to use the tcpdump command but I don't have
> appropriate permissions for that.
>
> Also, I tried transmitting *.gif file. It is total 3580 bytes. Out of
> whihc server is only ebing able to send 2898 and the client receives
> 1642 bytes.
>
> So I'm trying to see why the whole thing is not getting transmitted
> from the server side.
>
> I use recv() and send() to receive and send data and unsigned char
> array.
In regards to your integer issue:
man ntohl
man ntohs
man htonl
man htons
| |
| Loic Domaigne 2007-02-08, 7:21 am |
| Hello,
> I'm using TCP. I tired to use the tcpdump command but I don't have
> appropriate permissions for that.
>
> Also, I tried transmitting *.gif file. It is total 3580 bytes. Out of
> whihc server is only ebing able to send 2898 and the client receives
> 1642 bytes.
>
> So I'm trying to see why the whole thing is not getting transmitted
> from the server side.
>
> I use recv() and send() to receive and send data and unsigned char
> array.
>
> Please advise if possible.
Is the platform architecture where your client and your server run
exactly the same? I mean, same endianess, etc?
You may need to use XDR or roll you own data exchange protocol using
the ntoh* / hton* functions as mentioned by another poster.
HTH,
Loic.
| |
| Jens Thoms Toerring 2007-02-08, 7:21 am |
| ashish.lohra@gmail.com wrote:
> I earlier was using char array to send over the data and the
> application was only able to send .txt, .java .c etc. files. When I
> tried sending over jpg or binary or compressed files then it wouldn't
> work.
> The recv() is working correctly as it returns the number of bytes.
> My basic problem is I want to transfer all types of files.
Do us and yourself a favor and provide some source code. Without
it everything anyone here can answer is idle speculations which
probably won't really help you. There are literally hundreds of
ways you could have screwed up. You could make mistakes in de-
termining the length of the file, you could make mistakes in
reading in the file, including using memory you don't own, you
could make mistakes in sending the data (by the way, how do you
tell the other side how many bytes it got to expect?), you could
not check the return value of send() if the socket is in non-
blocking mode etc. And on the receiving side there might be a
similar amount of errors. You definitely are not providing enough
information to guess what might be going wrong. And your messing
around using an int array instead of a char array just to cure
some symptoms but not really understanding why it then "works"
looks suspiciously as if there could be a number of unresolved
problems.
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
| |
| Tarkin 2007-02-09, 1:32 am |
| On Feb 8, 3:31 am, "Loic Domaigne" <loic-...@gmx.net> wrote:
> Hello,
>
>
>
>
>
>
> Is the platform architecture where your client and your server run
> exactly the same? I mean, same endianess, etc?
>
> You may need to use XDR or roll you own data exchange protocol using
> the ntoh* / hton* functions as mentioned by another poster.
>
> HTH,
> Loic.
Or base64 encoding, as the OP has no problems
with text.
HTH,
Tarkin
| |
| Christopher Layne 2007-02-09, 7:20 am |
| Tarkin wrote:
> Or base64 encoding, as the OP has no problems
> with text.
>
> HTH,
> Tarkin
base64 to send binary data because the OP cannot figure out how to send binary
data portably? Yeah, that's efficient.
Use the right way the first time.
| |
| Tarkin 2007-02-10, 7:23 am |
| On Feb 9, 7:33 am, Christopher Layne <cla...@com.anodized> wrote:
> Tarkin wrote:
>
>
> base64 to send binary data because the OP cannot figure out how to send binary
> data portably? Yeah, that's efficient.
>
> Use the right way the first time.
Yes, thank you. Especially if he
has to meet a deadline or fulfill a
requirement. As long as it's properly
documented and commented, it
can be reworked later. If it needs
to work now, wrap it; If not, I'm
sure Google will be his friend.
Efficiency is generally a measure
of the most amount of output with
the least amount of input or effort.
'Use the right way the first time'
is a more of a statement on
accuracy. When you can
be efficient *and* accurate-
well, then they offer you
management, don't they?
TTFN,
Stevo
| |
| Christopher Layne 2007-02-10, 7:18 pm |
| Tarkin wrote:
> On Feb 9, 7:33 am, Christopher Layne <cla...@com.anodized> wrote:
>
> Yes, thank you. Especially if he
> has to meet a deadline or fulfill a
> requirement. As long as it's properly
> documented and commented, it
> can be reworked later. If it needs
But we know it will never be reworked later once he sells his soul to the
deadline devil.
> Efficiency is generally a measure
> of the most amount of output with
> the least amount of input or effort.
Then base2 should be the most "efficient" implementation, right?
http://en.wikipedia.org/wiki/Algorithmic_efficiency
I wasn't referring to volumetric or energy efficiency. I'm sure you know this
though.
> When you can
> be efficient *and* accurate-
> well, then they offer you
> management, don't they?
That's only if you can be coniving as well. 
| |
| Tarkin 2007-02-11, 1:30 am |
| On Feb 10, 7:43 pm, Christopher Layne <cla...@com.anodized> wrote:
> Tarkin wrote:
>
>
>
> But we know it will never be reworked later once he sells his soul to the
> deadline devil.
>
>
> Then base2 should be the most "efficient" implementation, right?
>
> http://en.wikipedia.org/wiki/Algorithmic_efficiency
>
> I wasn't referring to volumetric or energy efficiency. I'm sure you know this
> though.
>
>
> That's only if you can be coniving as well.
Sorry about the sarcasm. I may have
(mistakenly) taken his statement
about 'wanting to send all kinds of
files' with an underlying
tone of, 'I don't care how.'
Algortimic efficiency doesn't
appear to be his goal; getting his
code to work does. If I couldn't
get binary transfers to work, and didn't
want to bother following any of the other
several (including your htons...) good
suggestions, I would wrap the data in
base64. Isn't that a classic internet
solution involving binary data transfer?
Given the size of of the files he's used
as examples thus far, I'd say the overhead
of base64 encode/decode won't present
much of a problem. Of course, if he moves
on to DVD images or huge AI training
datasets, that's another kettle of fish.
Myself, I would explore the avenues
listed here first, and use google a little
more.
And yes, conniving and cunning are
management requirements 8^)
TTFN,
Tarkin
| |
| David Schwartz 2007-02-11, 7:18 pm |
| On Feb 10, 7:18 pm, "Tarkin" <Tarkin...@gmail.com> wrote:
> Algortimic efficiency doesn't
> appear to be his goal; getting his
> code to work does. If I couldn't
> get binary transfers to work, and didn't
> want to bother following any of the other
> several (including your htons...) good
> suggestions, I would wrap the data in
> base64. Isn't that a classic internet
> solution involving binary data transfer?
> Given the size of of the files he's used
> as examples thus far, I'd say the overhead
> of base64 encode/decode won't present
> much of a problem. Of course, if he moves
> on to DVD images or huge AI training
> datasets, that's another kettle of fish.
It seems like getting his code to work with minimal effort was his
goal. If that's true, he's probably better off trying to find the bug
in his code rather than writing a whole bunch of new code that will
likely bring with it all kinds of new bugs.
While base64 encoding and decoding isn't that complex, it's about on
par with sending binary data. So starting on a whole new task of equal
complexity that will likely still leave him with the bug he had in the
first place doesn't seem like such a good idea.
Plus, if his problem stems from, for example, the inability to deal
with embedded zero bytes, he may wind up with a working server that is
a disaster waiting to happen. All it might take is a malicious client
that sends an embedded zero byte and god knows what his code might do!
DS
| |
| Tarkin 2007-02-11, 7:18 pm |
| On Feb 11, 5:13 pm, "David Schwartz" <dav...@webmaster.com> wrote:
> On Feb 10, 7:18 pm, "Tarkin" <Tarkin...@gmail.com> wrote:
>
>
> It seems like getting his code to work with minimal effort was his
> goal. If that's true, he's probably better off trying to find the bug
> in his code rather than writing a whole bunch of new code that will
> likely bring with it all kinds of new bugs.
>
> While base64 encoding and decoding isn't that complex, it's about on
> par with sending binary data. So starting on a whole new task of equal
> complexity that will likely still leave him with the bug he had in the
> first place doesn't seem like such a good idea.
>
> Plus, if his problem stems from, for example, the inability to deal
> with embedded zero bytes, he may wind up with a working server that is
> a disaster waiting to happen. All it might take is a malicious client
> that sends an embedded zero byte and god knows what his code might do!
>
> DS
Hmmmm...I was under the impression that you
could just C&P from some tut or library, spend
a couple of hours on debug, and be done with.
When I want things done, as opposed to right,
that's what I do....
Note that I do not do this for clients or employers,
just code for my own edification. If my knowledge
hits a brick wall, and no amount of docs or man
pages are helping, I google for few-thirty minutes,
find an appropriately 'close' tut or library, C&P
the relevant portions or functions, then swear
profusely as I bend code that I ill understand
to my own twisted purposes :^)
But... the upshot is, I learn a lot of things- sometimes
what to do, sometimes what *not* to do. But I always
learn *something*.
The base64 example I found had only
two functions- ???encode() and ???decode(),
the parameters involving byte lengths and buffers
and such. Anywho, it seemed incredibly trivial
to use, from what I recall, and thought the OP
might be similarly disposed to such antics-
again, when one wants something done *now*,
as opposed to done *right*.
Just my 2p,
Tarkin
| |
| David Schwartz 2007-02-11, 7:18 pm |
| On Feb 11, 3:59 pm, "Tarkin" <Tarkin...@gmail.com> wrote:
> The base64 example I found had only
> two functions- ???encode() and ???decode(),
> the parameters involving byte lengths and buffers
> and such. Anywho, it seemed incredibly trivial
> to use, from what I recall, and thought the OP
> might be similarly disposed to such antics-
> again, when one wants something done *now*,
> as opposed to done *right*.
First, the base64 code will add new complications. For example, if
you're not comfortable with C-style strings (which the problem the OP
is having suggests he may not be), dealing with the memory management
may be a problem. He'll either need to allocate enough space for the
base64 string (and it's not obvious how much that is), or he'll have
to let the library allocate it and him free it.
Second, he may be dealing with files too large to encode in one pass.
Splitting into chunks for base64 encoding is not simple either. You
cannot just break on arbitrary boundaries or the decode process will
get errors unless it can find the exact same boundaries. This is a
much slipperier problem than you might think. There are three ways to
solve it and they each have their subtleties. (I'm betting your base64
decoder doesn't keep state across calls and output data as it is
completed. So you have to properly chunk the input to the decoder.)
Third, you aren't suggesting removing any existing code, and his
existing code has a bug. So the bug will still be there. If he still
has to find it, this added complexity will have gained him nothing. If
he doesn't find it, he won't know if it's affecting his code or not.
I'm personally not comfortable with that and I don't know that OP is
either.
Last, the learning opportunity is lost. Handling binary data in C
without mangling it is a *very* basic skill. It's logically way below
any networking code. So this would leave the OP with a huge hole in
his knowledge right in the area he's working around.
DS
| |
| Tarkin 2007-02-12, 1:33 am |
| On Feb 11, 7:48 pm, "David Schwartz" <dav...@webmaster.com> wrote:
> On Feb 11, 3:59 pm, "Tarkin" <Tarkin...@gmail.com> wrote:
>
>
> First, the base64 code will add new complications. For example, if
> you're not comfortable with C-style strings (which the problem the OP
> is having suggests he may not be), dealing with the memory management
> may be a problem. He'll either need to allocate enough space for the
> base64 string (and it's not obvious how much that is), or he'll have
> to let the library allocate it and him free it.
>
> Second, he may be dealing with files too large to encode in one pass.
> Splitting into chunks for base64 encoding is not simple either. You
> cannot just break on arbitrary boundaries or the decode process will
> get errors unless it can find the exact same boundaries. This is a
> much slipperier problem than you might think. There are three ways to
> solve it and they each have their subtleties. (I'm betting your base64
> decoder doesn't keep state across calls and output data as it is
> completed. So you have to properly chunk the input to the decoder.)
>
> Third, you aren't suggesting removing any existing code, and his
> existing code has a bug. So the bug will still be there. If he still
> has to find it, this added complexity will have gained him nothing. If
> he doesn't find it, he won't know if it's affecting his code or not.
> I'm personally not comfortable with that and I don't know that OP is
> either.
>
> Last, the learning opportunity is lost. Handling binary data in C
> without mangling it is a *very* basic skill. It's logically way below
> any networking code. So this would leave the OP with a huge hole in
> his knowledge right in the area he's working around.
>
> DS
I see your point. My recollection on the routines
was/is fuzzy- IIRC, I did aba^H^H^H let the project
rest, as I ran into the chunking problem you're
talking about. IIRC, I had to coordinate/invent
some convenient scheme to send chunk length
with the chunk, etc....
However, he seems to be testing w/ files of < 8192
bytes. This led me to believe that he could encode
his single 3850 .gif in one pass, dump it through
his prog, and see if that gets by unmolested.
He *thinks* text is passing ok, and I'm betting mangled
text will test that assumption. Because, after all, isn't
text binary data anyway? (Limited subset, special
interpretation, 7b or 8b, but ultimately binary...)
But, you two are right- the added complexity isn't
worth it. I tend to do things the hard way, watch
things explode spectacularly, then observe the
fragments. Effecient? No. Educational? Yes.
So, it's back to man pages for the OP.
and probably[1]:
'cd /usr/include
view foo.h bar.h bits/types.h bits/errno.h'
And other such viewings. Fun stuff for
network programming.
[1] I don't if this particularly accurate;
it's linux-ish
TTFN,
Tarkin
| |
| Tarkin 2007-02-12, 1:33 am |
| On Feb 11, 9:45 pm, "Tarkin" <Tarkin...@gmail.com> wrote:
> On Feb 11, 7:48 pm, "David Schwartz" <dav...@webmaster.com> wrote:
>
>
>
>
>
>
>
>
>
>
> I see your point. My recollection on the routines
> was/is fuzzy- IIRC, I did aba^H^H^H let the project
> rest, as I ran into the chunking problem you're
> talking about. IIRC, I had to coordinate/invent
> some convenient scheme to send chunk length
> with the chunk, etc....
>
> However, he seems to be testing w/ files of < 8192
> bytes. This led me to believe that he could encode
> his single 3850 .gif in one pass, dump it through
> his prog, and see if that gets by unmolested.
> He *thinks* text is passing ok, and I'm betting mangled
> text will test that assumption. Because, after all, isn't
> text binary data anyway? (Limited subset, special
> interpretation, 7b or 8b, but ultimately binary...)
>
> But, you two are right- the added complexity isn't
> worth it. I tend to do things the hard way, watch
> things explode spectacularly, then observe the
> fragments. Effecient? No. Educational? Yes.
>
> So, it's back to man pages for the OP.
> and probably[1]:
> 'cd /usr/include
> view foo.h bar.h bits/types.h bits/errno.h'
> And other such viewings. Fun stuff for
> network programming.
>
> [1] I don't if this particularly accurate;
> it's linux-ish
>
> TTFN,
> Tarkin
Here are my other thoughts on the subject:
don't various formats of binary files usually
have some sort of header, and if not,
isn't there still some method to their madness?
Due to the inherent design of whatever format,
decimal values like '0' (ASCII 'NUL', or null) and
'10' and '13' have entirely different meanings than
their standard ASCII, Unicode, or whatever text
encoding is in force on your particular system.
So, at a guess, the OP is probably not bothering
to examine his binary file to obtain the file length,
and not opening (fopen()?) the file in binary mode.
This makes his read(), or fread(), or whatever call
he is using, choke on the first EOF or '0' value,
and thus truncates his sent data.
So, if that's his issue, yeah, he should
probably fix that before tilting at encoding
windmills.
TTFN,
Tarkin
| |
| Christopher Layne 2007-02-12, 1:33 am |
| Tarkin wrote:
> Here are my other thoughts on the subject:
> don't various formats of binary files usually
> have some sort of header, and if not,
> isn't there still some method to their madness?
>
> Due to the inherent design of whatever format,
> decimal values like '0' (ASCII 'NUL', or null) and
> '10' and '13' have entirely different meanings than
> their standard ASCII, Unicode, or whatever text
> encoding is in force on your particular system.
>
> So, at a guess, the OP is probably not bothering
> to examine his binary file to obtain the file length,
> and not opening (fopen()?) the file in binary mode.
> This makes his read(), or fread(), or whatever call
> he is using, choke on the first EOF or '0' value,
> and thus truncates his sent data.
He needs to do a minimum of two things:
1. Find the length of the total payload he is sending.
2. use htonl() on that length, and communicate it to the receiving end which
must know then ntohl() this length and allocate an appropriately sized buffer
for receiving the payload.
3. Send the binary payload. No transformations, nothing.
4. Optionally confirm receipt and handle issues or close socket.
| |
| David Schwartz 2007-02-12, 1:33 am |
|
> So, at a guess, the OP is probably not bothering
> to examine his binary file to obtain the file length,
> and not opening (fopen()?) the file in binary mode.
> This makes his read(), or fread(), or whatever call
> he is using, choke on the first EOF or '0' value,
> and thus truncates his sent data.
I don't know of any UNIX that has any mode other than binary for
opening files. His 'read' or 'fread' call will not choke on a '0'
value because 0 is not used to indicate end of file. EOF is used to
indicate end of file.
Of course, he could still choke on embedded zeroes his own way. For
example, if you tries to read the file a line at a time or calls
'strlen' on the data he read from the file.
A common mistake is to call 'read' or 'fread', like this:
len=read(fd, buf, sizeof(buf)-1);
if(len<=0) ...
buf[len]=0;
....
send(fd, buf, strlen(buf));
The 'buf[len]=0' is pointless, and then 'strlen(buf)' is broken.
DS
|
|
|
|
|