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
nodes).
* 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
respond).
* 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.)