I just tested it, and I don't know if it was just me or what, but the transfer was very slow.
I started the upload from FF, and downloaded it with IE, on the same computer, and it would take about 30 min.
The file was like 30 megs, and I am using cable. I downloaded the file from the original server in less then 30 min.
-nite_monkey
I doubt the java code or whetever they use to manage the transfer is smart enough to know both of your computers are inside your firewall. So your file is taking a tour of the internet.
When you consider what's happening -- bytes streaming up to your ISP and back down again -- a 30 minute round-trip that originally took 30 minutes to download one way is pretty good. If you're using standard consumer-grade broadband, your upload limit is probably capped way lower than your download speed, so that'd be the limiting factor.
Of course they have limits though. I think the PipeBytes "no limit" thing is a gimmick to get attention for the time-being.
The "no limit" thing makes sense when you consider that all PipeBytes does is negotiate a peer-to-peer transfer then backs out of the process.
My understanding is that you are not uploading to their servers at any time. Think of it as an easy two-computer BitTorrent session, utilizing some browser-based code to do the heavy lifting.
Thus, no reason for them to impose limits, and no worries about what you're transmitting... since the file is never on their hardware, they're never hosting it, and thus avoid prosecution for potential copyright violations.
RapidShare and other services *do* store the file, even if for a limited time. And many of the free sites impose stupid user tricks on the experience, like making you wait for a queue position.
I'm not saying PipeBytes is wonderful; I hardly know them. But it's certainly different than anything else I've seen out there. Even if they're out of business in six months it's an interesting approach to a common need.
