Domain: pdtp.org
Stories and comments across the archive that link to pdtp.org.
Comments · 12
-
Re:If it all works... the end of BitTorrent?Seems to me like BitTorrent's days are numbered, it's halfway between two other technologies and doesn't fit the role of either of them. This application seems to be merging BitTorrent with what Kazaa originally tried to be, a fully decentralized distributed network that allowed parallel downloads of file chunks. Now given BitTorrent does parallel distributed downloads of file chunks substantially better than Kazaa, and it sounds like this new application will fill the P2P role of BitTorrent much better.
On the centralized aspect, I think when it's complete PDTP will completely replace BitTorrent for downloads from a central server. It can easily be used with large file repositories like current FTP servers maintain. It works way more like Apache, you just point it at the directory you want it to serve and it does the rest, no need to generate crappy
.torrent files. Plus since all of the logic is server side it makes writing clients much easier, and allows for substantially faster downloads and better control. I always get sick of when my torrents are coming in 5kpbs down 100kbps up :( -
Re:One little problem...
Sounds like something PDTP could solve...
-
Re:BitTorrent is nice.The solution is, in my opinion, to first move away from BitTorrent for content distribution. There are significantly more flexible, powerful, and elegant protocols ready to take its place such as PDTP which could be used for distribution of the actual RSS feed.
The next step would be some sort of UDP beaconing system, where clients periodically "ping" a beacon saying they want updates pushed to them, and the server will periodically "beacon" with the latest available content of a given type until a TTL expires, provided they don't receive a "ping" from the client before that.
-
I just can't wait until...
PDTP usage surpasses BitTorrent...
-
I just can't wait until...
PDTP usage outranks BitTorrent
-
Re:The concept is great, but...Hello. I'm the designer of PDTP.
I suggest you look at this page with graphic illustrations of PDTP networks for a better idea of how PDTP works. There is no concept of a "mirror" in a PDTP network. The Source Server is the central authority on all files being distributed over the network, and notifies all servers/piece proxies on the network whenever files become available or unavailable. Like BitTorrent, the network is largely self-sustaining, with clients uploading pieces to each other and verifying their integrity with MD5 or SHA1 checksums. Files are tracked on the network with integer keys, so if a file were altered its name would simply be mapped to a new key, and the entire network would be notified that the previous version is no longer available. ...mirrors would need to be in sync at all times for this to work. Otherwise your PDTP client is only able to download from the mirrors that are in sync, or worse, will get some chunks from files that aren't up-to-date, causing problems. Unfortunately, it's (almost) impossible to mirror new files instantaneously, so mirrors are never all in sync, all the time. -
Re:A better protocol for legitimate download swarmI agree. PDTP seems to be much better suited to corporate use than BitTorrent. BitTorrent's main drawback seems to be the lack of a mature, well supported C implementation, without which integration into other native code applications is extremely difficult as all applications using BitTorrent must bundle a Python runtime.
Unfortunately, PDTP seems a bit far from completion
-
A better protocol for legitimate download swarming
I have a lot of hope for PDTP to provide BitTorrent-like load distribution for roles typically filled by FTP servers. It's designed to be scalable into server clusters, while BitTorrent seems to have trouble with tracker overload for popular transfers.
-
A better protocol for legitimate download swarming
I have a lot of hope for PDTP to provide BitTorrent-like load distribution for roles typically filled by FTP servers. It's designed to be scalable into server clusters, while BitTorrent seems to have trouble with tracker overload for popular transfers.
-
Re:Should be used for Linux DistributionsThe problems seems to be with the inability of BitTorrent to serve directory heirarchies, and the difficulty of generating
.torrent files for a large repository of 10,000 files or more, plus the resource usage of running a BitTorrent tracker for each file.It seems there are protocols which are working to overcome these limitations.
-
A protocol better than BitTorrentIs anyone else sick of BitTorrent downloading 4kB/s while uploading 40kB/s? Or your downloads getting stuck at 99%? Anyone sick of a lack of a good C implementation and the Python implementation chewing up all your CPU and memory?
Check out PDTP, it looks quite promising. It serves file heirarchies just like an HTTP or FTP server and doesn't require you to pregenerate something like a
.torrent file, is written completely in C, and supports a number of other features like XML metadata and directory listings. -
Re:I'd rather see BitTorrent improved in more...I've taken a throw the baby out with the bathwater solution and have implemented BitTorrent-like download swarming with a server that stores a heirarchical filesystem and transfers that are highly server regimented: