konspire logo the power of broadcast
[a revolution in mass-scale content distribution]
main
download
[features]
channels
start a channel
recommendations
k2b_measure
hostKatcher
[docs]
the revolution
how k2b works
results
faq
k2b is like...
other systems
BitTorrent?
[community]
foundation
forums
wiki
skins
[dev]
bugs
developers
project page
coding credits
[donate]

hosted by:
SourceForge Logo
visit:
infoAnarchy Logo

Why not BitTorrent

main page | recent changes | preferences

Difference (from prior minor revision) (no other diffs)

Added: 9a10,11
Random two cents on above question
The two are not mutually exclusive per se. As they get around to releasing the k2b API to write your own apps using the kast push technology, you could theoretically write software to harness the power of both. You could use kast to get your new content out quickly and automatically to your subscribers. Then, knowing at least some of your subscribers probably still have your old broadcasts, you could have built in BitTorrent hosting in your version of the program to allow people to retrieve old broadcasts without having to ask you to rebroadcast each file.

Added: 13a16,18

One Guys Random Two Cent Answer
There is no real battle here. Us technology minded people are always having to place a fight between two technologies that seem even remotely similar.

Question: Why not use bittorrent al together, concentrate on building the Trust&Distribution and leave filetransfer to bittorrent. (I suspect Not-Invented-Here syndrome is an important factor but I see no reason not to use Bittorrent) /Erik

Answer:

BitTorrent is is a demand-base swarming distribution system. To receive a file with BitTorrent, you connect to the file's original owner, receive a "map file" that describes hashes of each file chunk, and try to download chunks from peer downloaders that already have them. If you have only one downloader per day (or per hour, etc.) seeking your file, you'll still end up serving the file to each one directly, chewing up your bandwidth day after day. k2b is completely sender-driven and is targetted at short-term, "zero-day" distribution. It forces a new model for sender/receiver interaction, and in doing so, it gives more precise guarantees about bandwidth usage. k2b and BitTorrent may be attacking the same problem, but they're attacking it completely different ways.

The description above isn't quite accurate. In the case of k2bitorrent, the 'serving' would be done by 'subscribers' who have already gotten the file, which is _already_ true in the current k2b model, and would also be a valid method of passing the file on, rather than the log method. My sincere suggestion: code it up with _both_ options: the log scaling method used now _and_ the bittorrent method, and see which scales better in the real world tests. For large bandwidth files, I suspect the bittorrent method might work better, assuming that _subscribing_ equals _sharing_. That is the main _flaw_ in BT: many people stop sharing right after they complete, and the seeder is left as the primary source for the file as you complain about.

Random two cents on above question The two are not mutually exclusive per se. As they get around to releasing the k2b API to write your own apps using the kast push technology, you could theoretically write software to harness the power of both. You could use kast to get your new content out quickly and automatically to your subscribers. Then, knowing at least some of your subscribers probably still have your old broadcasts, you could have built in BitTorrent hosting in your version of the program to allow people to retrieve old broadcasts without having to ask you to rebroadcast each file.

Question 2: You actually say that k2b and bittorrent are good for zero-day delivery, but the battle is between the diffrence in p2p transfer models. Ok this is way over my head, but I said that perhaps concentrating on the "fun" part was the most intresting.. ;-)

One Guys Random Two Cent Answer There is no real battle here. Us technology minded people are always having to place a fight between two technologies that seem even remotely similar.


main page | recent changes | preferences
edit text of this page | view other revisions
Last edited June 11, 2003 3:10 pm (diff)
search: