Re: Public SFS servers

Hi there,

>SFSRO meets to our request. It looks like what I wanted!
>
>I understand that "sfsrocd(sfs read only client daemon)" works to
>relay the blocks which are downloaded. Is it true?

At present, SFSRO does not use the BitTorrent technique of requiring
clients to also serve the data they've downloaded.  It's a promising
idea though.  If folks like that style of replication, SFSRO could
certainly integrate its replication code into the client daemon
itself.  Right now the programs are separate.


>Can "sfsrocd" work as Bittorrent? I mean that "sfsrocd" makes
>connections to some SFS mirrors("sfsrocd") and achieves good
>performance and fault-tolerance.

SFSRO builds on an existing location management infrastructure.  For
instance, it could use round-robin DNS scheduling to help clients
locate replicas.  BitTorrent builds in its own flavor of location
management by using trackers.

The download and replication processes are separate in SFSRO.  So to
generate BitTorrent-style replication with SFSRO:

* A client would run "pulldb" to replicate an existing database.
  The database is not really a file, rather it's more like
  a partition image.

* The client would start a replica server, giving it the database.

* The client can then mount the replicated file system with the client
  daemon.  The user can then access the files in a traditional sense of
  a file system.

SFSRO and BitTorrent solve slightly different problems, but I'll try
to compare them anyway.  High level differences/similarities:

* SFSRO:      scalable replication of public content
	      storage
              file system integrity
              incremental updates of dynamic content
              large collections of files

* BitTorrent: scalable replication of public content
	      caching
              file integrity
              on-demand replication of static content
              individual, large files

Comments:

SFSRO is good for distributing and archiving public data that requires
strong integrity guarantees in a file system format.  Software
distribution or fast certificate revocation is a good application.

SFSRO is about efficient storage and replication on untrusted hosts.
Replicas must support incremental updates of files such that updates
of content produce minimal network traffic.  We require that SFSRO
replicas be very fast, performing no complex operations or
cryptography.

SFSRO provides integrity not only of files, but of an entire file
system.  That is, the entire context of how files are arranged in
directory trees is part of the integrity check.  SFSRO will detect
tampering such as: removal of a file from a file system or
substitution of an old file for a new one.

BitTorrent is good for locating and distributing massive amounts of
static content on demand.  BT uses a "tracker" for clients to locate
content.  Video is an excellent application, and has minimal security
requirements.

BitTorrent is about making popular content readily available by
requiring downloaders to contribute upload bandwidth and temporary
storage.  Unpopular, old content may disappear.

Both systems take advantage of untrusted replicas.  SFSRO could
certainly learn from BitTorrent's success in on-demand replication and
location tracking.

Others more familiar with BitTorrent are welcome to chime in to
correct/supplement my comments.  See
http://www.scs.cs.nyu.edu/~dm/sfsro-tocs.pdf for SFSRO details.

--------
Kevin E. Fu ([email protected])