Acronym: Peer Distributed Transfer Protocol
The description from the website:
- “Like BitTorrent, PDTP decreases the amount of bandwidth a server needs to effectively serve files to a large number of clients by having the clients distribute portions of files to each other whenever possible. Unlike BitTorrent, PDTP is designed to serve directory hierarchies and requires no effort in manipulating the file repository it’s serving beyond manipulating the underlying filesystem. Consequently, a PDTP server functioning much like an anonymous FTP server, and supporting standard FTP features such as directory listings.”
- What is wrong with BitTorrent? Why reinvent the wheel?
- As PDTP is fundamentally different from BitTorrent in several ways, it shouldn’t be viewed as “reinventing the wheel”. However, PDTP was designed after analyzing and learning from a number of BitTorrent’s design and implementation problems.
- BitTorrent places considerable logic in the client. The tracker is little more than a switchboard through which every client participating chaotically attempts to manage the transfer process. Because no one client ever has the “big picture”, transfer rates are often suboptimal as the network of transfers is not logically organized by a central authority into an optimal configuration. Without centralized control, special hacks (http://home.elp.rr.com/tur/superseed.txt) are required in order to improve transfer rates.
- BitTorrent provides a means of transferring groups of files rather than files within a hierarchy. Consequently, BitTorrent cannot act as a “drop-in” replacement for an HTTP or FTP server. While it would be possible to use a program like dnotify (http://www.student.lu.se/~nbi98oli/dnotify.html) to autogenerate .torrent files for every file within a directory hierarchy, a subsequent problem with BitTorrent’s design is encountered with the computational overhead of the protocol design.
- Tracker communication in BitTorrent is handled over HTTP in a connectionless manner, which places significantly more demand on the server than a lightweight transactional protocol. Because of this, it becomes difficult for a single server to serve multiple “torrents” due to the resource usage of the BitTorrent tracker. While BitTorrent makes claims of “limitless scalability”, anyone who has actually used it knows this isn’t the case.
- BitTorrent suffers another problem in that the only usable implementations are currently only available in Python. The primary problem with Python is its excessive resource usage, but other problems arise such as integration of the Python implementation into a native GUI frontend for a given platform, as well as the need to bundle the Python runtime with the BitTorrent client on most platforms as few deployed systems have a Python runtime available.
What will be solved by PDTP? From the FAQ:
- What specifically will PDTP be doing differently from BitTorrent?
- PDTP is being designed and implemented with a primary goal of maximizing performance, and a secondary goal of ease of deployment and day-to-day operations.
- The state model is designed so that anyone will receive at least what they give to the peer network whenever it is available. Further performance will also come from the lightweight nature of the protocol, and the multiplexing model used within the server, pdtpd.
- Ease of use will be provided by eliminating the need for those making content available to pregenerate a content description file (i.e. torrent files) before making content available. All information needed to receive a file via PDTP can be expressed in the form of a URI. Hashing of files on the server is handled transparently to the server administrator by the Squall Hub, which supports multiple methods of filesystem monitoring, including ReadDirectoryChangesW() on Win32, dnotify/F-NOTIFY on Linux, kqueues on *BSD, and FAM for all other platforms.
- The PDTP server and client library are both written in C, and support both Win32 and POSIX platforms. Skyfire, the client application, is written in C++ using the Qt cross-platform GUI library and will operate on Win32 and POSIX platforms as well.
- PDTP will also support a feature currently only available in the protocols of peer-to-peer networks, namely extended file attributes. PDTP will support a Rich Directory Listing format capable of carrying file metadata and extended attributes (e.g. codec and bitrate for media streams) through the use of an XML format based on the Dublin Core Metadata Element Set. However, this feature operates secondarily to PDTP’s core functionality, and consequently XML formatting/parsing is not a requirement of any PDTP application.
- PDTP will also include support for the Digital Signature Standard, and will be capable of cryptographically verifying the integrity of files signed with a particular DSA key. This will allow applications to automatically propt the user in the event that a downloaded file fails to match its DSS signature. Currently the best approach to the problem of file tampering is to require users to manually verify file signatures using a program like GPG. PDTP will allow this process to be fully automated on the client side.
PDTP consists of the following components
- Skyfire (http://skyfire.sourceforge.net) – PDTP Client
- Squall (http://squall.sourceforge.net) – PDTP Server (hub, server, proxy and piece proxy)
- libpdtp (http://libpdtp.sourceforge.net) – Client Library
- PDTP FAQ (http://pdtp.org/faq.php) – The Frequently Asked Questions. Start here! Includes snapshots and SVN info.
- PDTP Status (http://pdtp.org/status.php) – The overal status of the project and its various components.
- PDTP Protocol specifications (http://pdtp.org/protocol.php) – The latest drafts of the PDTP protocol specification
TakeDown.NET -> “Peer-Distributed-Transfer-Protocol”