There are a lot of ways to send large files online. One my favorites is Senduit from Davidville (the Tumblr guys), which I wrote about in April. I like its simplicity and how easy it is to use. Unfortunately, Senduit, which is built on the back of Amazon's Simple Storage Service, has a 100mb file limit and though speedy on the download, requires that the file first be fully uploaded before downloading can begin.
PipeBytes is a new service that cuts out the middle man. The service has no file size limits and lets recipients begin downloading before the file is finished uploading -- in fact, that file doesn't begin to upload until someone starts downloading on the other end. While files are being transferred, a YouTube video plays in the browser window to keep you occupied, and an animated status indicator shows you the progress of your transfer.
I was able to successfully send an 80mb MP3 file to Marshall Kirkpatrick via the service. Though we were both shown different videos, they seems uncannily matched content-wise to the file I was sending -- which was a DJ mix, and I was shown a video of a turntable routine. I'm not sure if PipeBytes read the file note I left, which mentioned what type of music the MP3 was, and tried to match up a like video or if it was a coincidence (I think I'd lean toward the latter).
It's not clear how PipeBytes works, but my guess is that the site is establishes a direct connection between the uploader and downloader. There are a few reasons I think this: 1. Your file doesn't start uploading until someone is downloading, 2. It can only send to one person at a time, 3. Their FAQ says files "are sent directly to your peer."
If that's the case, PipeBytes should be spending virtually nothing on bandwidth. Though it does raise some questions about the usefulness of the service. If all it is doing is establishing a direct connection, what is the advantage over doing the same thing via instant messenger, Skype, or IRC (DCC Send)? The advantage of file sending sites like Senduit is that they allow the downloader to get quicker speeds on their end as a result of getting the files through a faster pipe. Also, they are asynchronous, so uploader and downloader don't have to be online at the same time. When both of those advantages are removed, why not just use IM?
Comments
Subscribe to comments for this post OR Subscribe to comments for all Read/WriteWeb posts
couldn't one advantage be that it uses port 80, in terms of being blocked by firewalls?
Posted by: ryan | November 9, 2007 2:16 PM
From your description, I doubt it is a direct connection, which wouldn't be possible without Java or another browser plug-in. What they are doing is holding the HTTP connection open and waiting for the download to start, then once the download starts they just pipe the upload stream to the download stream. It is a clever solution, but it doesn't save them any money on bandwidth as you suggested.
And I do see it having some advantages, such as the one Ryan mentioned.
Posted by: Paul Butler | November 9, 2007 2:34 PM
@Paul: Thanks for the comment! You certainly seem to have a better handle on the technical aspects of this stuff than I do. Appreciate it. :)
Posted by: Josh Catone | November 9, 2007 3:15 PM
It's an interesting service.
It's not using p2p direct link, the sender is actually upload to a special web server and downloader is download from such special web server as well. The server bridge up the upload and download session, so no data storage will be required on server side, however bandwidth will be required.
This service is built on Amazon's EC2.
Posted by: robert | November 9, 2007 3:32 PM
If they are actually reading, as you imply, the content and or file that you send they might have some serious legal issues around contributory infringement as well as vicarious infringement if people start sending copyrighted material and they can knowingly track it yet fail to do anything about it.
Posted by: Boris M. Silver | November 9, 2007 5:22 PM
The idea of being able to start downloading the file before it has completed uploading is a nice concept.
Imagine uploading the file to a server for storage (as opposed to piping it directly to the recipient) - but providing the recipient with a torrent file instead of a plain link. If that were the case, you might be able to safely start downloading the file when only a portion of it has been successfully uploaded.
Al.
Posted by: Alistair | November 10, 2007 6:01 AM
Benchmarked the service by sending a 28 meg file to myself.
Using "Online Eye" as my thruput meter I (I opened two tabs in Firefox / one send / one receive. Groooooaaaannnnn way too slow. I was getting 14 KB (K Bytes) per second in each direction. I am on cox Cable and have gotten as much as 1 meg per second download speed and 200 K Bytes upload speed.
Time of test was 07:30 EST from Virginia Beach, Va.
bottom line - this thing is not really going to make it in the real world!
Posted by: Miles Levy | November 13, 2007 4:49 AM
is anybody sure that this works only via port 80(http)?
because i am behind a firewall and it doesen't work for me:(
plz a need an answer
Posted by: siegfried18 | November 13, 2007 3:18 PM
to Miles Levy: The problem is probably because you were trying to upload and download file from the same browser. all browsers have limit for simultaneous connections to same host. it is HTTP/1.1 limitation. Could you try the same thing with two different browsers? Thanks!
to siegfried18: it is definitely port 80. Could email your problem to pipebytes@pipebytes.com Thanks!
Posted by: Alex Sova | November 14, 2007 12:41 AM