[LCP]moving folder contents from one m/c to another
Jack Lloyd
lloyd at acm.jhu.edu
Tue Dec 17 21:24:01 UTC 2002
On 17 Dec 2002, mehul radheshyam choube wrote:
> hi friends,
> i want to move folder contents from one m/c(client) to another
> m/c(server). for this i have written two programs client.c and
> server.c.
>
> for this there can be two approches :-
> (a) client sends file wait for ack from server and on recieving
> ack send
> next file.
> (b) client just pushes the all the files and the server reads
> the
> contents. no ack in this approach.
>
> i m trying 2nd approach but it doesnt work. here i have decided
> for a delimeter which is '\012'(LF). the cliebt send file name ending
> with LF, hen send file perms ending with LF then sends file size ending
> with LF and last the file contents ending with LF.
First, as others pointed out, the file (or permissions bits, or the
filename) might contain a LF char. The best way to handle this (IMO) is to
define some sort of reasonable format using length fields. As a simple
example, send:
LEN(FILE_NAME) || FILE_NAME || LEN(FILE_CONTENTS) || FILE_CONTENTS
This way you can pick things off the network easily enough without having
to check every byte you read to see if it's the delimiter you chose, so
it's faster and easier as well as safer. In particular, if you always
encode the length field to a particular size, you don't have to use a
delimiting marker anywhere.
Having the client push all the files at once could be problematic. In
particular, if they're big and the server is busy with other things (like
reading huge files sent by another client), packets will get dropped and
the client will have to retransmit. This may or may not be an issue
depending on your environment, just thought I should mention it.
Lastly, are you sure you really want to do this at all? Using something
like FTP, SFTP, or RSYNC might be more appropriate, and reinventing the
wheel, fun as it is, does take up a lot of time that might be spent more
usefully.
-Jack
More information about the linuxCprogramming
mailing list