In the standard library there is ftplib, which allows your program to
act as a FTP client. Of course
the receiver end should have an FTP server installing and running. I
don't tink it can handle SFTP protocol, so
if you are concerned with security you should opt for someting else,
or protect your connection somehow (e.g. SSH tunneling).
Or, if you have ssh (client and server) installed, you could simply
spawn a subprocess ( see the subprocess module for that ) which
execute one or more 'scp' commands.
Ciao
There are many ways to do it; each may have it's own pros and cons.
The low level sockets approach is feasible, as you said, and not too
difficult, either. Read from each file and write the data to a socket
from one end; read the data from the other end, and write it to a
file.
For the FTP approach, as Francesco said, the Python standard library
has ftplib, which can help you with the client side, i.e. the sending
side. If you don't have an FTP server on the receiving side, you could
try using pyftpdlib to implement your own FTP server in Python:
http://code.google.com/p/pyftpdlib/
Quoting from that URL:
" Python FTP server library provides a high-level portable interface
to easily write asynchronous FTP servers with Python.
pyftpdlib is currently the most complete RFC-959 FTP server
implementation available for Python programming language.
It is used in projects like Google Chromium and Bazaar and included in
Linux Fedora and FreeBSD package repositories. "
Of course all that could be too much overhead; also, you would need
permission to install your FTP daemon program written using pyftpdlib,
on the receiving computer.
As Francesco said, you could use the subprocess module and spawn a
process that runs instances of scp.
Another fairly easy way could be to write an XML-RPC client and
server. The client, on the sending side, can send the data of each
file to the server via an XML-RPC method call (in chunks, if needed,
if the file is large); the server, on the receiving side, can read
that data, and write it to a file on the file system. The client could
send the file name of each file first, via a separate method call,
before the data of each file, so the server would know under what name
to save the file on its file system.
By using the Binary data type supported by XML-RPC, you could send any
type of file, whether text or binary, and irrespective of the
operating system of the sender or receiver, whether Windows or UNIX.
I've done this in some code of mine, so I know it works.
You might have to take care about newline conversions (LF to CR + LF
or vice versa), though, if one side is UNIX and the other is Windows,
and do that conversion only for files that are text files. (For binary
files, you actually have to make sure that you DO NOT do that
conversion, or you will corrupt the data.)
And do a similar conversion if one side is Mac and the other is
Windows or Linux. On Mac, line endings are marked with a CR.
LF = Line Feed (ASCII 10)
CR = Carriage Return (ASCII 13)
The subprocess + scp method may be slower than the XML-RPC method,
since it will have to spawn a new scp process for each file sent,
unless you use wildcards and transfer all or many files in one call.
One the other hand, the XML-RPC method may be slower, since it
transfers the data over HTTP (which rides on TCP which rides on IP),
whereas scp probably uses a lower level protocol such as TCP packets
directly, or something similar to what FTP uses - those protocols may
have less overhead per unit of data sent.
Which approach is best depends on your needs, whether it is a one-off
job, or whether you need to repeat the job regularly, etc., how much
time you have to write the code, etc.
HTH,
Vasudev
---
Vasudev Ram
Biz:
www.dancingbison.com
xtopdf: fast and easy PDF creation from other file formats:
www.dancingbison.com/products.html
Blog (on software innovation): jugad2.blogspot.com
