Is AIM Really a Bandwidth Hog?
Crispen asks: "A mess of schools, especially K-12 schools in the US, have banned instant messaging, claiming that it is a huge bandwidth hog. Is it? If you block ports 4443 (images) and 5190 (file transfers), how much bandwidth does AIM really take?"
There's two main reasons we've taken to blocking any form of IM, or in fact anything that isn't HTTP/FTP, to student desktops. First, of course, is the somewhat limited bandwidth, although this was the least of our reasons. Secondly, and far more importantly, is the element of control: with a transparent proxy through which all HTTP and FTP traffic is routed, we can (a) cut down the amount of input bandwidth needed, and (b) implement a certain amount of filtering (well known porn sites, ads, etc).
Not having IM installed on each desktop also means that there's not configuration problems. Realistically schools have to support one environment, and IM systems, with the number that there are, complicate this no end (imagine the arguments if AIM is the only one supported by a school, but a large percentage of kids use MSN...).
Realistically, if kids want to use IM, they're welcome to do so at home on their own (usually dialup) time. Likewise with any other non-HTTP access. I personally don't see it at that disabling; if kids want to IM each other, they can go back to "pass-it-on" notes. :-)
I have a net admin friend at a school who helps manage the dorm network. Amazingly, he claims that it is really those tiny ads (150x40pix). I guess AIM is very lazy and is constantly refreshing them (If you're using the computer or not) and doesn't do much caching.
To fix it, they rerouted ads.aol.com (i just made up that DNS) to their own servers and sent their own images back localally.
It ain't hard to setup an FTP server at home, and most Universities (Colleges for the yanks) allow FTP access to their students.
Why not just use that?
Because FTP isn't designed for this. FTP is great if you have an always-on machine at the same IP (or at least hostname). It was originally designed to let a user work with files in *his* account's disk space.
AIM and other IM programs with file-transfer capabilites are far better suited to most home users. The IP of the user may change. The user may only come online at some time. The remote user is made aware of this ("Oh, John's on. I can send him that presentation file."), since an IM program handles registering and retransmitting this information.
Furthermore, FTP exposes a whole collection of directories, and generally (unless you hack things up) grants write and list access to *other* things in an upload directory. The user wants to make available a *single file*, and wants to know when the transfer is done, so that they can get offline. IM clients do a better job of providing this functionality than do FTP server/clients.
Often, file transfer is done at the same time people are talking to each other. This combines two frequently-used-together services, since an IM client would likely be necessary anyway.
Finally, even setting up an FTP system to approximate the model desired is *much* more work. You'd need a dynamic hostname, need to run a daemon to keep it up to date, the remote person would need to have a program that keeps trying to log in to tell when you're online, you'd need to set up permissions so that your server didn't let people see files that other people uploaded, you'd need some monitor for people logging in...
FTP was designed in an era where people didn't have goddamn filewalls or NAT all over. Frankly, they do now, and pose a major irritation if someone's trying to send a file. AIM is quite good at dealing with firewalls.
Also, FTP security sucks. Kerberized FTP is *very* rarely used, as is SSL-tunneled FTP. Plaintext passwords...not even MD5 support. Ick. Granted, most popular messaging protocols aren't much better, but they are improving.
So while FTP is better for the task that it was designed for, for the kind of thing this guy is doing, he's better off with IM.
May we never see th