Trillian users hog RSS bandwidth

Publishers who use RSS should take a look at how Trillian Pro users are checking your newsfeeds.

Trillian Pro is an instant messaging client for Windows that can be extended with plug-ins to support other kinds of information. There's a popular RSS 0.9x plug-in. The software breaks the once-per-hour standard adopted by most RSS readers, but I haven't determined yet if this is by default or set by each user. One of my RSS feeds is being checked by a Trillian Pro user twice an hour. Another feed is being checked every five minutes -- 264 times a day. It won't take many users like that before it becomes a problem.


It's funny, Trillian also floods AOL Instant Messenger servers with completely unnecessary "not idle" updates, which causes your user info to be sent to everyone on your buddy list every minute, instead of just upon changes.

I just booted up my copy of trillian 2.0 pro, the default refresh of the RSS feed reader (0.9x) is 1800 seconds which is... 30 mins.

PS its user setable

Thanks for the update. RSS-consuming software should not allow users to check more than once an hour (at least not without warning them about what producers might think). It's possible I'll change my site to disallow Trillian requests.

I don't understand why you're so concerned about the frequent pulls - how is this different from folks who sit at a desk compulsively reloading, say, a dynamic web forum page every 30 seconds (a behavior you should be well acquainted with)? Is the RSS processing so heavy on the server that it threatens your stability with the frequent checks? Or are you just getting uptight about an unwritten community rule being violated?

If it's the server load, which I suspect it is, shouldn't everyone be looking into why XML processing is so expensive? I know I have got some great functionality / convenience out of using XML on the server side of web apps, but at a definite efficiency cost.

I'm not trying to troll - as an RSS community outsider / voyeur (neither producer or consumer) - I am honestly curious.

Humans may hammer a server for short periods, but message board zealots don't increase in number like RSS users -- I wouldn't be surprised if the growth is an exponential curve -- and they don't keep at it all day long.

That's why it was a bit alarming to see that the first subscriber to the Drudge Retort RSS feed was hitting it 264 times a day. If I'm serving a 15K RSS file and 10 more people like him show up, they'd eat 38 megabytes of bandwidth a day just to check a feed that might change five or six times on its most active day.

Ideally, your server software and hopefully Trillian should respect HTTP Conditional GET so even if you get all these requests, they'll result in a 304 (Not Modified) response. Beyond that, your server software and hopefully Trillian should support sending of GZIP'd content to reduce the total amount of content you're sending with each response. Beyond that, ban them if they're not respectful of a 1 hour polling period.

I have to agree with david, i personally think its a resonable default, as long as 304's work. granted 264 checks a day is excessive, and i agree here that that is just abuse, but banning all trillian uses due to one prat i think is OTT. although it doesn't to much worry me as i only run feeds from slashdot/theregister/theinquirer.

Surely other RSS readers allow you to set the polling period and therefor abuse the priviliage?

Trillian does not support conditional GET or GZIP.

I've only used two newsreaders, and neither one allowed me to increase the frequency of polling to more than once an hour.

"I've only used two newsreaders, and neither one allowed me to increase the frequency of polling to more than once an hour."

FeedDemon allows the user to set the polling frequency as high as once every five minutes.

Astro's right though -- the basic problem is that if you're concerned about bandwidth, RSS/whatever doesn't scale.

Add a Comment

All comments are moderated before publication. These HTML tags are permitted: <p>, <b>, <i>, <a>, and <blockquote>. This site is protected by reCAPTCHA (for which the Google Privacy Policy and Terms of Service apply).