C[omp]ute

From: "andrew cooke" <andrew@...>

Date: Sat, 31 Mar 2007 12:02:45 -0400 (CLT)

On the plane Thursday I played around with the idea of writing a modular
system to move data (large quantities).  This is important in Astronomy at
the moment, and I'm not sure we have the best solution yet.

The approach I took was to remain as simple and modular as possible.  This
raised issues with metadata and resources.

Metadata seems unavoidable - if, for example, you are splitting files into
smaller pieces, or you want end to end verification, then you need
metadata.  And typically metadata and data have different requirements, so
tend to use different transports.  On the other hand this makes it
difficult to nest components (say you have a multi-hop transfer and want
one hop to use a component that splits data into smaller, parallel
chunks).

By "resources" I currently mean "disk space".  It should be configurable
for the system to not delete data until received at the destination (even
for multi-hops or broadcast to a known number of sinks).

The best solution I found was a hybrid approach that bundles "outgoing"
metadata with the data, but uses a separate broadcast channel for resource
release.

So during transfer the data would be packaged as a jar file (probably
uncompressed since the payload would likely already be compressed).  The
jar file would contain data and metadata (including checksums).  This
allows nesting, since a jar can contain another jar.  This has the
advantage of being "human readable" in caches and doesn't require separate
databases to associate data and metadata.

Resources are named (uniquely - probably from a naming service),
inherited, and freed on completion.  Notification is via a reliable
broadcast.  So, for example, a transfer might have two resources - the
initial resource for the data and a second resource used in an internal
hop.  If the inner resource is broadcast only that is freed, but if the
outer resource is broadcast both are freed.

I realise this is rather brief, but perhaps it will make sense to someone.
 My notes made on the plane follow.

Andrew


initial notes on file transfer toolkit


file format

uncompressed jar with MD5 and other metadata in META-INF
jars can be nested


use cases

- transfer from directory
- multi hop transfer
- several routes
- fragmentation


global reliable broadcast for resource management
global name source

intermediate data stored in temp directories (abstract to include memory?)
intermediate data are resources.

resources labelled by names.
resource can be associated with more than one resource name.
resource freed if any any resource name matches?
(generalize to boolean expression?)

directories act as queues
qos affects selection of data from directories?

initial directory unusual as name is arbitrary.
move to intermediate temp directory

final directory ditto.
populated from final temp, and then resource freed


global reliable broadcast for logging
dump to text log
ability to reconstruct history of a particular file from text log
text log human and machine readable


single-hop flow:

 +- data enters initial directory
 +- data moved to managed directory in jar format
    +- data selected from managed directory by qos
    +- data transmitted to remote target
    |  +- data arrive in remote managed directory
    |  +- data verified
    |  |  +- data unpacked into destination directory
    |  |  +- resource released
    |  +- managed data deleted
    +- managed data deleted

multi-hop could be repeated as above, but we may want to keep initial file
around.

problem with above is that file is deleted immediately from entry directory.