Turning Off a Radio UserLand Scripter

Last June, I published a 23-minute podcast of Juan Cole being interviewed on the Alan Colmes radio show.

A Radio UserLand user on Comcast in Monterey, Calif., is apparently a big fan of Cole. His copy of Radio keeps requesting that 5.5-megabyte podcast over and over, as frequently as every 10 seconds. In the last week alone, he's consumed 12.13 gigabytes of my server's bandwidth by downloading the file 2,365 times.

I don't know why this is happening -- it could be a bug in Radio UserLand or a UserTalk script run amok, either by accident or by design. The fact that it's coming from a fixed IP address suggests it's not malicious.

I renamed the audio file and blocked the offending address with iptables:

The problem illustrates an aspect of Radio and the OPML Editor that casual users should keep in mind when they begin writing scripts in these programming environments. You need to know exactly what the script's doing, especially when you schedule it to run regularly.

These repeated downloads amount to a denial of service attack, and the 56 gigabytes of traffic he's consuming per month is larger than the transfer limit on many servers, subjecting the publisher to excess bandwidth charges.

If this user needs to learn how to write scripts in Radio, there's a book I can recommend.


Heh. Heh. Yeah, it can be a problem. I think automatically throttling things on a per IP basis might be helpful

I note that you were a lot nicer about it then some people have been. I remember when Mark Pilgirm banned someone: diveintomark.org

He was a real ass about it. Then again what do I expect from the guy who gave the world the MBDF virus. www.rbs2.com

What's the deal with all of the Mark Pilgrim comments today, here and elsewhere?

The guy seems to be on my mind for some crazy reason.


The code in Radio's aggregator doesn't handle errors well. It's likely that the user doesn't even know what's going on. I had to handle something like that once myself where it wouldn't download a file, coincidentally on your server. Digging in to it, it was the 255 character string limit in the kernel--the remote URL was very long, likely causing the error.


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).