http://en.wikipedia.org/wiki/Baud

Matt, do you know what baud rate is? The baud rate is the fundamental unit used in communications and it is defined as bits/sec. The unit has been in use since the days of the 300 baud modems. When a web browser displays kilobytes/sec, the browser is the one breaking convention. When bits per second is advertised, that is the correct terminology. If that happens to be the bigger number, then all the better for the marketing department.

"We still have the basic issue of centralizing hosts vs decentralizing hosts."

Last time Matt, this is NOT centralized hosting. The web seed is there as a persistent and fast backup. When you have 10,000 people trying to get the file, they’re most likely not going to be touching the web seed.

"Also, correct me if I am wrong, but I do recall there being issues with extended duration TCP and/or FTP transfers, that there are things that can interrupt the connection."

There is no indication of TCP resets affecting FTP transfers.

Yet again, I’ll post from above since you somehow missed things I said. Also, notice my capitalization, I did not misinterpret terminology nor mathemetics. I was indeed deliberately denoting kilobytes and not bits. I get 40KB/s, and not 48. You and I both know why vendors use bytes/sec, its for sales psychology. Larger numbers = more. Basic obfuscation of fact.

We still have the basic issue of centralizing hosts vs decentralizing hosts. Having the information on one apparent comcast webserver would mean it is optimal for a certain specific group of people by area. What does that say for the rest of the country, let alone the world, who wishes to download said document? I forsee potential legal and technical issues arising out of this aspect.

Also, correct me if I am wrong, but I do recall there being issues with extended duration TCP and/or FTP transfers, that there are things that can interrupt the connection. Especially considering 1-2days to upload an orphan work of artistic value, for example.

You upload it to the web server using FTP or HTTP at full speed (whatever peak upstream you can get). This will never be reset and you’re only doing it once.

"40KB/s as mentioned for an upload (and vigorously advertised by comcast as 320 kb/s "WOW" factor) will still take an excessive amount of time for many legitimate independent works to reach a webserver"

40 KB/s is the same thing as 320 Kb/s. You might in reality get 384 Kb/s. It’s pretty standard for the networking people to quote bits/sec rather than bytes/sec. For whatever reason, application vendors choose to use bytes/sec and that has caused a lot of unnecessary confusion for consumers.

As for taking an excessive time to get to the web server and it is the same for any protocol you choose. Your problem is that you’ve bought the wrong technology if 384 Kbps isn’t suitable for you needs.

You do have the FREEDOM to buy a faster Broadband connection or a T1/T3 line to your house if you want the faster upload speeds.

To first state I don’t think that in any way this is a horrible idea, but I think it needs a lot of further refining and examination before expecting this to be a good solution. Sorry that things came out in a far more hostile fashion.

However, even if a file is encrypted and zipped (at which case safety is less of an issue), I fail to see that it still must be uploaded to the webserver at a slow rate (which they claim is .048, but its really .040 in most cases, but I’m just humorously nitpicking on that), and as said we’d be held to comcast’s decisions. If there happens to be a bad ruling in the court of law and comcast goes "damage control" for liabilities, all you get is a big "so sad, too bad", when your seed is removed. Nothing seems to cover who has the absolute authority over the file.

We still have the basic issue of centralizing hosts vs decentralizing hosts. Having the information on one apparent comcast webserver would mean it is optimal for a certain specific group of people by area. What does that say for the rest of the country, let alone the world, who wishes to download said document? I forsee potential legal and technical issues arising out of this aspect.

I do agree that an ISP offering to take over the bandwidth resource costs of distribution is a good thing. I also agree with yours and robs statements that (in my own wording here) its basically the equivalent of being rented for free someone else’s server, per-se…in terms of that you don’t have to manage things as much..

I do understand the benefits of this technology, even if you seemed to interpret otherwise from my comment. The "let someone with more bandwidth resources" handle the connection is fine. However the "how the heck do I get it to them in the first place" still remains, in terms of upload capacity. 40KB/s as mentioned for an upload (and vigorously advertised by comcast as 320 kb/s "WOW" factor) will still take an excessive amount of time for many legitimate independent works to reach a webserver, such as audio and video recording, theatrical works, etc.

Not uploading constantly and not having to baby sit continuously is the whole point of web seeding. Even if that web server only allocates 40 KB/sec per file, it’s as good as a fulltime dedicated seeder.

Now I ran the web seed test for the da Vinci file multiple times and every time the web seed did contribute most of the bandwidth even though there were 12 other seeders. It would seem that backing this file up with a web seed made it a whole lot more popular than the P2P version. It would probably help even more if the file was compressed, but I didn’t do that because I wanted an exact comparison with the pure P2P version.