FeedTree

FeedTree tackles the problem of server load in RSS feeds. When clients subscribe to an RSS feed they poll the server periodically (typically once every 1/2 hour) to get the last updates. This polling, when it comes from many clients, in addition to the tendency of the server to always send the last lines even when there wasn't an update (to prevent calculations), cause a load on the server and do not scale well beyond a few thousands of subscribers.

The authors turn to the direction of P2P cooperative RSS. This scheme involves the Scribe multicast system to forward updates from the RSS server to the interested clients. The clients subscribe to the feed in the usual Scribe way.

Using the Scribe system should (theoretically) take care of churn - joining and leaving clients. However, a client might miss out on a feed due to it being disconnected for a time from the network (e.g. a dial-up user). In these cases, the user will get the updated feed straight from the RSS server, exactly like today. The load on the server will be less than today so it should not be a scalability-inhibiting issue (again - theoretically. It might depend on the number of dial-up users and their connection patterns)...

Open issues:

• Using Scribe means that clients who are uninterested in a specific RSS feed might still have to forward updates to the subscribed clients. This can be solved by using "polite" techniques such as the one suggested in the Subscribe/Volunteer trees article.
• Contacting the RSS server after being disconnected might form a scalability issue. Hence, persistent storage methods could be employed to keep RSS updates available without contacting the main server.
• Incentives for participating users should be thought out. According to the authors, the fact that RSS service would improve might be a sufficient "incentive", but the rational incentive might not be the most effective one in reality...