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.
...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.
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.
There are many places in the world where bandwidth is metered and charged for the amount of data transferred. Unfortunately, it looks like this was written by a bunch of Americans and college students who don't have to pay for their bandwidth usage and seem willfully ignorant of the entire rest of the world out there. I, for one, will not be sharing my bandwidth for something that should be provided by the file's source.
We already have. It is called SCP
"Weapons should be hardy rather than decorative" - Miyamoto Musashi
I think that goes for OS's too
Answer to this is the same argument that I've heard sometimes applied to open source:
If we all contribute a little, then the cost to all of us is that much less.
----- Documentation is worth it just to be able to answer all your mail with 'RTFM' - Alan Cox.
I'm waiting for boot disks that fire up a peer to peer client for installing your os, and updates. Debian would be a great start, it would hugely reduce the load of the servers. Also Fedora, the BSDs, etc.
Yes, you can already do bit torrent for the ISO, but that is its own kind of wast and hassle.
Some day.
Plato seems wrong to me today
There's no problem with that, don't share your bandwith with anyone, noone shares bandwith with you. Then you can only download from one source with limited resources. Other people that share can download from many sources (eventually each one with much less resources) that provide a total bandwith much greater, and more, when there is more people downloading they also download faster, instead of you that don't wanna share and have to slower the download when more people that don't share start to download... And besides, most people's connection limits are dowload limits not uploads :-P
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?
Question:
"Skyfire is using a derivative of the Apache License. Doesn't that preclude linking with Qt as the Apache License is incompatible with the GPL?"
Answer:
The FAQ page"Qt/X11 is dual licensed under both the GPL and the QPL. The Apache License, while incompatible with the GPL, is not incompatible with the QPL, so when Skyfire is linked with Qt/X11 the terms of the QPL apply. Qt Non-Commercial Edition for Windows has a separate set of license terms which apply to all Windows builds of Skyfire." (emphasis added)
Isn't this license a poor one? Aren't they breaking sourceforge.net rules by using a OSI unapproved license?
Or maybe I don't know what I am talking about. PLEASE Correct me if I am wrong.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?
You could either use a free distribution site, like Sourceforge, or, if your application is as great as you say it is, other people will ask *you* about mirroring it.
The operating systems are not going to chuck ftp so soon and nor are they going to include torrent as a default program. :-)
I think theres still a while till we ditch ftp and move onto something else completely.Torrents and other p2p stuff is good but only if you take the effort to get them.What about the masses who want to click and go?It won't happen till they can right click and it says "Save torrent as".
Lord of the Binges.
... this QT GPL project was ever done, we could just ignore any such issues for ever and ever: http://kde-cygwin.sourceforge.net/qt3-win32/index. php
HTTP does not do the same things that FTP does.
HTTP sucks for file transfers, frankly. You need a full-fledged web-browser just to view the index of files on an HTTP server. Not to mention that automatically downloading subdirectories requires serious processing of numerous HTML sub-documents.
HTTP does not do a good job of:
handling authentication.
handling sessions.
keeping statistics
limiting connections
communicating error messages
Etc, etc, etc.
Yes, I think everyone will agree that FTP sucks in that regard, but HTTP has it's own drawbacks.
FTP would disapear quickly if something came along that had all the features of FTP, without the baggage. However, until that something comes along, we are all stuck with FTP.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
But there are people that keep sharing even after their dowload completes... And you seem to be missing an important point. Even if you have a T1, if there are lots of people downloading through FTP you have to share the bandwith with all of them. With a p2p solution people stop using your bandwith sharing between them, meaning you can serve your files faster and with a greater total bandwith. When you say In BitTorrent, your download speed is theoretically capped to your upload speed you are assuming that the FTP server can serve you faster than you can upload. And that's not the case when there are lots of people trying to access the files in question (never heard of pages being slashdoted?).
Please don't use straight SHA1 - it requires downloading the entire file to verify.
.torrent files relatively big).
Bittorrent and some other file sharing networks split the file into chunks and keep metadata with the hashes of chunks. The problem with this idea is how big to make the chunks: too big and you need to download a big chunk before you can verify. Too small and the list of hashes itself takes too long to download (the hashes are what makes
I think the solution should be to use hash trees. Split the file into relatively small chunks (1k?) and calculate their hashes. Now take every two consecutive hashes and hash them. Repeat with the hash results from the previous step until you have a tree with a single hash at its root. The root hash represents the entire file just like an MD5 of SHA1 sum. The difference is that with a small amount of metadata as hints you can verify any part of the file without downloading the entire file. All you need is a short (log n) chain of hashes leading down to the root hash. The server will trickle the hash information interleaved with the download and the client will verify it on the fly and never need to write a single byte to the disk before it's cryptographically verified.
Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.