[Twisted-Python] Collaborative file storage via ftp/sftp/smb and html
Andrew Bennetts
andrew-twisted at puzzling.org
Mon Mar 1 00:56:15 MST 2004
On Mon, Mar 01, 2004 at 05:29:47PM +1000, Andy Gayton wrote:
> I'm investigating setting up a collaborative remote file share. There
> are a number of traditional ways for doing this, each has their
> strengths and weaknesses:
>
> ftp - not secure, fast and robust file transfer, supports resume,
> difficult to administer as unless chrooted users have access to the
> entire file system, if chrooted its difficult to set up group, no vendor
> lockin on the client
ftp isn't robust, either -- the multi-socket aspect of it means it often
breaks in the presence of firewalls. It also has no agreed standard for
sharing metadata (like modification times or content types?).
> sftp - same as ftp but secure
That's almost entirely wrong :)
SFTP has very little in common with FTP. The only similarities I can think
of are that SFTP clients are traditionally presented to look like FTP
clients, and that SFTP has per-session authentication (whereas with e.g.
HTTP you have to re-auth for every request, or at least pass auth
credientials like a session cookie for every request). As far as I'm aware,
SFTP doesn't have the binary/ascii transfer mode gunk that FTP has, or any
of the nasty seperate data connection sockets issues.
SFTP is massively more secure than FTP, though :)
> smb - secureish, slow over wan, doesn't support resume, great to
> administer - give exactly the access you want to who you want, easy to
> support groups, vendor lockin on the client
I suspect that you can resume with SMB -- a network filesystem that doesn't
support accessing files in pieces (i.e. seek) is pretty limited. Most
clients wouldn't expose this functionality, though.
> html - can be secure, slow non robust file transfer, doesn't support
> resume, easy to administer who has access to what, client access is
> universal
(I think you mean HTTP)
What's non-robust about HTTP, compared to FTP? And it definitely *does*
support resuming downloads -- see the Range header:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35
> I'm looking at defining a virtual filesystem that can be accessed
> eventually by all of the above the methods.
>
[...]
>
> I am going to start with conch's sftp at first and see how I go. Just
> thought I'd run it past the list as I get started to see if others are
> interested and have thoughts in the area or recommendations on how this
> should be done.
I just thought I should correct some misunderstandings about the protocols
you mentioned :)
-Andrew.
More information about the Twisted-Python
mailing list