Slashdot Mirror
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?"
As Manager of Technology for a school system, we made the decision to shut down all AIM ports because there is currently no way to monitor, filter, or track instant messages that go across it. Local, state, and even federal programs require that we monitor and filter all Internet access by minors. After having some incidents with AIM (including a bomb threat that AOL would not trace for us, even with a search warrant from the FBI), we shut down all Internet-based instant messaging programs.
.. especially in these days of cheap bandwidth for education (we have a full DS3 45Mbps for a 7500 student district). The liability of having Internet traffic that is basically untraceable without a sniffer is something we can't have.
The bandwidth use is negligible
Jason
"FORMAT C:" - Kills bugs dead!
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. :-)
Nonsense. You can change the port to almost whatever port you want. login.oscar.aol.com listens on 1600 different ports, all with the same service. Try one, like say, port 80. Watch your network with tcpdump. You won't see anything on port 5190, and AIM will work just fine.
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.
Now before you go on about emailing my files, my college had the myopic foresight to limit email to 5 megs per attachment. My senior thesis was over 19 megs and my thesis advisor couldn't figure out how to open it after I split the files into email sized pieces. Turns out he didn't have winzip but that's another story. Make a long story short, his computer didn't have AIM and I had to turn a hard copy in late.
Once AIM caught on we had files going in and out of the department all the time. Students began collaborating on AIM. This was a commuter college and students HATE collaborating. AIM takes some of the sting out of having to drive in at the one awkward time when everyone can meet.
I can understand schools wanting to control net access but there are better ways to go about doing it. How many naughty files slip through the filters anyway. Blocking AIM isn't going to stop a determined kid but it will chill an effective means of communication between students and the school.
At the rate some schools are going all those computers will turn into nothing more then a complicated Cable TV system attached to a word processor.
I've hit Karma 50 and gotten a Score:5, Troll... I win!
Before our campus moved to a fully switched LAN, I used to use Ethereal to sniff my whole dorm's AIM traffic in real time. 80 people, not that much traffic. Even in the evening at peak utilization it was easy to keep up with, no worse than a busy IRC channel. So IMO AIM is not a bandwidth hog.
The protocol itself is not as efficient as it COULD be. I did notice occasional repeated messages, and signon/signoff messages are repeated frequently. But we're still talking about piffiling small bandwidth.
PS I'm just kidding and I didn't actually do anything that I've described in this post. By reading this post you agree that I didn't run a sniffer, or reverse engineer AIM's protocol just by watching it's traffic in a sniffer.
-73, de n1ywb
www.n1ywb.com
Sure lets block email too! Email costs productivity!
I used IM and EMail regularly throughout the day to communicate with my teachers and fellow students. My productivity would take a big dump without either technology. If I lost both, well fuck I might have to use a telephone! Hey everybody lets ban all forms of communication other than written mail! Wake up.
Using AIM during a lecture is a totally different problem and shouldn't require BANNING it from the lab. IMNSHO it's no different from using a CELL PHONE during a lecture and the teacher should deal with the problem accordingly. And if it's a lab where people are typing anyway and the teacher can't tell that the student is IMing then who cares? Students aren't robots and you can't FORCE them to learn no matter how hard you try. If they can IM in lab and still pass then more power to 'em. If they fail then too damn bad, it's their own damn fault.
-73, de n1ywb
www.n1ywb.com
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