Loading ...
Sorry, an error occurred while loading the content.

7233Re: [radio-dev] BitTorrent for Blogs

Expand Messages
  • Jeremy Bowers
    Nov 30, 2002
    • 0 Attachment
      On Sat, 2002-11-30 at 13:07, Jeremy Bowers wrote:
      > So, can it help with RSS? Recall that while the furor over bandwidth
      > consumption has died down, that may yet be temporary, as all
      > improvements to date are just linear and will someday also be
      > overpowered. My answer to that one is a qualified "no".

      A little more thought shows that with a slight adjustment to the
      protocol (since it is open) signficant RSS benefit could be obtained.
      Since we can kind of count on the BitTorrent app being open long-term,
      we could make the following changes:

      * The Tracker elects some "trusted nodes", based on connectivity, some
      randomness, and the total activity of the file.
      * When a client downloads an RSS file for the first time, the Tracker
      sends down some part of the trusted node list (two or three random
      * The Tracker notifies the trusted nodes when the file changes (which is
      also an opportunity to update the trusted node list, if they don't
      * The clients ask the trusted nodes whether the file has changed,
      instead of asking the server directly. Since we're talking about leaving
      things open, we can also try to cache what other nodes are available and
      only ask the Tracker for other available nodes to share from if the
      client runs out of connected nodes.

      With this slight change, one request to the main web server (which is
      the bandwidth that we are really worried about) can result in multiple
      RSS files being transferred, as long as the trusted nodes are
      well-behaved. Depending on how well-behaved, the trusted nodes may be
      able to act as a server proxy for many hours or even days. This *is* an
      actual qualitative improvement to RSS serving, as the burden on the main
      server goes to one hit per *consumer* plus a log(consumer) maintainence
      fee, based on how well-behaved the trusted nodes are and how much we fan
      the duties out. (In constrast to the current one hit per consumer per
      update.... essentially going from n^2 to n log n.)
    • Show all 2 messages in this topic