DrFTPD

DrFTPD is an open source, distributed FTP daemon in Java. It does not handle transfers like normal FTP servers. Instead of conventional server ↔ client transfer, DrFTPD is set up with a master and a collection of file transfer slaves that handle the file transfers, meaning users can have as many file transfer slaves as they like. Some names that could be used to describe this is FTP site merger, FTP cluster, FTP grid or multi-site BNC.
DrFTPD can not only use master ↔ client for control connections and slave ↔ client for (most) data transfers, but it works with existing FTP software; regular FTP application can be used, and site-to-site (FXP) transfers can be made with normal FTP servers. The only exception is with passive (PASV) mode; for this the client needs to support the PRET protocol extension. PRET is already supported in several of the most widely used FTP applications. It often works without PASV mode unless the user is behind a firewall which he does not have access to or he needs to FXP with another DrFTPD server or a server which does not support PASV.
If you merge 10x100mbit sites, you don't get a 1gbit site but you get a 10x100mbit site. What this means is that the aggregate bandwidth is 1000 mbit but a single transfer will never go above 100mbit.
Distribution of assets
File system
DrFTPD has a novel approach to the file system and file transfers. Each file can, and will, end up on a different transfer slave.
DrFTPD uses transfer slaves for all file storage and transfers, it supports but doesn't require a file transfer slave to be run locally. The master therefore uses very little bandwidth. FTP control connection, data connections for file listings and instructions to the slaves, are the only operations that consume bandwidth on the master.
The master has a filelist that keeps track of which slaves have which files and information about those files. A file can exist on multiple slaves for redundancy and more bandwidth.
When a slave is started, it gathers a file list and sends the entire list to the master. The master merges this list with its existing file list and makes sure that it is in sync with its existing file list by adding and removing files to its own list.
Because the master does not have any files locally, modifications to the virtual filesystem cannot be done easily from outside of the drftpd application.
Neither the master or the slaves need root privileges. The virtual filesystem contained on the master of which slaves files reside on is the authoritative source for information about the files. Items like lastModified, size, user, and group, are all kept on the master. The slave does however require exclusive write access to the storage area, otherwise it will become unsynced with the master filelist and errors can occur.
The slave is kept thin/dumb and isn't told anything about users. It simply processes the instructions that are given to the master and knows nothing about the ftp protocol. This is an advantage as it simplifies administration of the slaves.
Comparison to traditional FTPDs
Drftpd is fully distributed and has no working comparison. Msftpd is a work in progress and follows the PRET spec that drftpd has created. Drftpd is the only working implementation of PRET.
RaidenFTPD managed to get halfway toward PRET with what it calls VLS (Virtually Linked Servers). It does a remote mount of a directory, so you can put /movies on another FTP. It's just a convenience so that the ftp client doesn't need to connect to another FTP.
Pros & cons
Pros
*It is completely multi-platform running on any environment that supports Java.
*The userlist and filesystem in DrFTPD is completely virtual, and this server is among the few that do not require administrative privileges to run.
*The slave is kept thin/dumb and is not told anything about users. It simply transfers the files as instructed by the master. This has security and administration advantages.
Cons
*Because the master does not have any files locally, traditional external scripts will not work, so no compatibility can be made for them (unless O/S APIs can be wrapped to DrFTPD APIs).

Main Menu

See Also

Main Menu