FDT Door
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?