sobhan102398
asked on
networking
I am involved in developing a program with the following specifications.(in Linux)
Whenever I use ftp to fetch a file(get <filename>) if I press Control-C the file should be saved upto that point in the file.I write a footer to the file about the file pointer position .When I try to fetch the same file using get the file should continue transfer from the point it was saved upto and thus the transfer should begin only after the point upto which it was saved.I can only modify the ftp client code.The program should work with existing ftp servers.How will I achieve this (i.e making server send data packets containing the file contents only after a particular byte offset instead of from beginning of the file).Please help me in this regard and also provide general advice on the problem.
Whenever I use ftp to fetch a file(get <filename>) if I press Control-C the file should be saved upto that point in the file.I write a footer to the file about the file pointer position .When I try to fetch the same file using get the file should continue transfer from the point it was saved upto and thus the transfer should begin only after the point upto which it was saved.I can only modify the ftp client code.The program should work with existing ftp servers.How will I achieve this (i.e making server send data packets containing the file contents only after a particular byte offset instead of from beginning of the file).Please help me in this regard and also provide general advice on the problem.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I need to implement the client for linux
so what about <reget>.
so what about <reget>.
1. restart support
Well, an ftp server 'should' support since it is part of the protocol. But, in this less-than-perfect world, one way to make sure is to send the REST command (with any offset, 0 comes to mind). The answer would indicate if the server understands what you want or not (> 400 indicates failure of some sort, see RFC640 for the FTP reply code structure).
2. multiple get
This is really a client functionality. The client will first ask the server for a list of filenames corresponding to the mask using the NLST command. Then, a RETR command is done for every file, just as if the user asked for them one by one. As far as the restart is concerned, the REST offset is used only in the directly following RETR command. If your client wants to restart all files in a multi get, it must send the REST/RETR sequence for every file in the list. The offset to use will of course depend on the status of each file (do you really need to restart all the files *.c from a fixed offset like 1234 ? Remark that you can, by sending REST 1234 before every RETR, but I fail to see a practical use for this).
3. reget (in fact: get and append to an existing local file)
This is the simple case, use the current filesize of the local file (from stat()) as the offset in REST, and append the data coming in for the RETR command at the end of the file.
Well, an ftp server 'should' support since it is part of the protocol. But, in this less-than-perfect world, one way to make sure is to send the REST command (with any offset, 0 comes to mind). The answer would indicate if the server understands what you want or not (> 400 indicates failure of some sort, see RFC640 for the FTP reply code structure).
2. multiple get
This is really a client functionality. The client will first ask the server for a list of filenames corresponding to the mask using the NLST command. Then, a RETR command is done for every file, just as if the user asked for them one by one. As far as the restart is concerned, the REST offset is used only in the directly following RETR command. If your client wants to restart all files in a multi get, it must send the REST/RETR sequence for every file in the list. The offset to use will of course depend on the status of each file (do you really need to restart all the files *.c from a fixed offset like 1234 ? Remark that you can, by sending REST 1234 before every RETR, but I fail to see a practical use for this).
3. reget (in fact: get and append to an existing local file)
This is the simple case, use the current filesize of the local file (from stat()) as the offset in REST, and append the data coming in for the RETR command at the end of the file.
ASKER
1.I want my program to be compatible with all unix ftp servers. they might not support restart. How will I know by program whether a server supports restart option or not
2.Can u provide me sites where I can get ftp client code documentation
2.Can u provide me sites where I can get ftp client code documentation
1. According to RFC640, a client sending a REST command can recieve following messages:
500 syntax error, command not recognized
501 syntax errors in parameters
502 command not implemented
421 service not available
530 not logged in
350 requested file action pending further information
So, make the client send a REST command, and act on:
350: ok, restart supported by server (and set for next RETR)
502: no go, server does not understand the REST command
other: fix the problem according to list above and try again (if your client is functioning correctly and connected and logged in to a host, only 350 or 502 should be expected).
2. FTP is part of the (linux) netkit package. The first one I found was at:
ftp://ftp.cc.gatech.edu/pub/linux/system/network/file-transfer/netkit-ftp-0.10.tar.gz
(There are plenty of other sources, for example all mirrors of sunsite.unc.edu)
500 syntax error, command not recognized
501 syntax errors in parameters
502 command not implemented
421 service not available
530 not logged in
350 requested file action pending further information
So, make the client send a REST command, and act on:
350: ok, restart supported by server (and set for next RETR)
502: no go, server does not understand the REST command
other: fix the problem according to list above and try again (if your client is functioning correctly and connected and logged in to a host, only 350 or 502 should be expected).
2. FTP is part of the (linux) netkit package. The first one I found was at:
ftp://ftp.cc.gatech.edu/pub/linux/system/network/file-transfer/netkit-ftp-0.10.tar.gz
(There are plenty of other sources, for example all mirrors of sunsite.unc.edu)
ASKER
What about dealing with servers which donot support restart options.(is there any backtrap or any efficient method)
I am afraid there is not much a client can do to make a difference. The only thing would be to discard incoming data up to 'offset' bytes and than start appending to the existing local file. But this is not really an optimization since the network will be the bottleneck, not the local disk throughput.
On the other hand, did you already encounter servers that do not support restart ? Remember that not every one is writing his own server, and the 'common' onces adhere to the standard as defined in the RFC. Supporting restart is not complicated on the server side (a simple seek in the file to the offset value received in a previous message before starting to read and send the file data), so I wonder why this feature would be left out of any server implementation.
On the other hand, did you already encounter servers that do not support restart ? Remember that not every one is writing his own server, and the 'common' onces adhere to the standard as defined in the RFC. Supporting restart is not complicated on the server side (a simple seek in the file to the offset value received in a previous message before starting to read and send the file data), so I wonder why this feature would be left out of any server implementation.
ASKER
Ok thanks . I will inform u on further progress*
ASKER
One last query
Is it possible say I don't want to modify the client code.
And I write my own code in a seperate file for handling the get command.
Now I make a DLL with my code.
Can I make the client program connect to my function for handling put without calling the actual function for put.
Is it possible say I don't want to modify the client code.
And I write my own code in a seperate file for handling the get command.
Now I make a DLL with my code.
Can I make the client program connect to my function for handling put without calling the actual function for put.
I am somewhat confused, but let me try to give you some ideas (for what I can make of the question, sorry if it is not what you mean).
Not modifying the client code and having it call a function you write is possible in certain limited cases:
1. There must be a function for you to replace in the original code (implementing the 'get').
2. This function must be in a source file of its own and compiled as a separate object, to be linked together with other objects to form the client executable code.
If this is the case, you can implement your own 'get' function in a source file, compile it and use this to be linked with all other objects that are part of the original client code, except the one containing the original 'get' function. This does not use the DLL mechanism but only static linking.
If the original function is not in an object file of its own, you are in trouble. Linkers typically search for a function in the object files and than link the complete object containing the function, including all other functions in the same object. If the 'get' function is not in a separate object and you want to replace it, you will have to implement in your source file all other functions in the original object. If you do not do this, these functions will not be resolved by the linked or, if you still supply the original object to the linker in addition to your object containing your 'get' function, the linker will find multiple definitions for the get function when the original object is linked in for some other function it contains.
Putting your code in a DLL (under Linux ?) would be a solution only if the original function was already in a DLL and you are able to replace this with your own with the same name. The problem of other functions in the original DLL is somewhat similar to the linking described above. You could try making your DLL call the original functions through stub routines, but the DLL name (original the sameas the new, and you cannot just rename a DLL and keep on using it).
If this is not a response to your question, please state it more clearly and I will do my best to answer it.
Not modifying the client code and having it call a function you write is possible in certain limited cases:
1. There must be a function for you to replace in the original code (implementing the 'get').
2. This function must be in a source file of its own and compiled as a separate object, to be linked together with other objects to form the client executable code.
If this is the case, you can implement your own 'get' function in a source file, compile it and use this to be linked with all other objects that are part of the original client code, except the one containing the original 'get' function. This does not use the DLL mechanism but only static linking.
If the original function is not in an object file of its own, you are in trouble. Linkers typically search for a function in the object files and than link the complete object containing the function, including all other functions in the same object. If the 'get' function is not in a separate object and you want to replace it, you will have to implement in your source file all other functions in the original object. If you do not do this, these functions will not be resolved by the linked or, if you still supply the original object to the linker in addition to your object containing your 'get' function, the linker will find multiple definitions for the get function when the original object is linked in for some other function it contains.
Putting your code in a DLL (under Linux ?) would be a solution only if the original function was already in a DLL and you are able to replace this with your own with the same name. The problem of other functions in the original DLL is somewhat similar to the linking described above. You could try making your DLL call the original functions through stub routines, but the DLL name (original the sameas the new, and you cannot just rename a DLL and keep on using it).
If this is not a response to your question, please state it more clearly and I will do my best to answer it.
ASKER
What I asked was
I donot modify the client means I am not taking care of the ftp client program or its code. The ftp client program is the executable client that is provided with linux which will not be changed. Now if in the ftp program if I use get command it executes the sub function meant for it. Now if I write a similar get sub function in a seperate file,can I make the ftp client to call my function instead of the original.
I donot modify the client means I am not taking care of the ftp client program or its code. The ftp client program is the executable client that is provided with linux which will not be changed. Now if in the ftp program if I use get command it executes the sub function meant for it. Now if I write a similar get sub function in a seperate file,can I make the ftp client to call my function instead of the original.
I understand what you want now, but I do not see any solution for it. While it is true that in theory you can write a 'get' function in a dynamic linked library and replace the original library containing this function (and only this one), in practice I do not know of any implementation that is really written in such a way. Although it might be a nice feature to have in your case, I do not think anyone writing a general FTP client will implement all the functions in separate libraries, just in case someone would like to replace a single function. Many implmentations will not even have a single function to handle a 'get' or any other command, so it would not be a trivial task to modify such a program to fit your need.
ASKER
What about when getting multiple files
like
restart 1234 //from 1234 byte
get *.c
will I get all c files from 1234 offset
how will I use the byte offset.