Slashdot Mirror
PDTP - The Best of Both FTP and BitTorrent?
ikewillis writes "For awhile I've been following the development of PDTP (Peer Distributed Transfer Protocol), which is trying to merge the concepts of FTP and BitTorrent. This sounds like it could be useful for apt-get repositories or other high demand FTP sites. It's designed to be used as part of scalable networks which could replace manual selection of FTP mirrors. It also supports a number of other nifty features like cryptographic file signatures. Isn't it about time we ditched FTP for something better?"
I feel sorry for these people. See, this isn't your typical slashdotting... It's a slashdotting that comes after eighteen consecutive nonsense stories being posted over twelve hours on the US April Fool's Day.
So, their chance to build a reputation is going to be damaged by the fact that anybody reading Slashdot today has already given up on finding anything useful, and will be evaluating them as a joke that they're "not getting" rather than as a proposed networking scheme.
Furthermore, the geek world is bored today by Slashdot's denial-of-normal-service throughout the day. So, once word leaks out that this is a real and normal story, they're going to get all of the pent up slashdotting force applied to their server.
Simon, you should have started your set tonight with an NY Times article or two. That would have been a suitable transition between nonsense content and factual content, since NYT operates in that murky space and has a suitable web setup to absorb a larger-than-usual slashdotting. I'm sure the people at PDTP would have not minded at all if their moment in the sun had come an hour later tonight.
Isn't it about time we ditched FTP for something better?
Isn't it about time we ditched floppy disks for something better?
Isn't it about time we ditched IDE drives for something better?
Isn't it about time we ditched x86 for something better?
Isn't it about time we ditched Microsoft Windows for something better?
Isn't it about time we ditched CDs for something better?
Isn't it about time we ditched telnet for something better?
Isn't it about time we ditched CRTs for something better?
Isn't it about time we ditched 20-year-old TV sets for something better?
Isn't it about time we ditched COBOL for something better?
Isn't it about time we ditched BASIC for something better?
Isn't it about time we ditched SCO Unix for something better?
Isn't it about time we ditched DOS for something better?
Isn't it about time we ditched Dubya for something better?
my point is that there is a lot of very old crap out there that should be replaces, but is going to get used and keep getting used for years to come.
Interesting... this could bring piracy back to the ftp world, rather than the emule appz or bittorrent world where it's easier to get caught.
We already have. It is called SCP
"Weapons should be hardy rather than decorative" - Miyamoto Musashi
I think that goes for OS's too
There are several P2P research projects that are looking at building reliabale and scalable P2P systems.
Take a look at Tapestry, and Chord (and read some of the papers) to understand the issues involved in providing scalable and high performance P2P services. Not only is scalable search and overlay graph connectivity an issue, but also node failure and short session times of P2P nodes.
Additionally, when you actually handle the issue of downloading data, building application-lvel multicast trees to distribute the data efficiently on a large scale is not easy. Two papers from SOSP '03 SplitStream, and Bullet address that issue.
"...Beer..."
So, if for example, I write this need little GPL'd app that everyone loves, and release it as opensource, I should be responsible for hosting the file server for everyone? What if hundreds of thousands of people use it everyday, and a new patch comes out. Should I have to buy a T-1 (or something bigger) that costs an arm and a leg, to provide the file patch for a free program to others with no income for me? Or should I ask others to help out with their extra bandwith, and get a few seeders out there with bittorrent and run the tracker with the DSL line i have. I could pay $20 a month for a metered tiered connection in my town, but I pay $50 for an "unlimited" (notice the quotes). I know that not everywhere has these kinds of services, but you don't have to leave the torrent open forever either, or just leave the upload at 1k/s or something. It might slow down your download, but your still going to get access to the file..
What are we going to do tonight Brain?
I thought something better was sftp. As for distributions.. why not HTTP? Setup one reflector that dynamically kicks outs redirects as new mirrors come online. This is mutch better as we have a ton of clients already installed (curl,wget,..etc) We also have load balancing, dns round robin, authorzation, security(read: SSL) well defined in the protocol. All we need is a cgi script to kick out the redirects, and another that will make signature files based on the publically available SSL cert. Whamo all the same features.. and we didnt have to reinvent the wheel.
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
Really? I'm currently running four throttled BT downloads on a PII-350 w/64MB. Max CPU usage is 8%, load average 0.25. If you're really that bothered see here for an alternative.
but other problems arise such as integration of the Python implementation into a native GUI frontend for a given platform
Ever heard of WxGtk? RPMs for most distros, if it wasn't part of your default install.
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
Now this is just silly. I dont think there is a linux distro which doesn't include Python libraries and even for Windows it's a single small executable. Besides (correct me if I'm wrong) but isn't one of the reasons for using Python that it has bounds-checking on arrays and is therefore proof against the cause of most exploits - the buffer overrun?