How can I send a file through socket?
Water Lin
Now the socket works, I can communication between server and client.
If I want to send a file from client to server, what should I do?
I think I need to read the file first, then put the file content to socket buffer, then send them. Is this sequence correct?
For txt file, I think it will be OK. But what will happen if I send exe file? How can I read exe file?
I am just a little confused about sending a file......
Water Lin
http://blog.waterlin.org
co...@mailvault.com
> I want to write a socket communication for my study in C++.
>
> Now the socket works, I can communication between server and client.
>
> If I want to send a file from client to server, what should I do?
>
> I think I need to read the file first, then put the file content to socket buffer, then send them. Is this sequence correct?
>
I worked on something similar recently. This page --
http://webEbenezer.net/build_integration.html -- has a link
to a file called File.cc. In CalculateMarshallingSize it reads
a file into a buffer and then uses a bzip2 function to compress
the file. There's a function called Send that sends the
compressed file data.
> For txt file, I think it will be OK. But what will happen if I send exe file? How can I read exe file?
>
I've not tried it with binary files.
> I am just a little confused about sending a file......
>
Brian Wood
Ebenezer Enterprises
www.webEbenezer.net
Water Lin
I also need to ask another question.
When I read the file, I need to send it exactly the same as the original
one.
But if I use <ifstream> to read the file, the >> will stop at a
blankspace or newline.
So, is it possible to read a whole file at one time without any change?
--
Water Lin
http://blog.waterlin.org
James Kanze
> Water Lin wrote:
> I also need to ask another question.
> When I read the file, I need to send it exactly the same as
> the original one.
Are you sure? There are cases where this is true, but most
protocols have specific rules, and the file doesn't
necessisarily conform.
> But if I use <ifstream> to read the file, the >> will stop at
> a blankspace or newline.
So don't use >>.
Formally, there's no way in C++ to read a file literally.
Practically, if you open the file in binary mode and imbue the
"C" locale, you should be OK. (In theory, binary mode can
append any number of 0's to the end. In practice, I don't think
that this is a problem with any modern system.) And of course,
you have to do unformatted reads.
> So, is it possible to read a whole file at one time without
> any change?
If you have a big enough buffer. The usual solution is to read
fixed sized blocks, processing each block before reading the
next. (A professional program will usually use a pool of
buffers and non-blocking reads, but that requires some system
dependent code.)
--
James Kanze (GABI Software) email:james...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Giuliano Bertoletti
Hello,
actually you need to write a protocol which details how data should be
exchanged from a client to a server and interpreted by the latter.
Indeed a few extra information besides the filebody have to be delivered
to the server. For example the name with which it should save the file.
It may also be worth including the expected length and a some kind of
crc or checksum.
Although TCP may provide reliability it can be useful for checking that
what you receive is exactly what you send.
Then it's up to you if you want to provide extra features like data
encryption or compression.
As I said, as simple as it may be, you need to design a protocol.
Regards,
Giuliano Bertoletti
Water Lin ha scritto:
Marcel Müller
> If you have a big enough buffer. The usual solution is to read
> fixed sized blocks, processing each block before reading the
> next. (A professional program will usually use a pool of
> buffers and non-blocking reads, but that requires some system
> dependent code.)
With a look to C++0x this should change, since a second thread may do
the job without the need for an asynchronous I/O API.
Marcel
James Kanze
wrote:
That's basically what I was suggesting, no. The thread doing
the processing doesn't block for the read. Using threads is
probably the simplest way to do it, although I suspect using the
system levelo asynchronous IO might be slightly more efficient.
Paavo Helde
> next. (A professional program will usually use a pool of
> buffers and non-blocking reads, but that requires some system
> dependent code.)
Just for curiosity: if a program uses mmap() or equivalent to map the file
(or parts to it) into memory and use it from there without asynchronous IO,
would it make it less professional, in your opinion?
Best regards
Paavo
James Kanze
> James Kanze <james.ka...@gmail.com> kirjutas:
It depends on the context. If it was a pure copy program,
probably, since that would limit the size of the file being
copied, and probably run slower as well (although that depends
on the OS). But very few people are writing pure copy
programs---they were generally written a long time ago. For a
lot of uses, mmap is a very good solution.