[a revolution in mass-scale content distribution]
|
|
the power of broadcast
[a revolution in mass-scale content distribution] |
|
how konspire2b works this page provides a high-level description of how the konspire2b system works. To make the description clear, we will build it on top of the following imaginary scenario: alice owns a channel called "cydonia", and she broadcasts a file called "theGrid.mpg" (512 MiB) on her channel. broadcasts and prebroadcasts when alice initiates the broadcast, her node first sends out prebroadcasts. Prebroadcasts are announcements for content. Using prebroadcasts, alice's node essentially says, "i'm about to send theGrid.mpg out on cydonia. Who wants it?". Her node sends prebroadcasts to all of its immediate neighbors in the network, and these neighbors forward it to all of their neighbors, etc. Lots of nodes in the network get this prebroadcast, and the path the prebroadcasts travel look something like this: 
some of the nodes that get this prebroadcast are subscribed to cydonia and want theGrid.mpg---they are marked with red. These nodes are sinks for the content that alice's node is currently sourcing, and they respond by sending back a prebroadcast response. These responses are routed back to alice's node along paths that look something like this: 
alice's node picks one of these sinks and sends theGrid.mpg directly to it, which looks something like this: 
now two nodes in the network are sources for theGrid.mpg, and they can both start sending out prebroadcasts, which may reach more nodes than the first prebroadcast. These prebroadcast travel along paths that looks something like this: 
again, prebroadcast responses are routed back to both source nodes. Each node picks one of the responding sinks and sends theGrid.mpg directly to it, which looks something like this: 
now four nodes in the network are sources for theGrid.mpg, and they can both start sending out prebroadcasts, which may reach more nodes than the first prebroadcast. This process continues as long as there are still nodes in the network that want theGrid.mpg. Eventually, all sink nodes reachable from alice's node will receive theGrid.mpg; when this happens, alice's node stops sending out prebroadcasts and terminates the broadcast process. Though alice's node is finished, other nodes in the network may still be delivering theGrid.mpg to the remaining sink nodes. In the end, alice's node only delivers theGrid.mpg to a small number of nodes, and the load of the file delivery is shared evenly among the nodes that want the file. The final distribution tree, once the broadcast process has terminated throughout the network, might look something like this: 
orange nodes receive theGrid.mpg first, red nodes second, magenta nodes third, and blue nodes last. theGrid.mpg is a large file (512 MiB, as mentioned above). Suppose that given the network bandwidth that the nodes have, it would take one hour for one node in the network to transfer theGrid.mpg to another node. Using konspire2b, alice has managed to deliver theGrid.mpg to all nine nodes that want it in only four hours, and her node was only occupied for three hours. If alice had tried to send theGrid.mpg to each node directly, her node would have been occupied for nine hours, and the last node to receive theGrid.mpg would have received it nine hours after alice started to send it. alice saved six hours by using konspire2b, and she has saved some of her receivers five hours, even in such a small network. These exponential time and bandwidth savings become even more significant in larger networks. security and trust to create the channel cydonia, alice generated a key for it and posted the receiver key to her web site. When the sink nodes in the network subscribed to cydonia, they downloaded alice's key. alice's node signed its prebroadcasts with her sender key, so when one of the subscribed nodes received the prebroadcast, it checked that it was really from alice before sending back a prebroadcast response. alice's node also signed the content of theGrid.mpg with her key---each receiver node checked that the content had not been tampered with before accepting it and becoming a source for it. in other words, broadcasts sent by someone pretending to be alice are stopped dead in their tracks and waste very little bandwidth in the system. receivers on the channel cydonia know that everything they receive on the channel was selected and sent by alice. In other words, alice is completely responsible and accountable for what goes out on her channel. Receivers build trust for alice over time: if she lets them down, they can unsubscribe from cydonia and stop receiving the files that she broadcasts. potential for anonymity receivers on the channel cydonia can build trust for alice without really knowing who she is: they feel certain that only the person with the sender key for cydonia is able to send broadcasts on the channel. receivers may have obtained the cydonia receiver key from a relatively untrusted, anonymous source (for example, a website residing on a free hosting service or a newsgroup posting)---they may not trust cydonia's owner at first. Over time, however, they will see the quality of the content sent out on cydonia and build a trust for the sender, whoever it is. anonymity of channel owners is possible even at a technical level, since it is difficult for a receiver in the network to tell which node originated a broadcast. Nodes cannot easily tell the difference between a node that originates a broadcast and a node that is simply passing on the broadcast originated by another node. a new user experience nodes that were offline when alice sent theGrid.mpg out on cydonia simply miss the broadcast. konspire2b does not allow receiver nodes to ask for a file to be resent after the broadcast is over. Of course, alice can resend theGrid.mpg again later on if she wants. konspire2b operates much like a radio system: if you miss the show, you miss it, unless the station decides to rebroadcast the show later. users in the konspire2b network interact in a different way than they would in another peer-to-peer network. Along with posting her key to the web, alice also posted a schedule of future broadcasts. For example, she indicated that she would broadcast theGrid.mpg on October 10, 2002, at 10:00pm. Of course, the broadcast took four hours to complete, so there was a grace period for any latecomers. aside from putting their nodes online during the time that the broadcast occurs, users do little else in order to receive alice's files on cydonia. In fact, during the broadcast of theGrid.mpg, most of the receiving users were asleep or away from their computers instead of staring at a progress bar while waiting for a download to complete. |
