Personal tools
You are here: Home Documentation dCache FDT Door
Document Actions

FDT Door

by admin last modified 2007-11-21 08:48

A work in progress page for the FDT door

FDT Door

The FDT door is built using dCache's LoginManager framework.  This allows us to authenticate with gPlazma and integrate easily with SRM.  The FDT door is designed to only do third-party transfers with other FDT doors and has two commands: get and put.  Once the get and put cycles have completed (documented below), the transfer is initiated on the pool itself.  The destination pool starts an FDT client and the source pool starts an FDT server.

Get Cycle

This documentation has not been written.

Put Cycle

This documentation has not been written.

FDT Interaction - Put

dCache provides us with a RandomAccessFile handle and information about the source server.  We need to take this and pass it to an static FDT-like object.  We need the following:
  • A way to instantiate the FDT system.  I understand that we need to make a pool of memory buffers; this instantiation can be done at the time of pool startup.  However, we need to be able to pass command line options through dCache means.  It's fine to pass it to FDT's config object, if that had a suitable public constructor.
  • A way to add files for FDT to download.
    • This seems to be done with the FileWriterSession.
    • Perhaps we need a dCacheFileWriterSession/dCacheFileReaderSession which takes a file handle instead of a file name?
    • We need to implement dCache analogues to FDTWriterSession and FDTReaderSession
  • I need to figure out how to "hit go" on FDT without using the FDT object, which is strongly oriented to one set of downloads for the JVM's lifetime.
  • Need to figure out a means for authentication for the source server.  We will want to only expose a certain subset of the node's files and make sure we only expose them to the "right" person.
    • Can we hand back a random number at the end of the "get" cycle and assume anyone with that number may download the corresponding file?  Assuming that server/client communication is encrypted (it is), is this secure enough?


Powered by Plone, the Open Source Content Management System