Slashdot Mirror
AOL vs. Trillian
Trinition writes: "ZDNews is reporting that AOL is once again trying to shut out the competition. Trillian has been updated twice in the past 24 hours to work around the blocks AOL is throwing up to prevent the popular IM client from interoperating with the AOL Instant Messenger service. Will Cerulean Studios hold up better than those they follow in the footsteps of (i.e. Microsoft, AT&T and Jabber)?"
I'm not sure of the current status of the application, but AOL has been doing the same thing to the OS X application Fire (a multi network IM client). Ever since it's release it's been a game of AOL blocking and subsequent update "fixing" the block,
Seems to me that all this extra programming is wasted cycles that could be better used for additional features for applications.
This is one area where greed is holding back innovation in the IM market.
Trillian is a very nice client - we use it almost exclusively here at work, as it lets us keep in contact with people using multiple IM platforms, and also doesn't ram ads down our throats.
One interesting thing is that the new AIM blocks only seem to affect Trillian v0.7x - some of our users still using v0.6x are still working fine, whereas us early adopters are having to update rapidly.
Luckily, the newest (v0.721) build includes an auto update function, so keeping up to date is likely to be much easier in the future. Bear in mind that there's a limit to how much AOL can do to break the protocols, as they don't want to shut out all of their previous clients.
how the hell is it a monopoly? is MSN messenger just a figment of my imagination?
they spent R&D money developing AIM, testing it, promoting it, upgrading it, etc. why in the hell should they be forced to open it up to people who want to piggyback on it? that's total and utter bullshit, and one of the things i can't stand about the slashdot crowd. .
gotta have everything, who cares if they spent a chunk of change and man-hours working on it, i want it, so it should be free and everyone should be able to use it.
BilldaCat
1. They added an overlay protocol, TIC-TOC, to allow interoperability (although, very limited, and not kept up-to-date).
2. The FCC ordered them to demonstrate iteroperability. They chose their victim.. I mean, partner, to be some dot-com that is now bankrupt and defunct (nice loop-hole spotting, AOL!). I'm trying to find links on this to back this up, and I'll post them here when I find them (just couldn't let this go unanswered).
3. AOL accepts e-mail from non-AOL SMTP servers. These e-mails traverse the AOL network, tying up their resources, and ultimately being converted into some AOL format for display in AOL. Why don't they block that? Oh, because it adds value to AOL by allowing its users to interoperate with the rest of the world. The difference with IM is that AOL owns 90% of that world (ICQ & AOL), so they don't see any value added.
For the millionth time, AOL is not preventing 3rd party clients from interoperating with the AOL Instant Messenger system. What they are doing is preventing 3rd party clients from using OSCAR, which is AOL's "private" protocol for AIM. They're not touching TOC, which is the protocol which AOL makes available for 3rd party clients to use.
Sure, flame me because:
1) TOC doesn't have all the features of OSCAR
2) TOC (might) use more resources than OSCAR on AOL's side, so you're doing them a favor.
3) AOL's required by the court to let us play in their sandbox.
4) AOL's a big bully.
5) Information wants to be free, man!
If AOL wants to make a subset of the features available to 3rd party clients, it's their prerogative. They own the servers, they wrote the service, they pay for the people to maintain the servers. And if TOC uses more resources than OSCAR on AOL's servers (which is just a rumor, and not confirmed from anyone with any authority), that's AOL's business, not yours. And no, AOL is not required by any court to let 3rd party clients play with AIM. They're only required to make the "next generation" AIM available to 3rd parties.
If you use OSCAR to connect to AIM and you don't use AOL's clients to do it, you don't get to complain when they change OSCAR around, regardless of whether they're deliberately blocking someone or just making modifications to the protocol for something else. Use TOC, or use another IM service.
-Todd
"The details of my life are quite inconsequential..."
The FCC ordered them to demonstrate iteroperability. They chose their victim.. I mean, partner, to be some dot-com that is now bankrupt and defunct (nice loop-hole spotting, AOL!). I'm trying to find links on this to back this up, and I'll post them here when I find them (just couldn't let this go unanswered).
Keep looking because you are wrong. Here is a link. The FCC only forces them to demonstrate interoperability of advanced IM services which includes Video conferencing and the such. Nothing was set about regular IM. Of course, this agreement lasts for only 5 years and can change at any time.
The main problem with AIM and Jabber is not the protocol, but AOL blocking the IP Address of Jabber's AIM transport. If it's moved to a new IP, it's usually blocked in a matter of only hours.
Apparently they notice when hundreds of client connections are coming off one IP Address, no problems.
Can anyone explain to me how AOL is changing their protocol without breaking their own IM?
I don't work for AOL or CeruleanStudios, so what I'm stating here are my asumptions.
I think that the first thing that AOL did was to analyze the data. If they found a Trillian SecrureIM package, then disconnect the user. This is why disabling SecureIM solved the problem at first.
I'm not sure what happened in the second step, but one theory is that they started checking the version number submitted in the Authentication request(or something similar).
Right now, Trillian seems to be working (Version 0.721). However, I believe that AIM has a CRC capability. The server will send a CRC request to the client with an offset and a length argument. The client will CRC the number of bytes specified by length starting from the specified offset, and send back the result. If the CRC doesn't match, then disconnect the user. It would be very hard to reverse-engineer the CRC algorithm. I believe that this is how Jabber was stopped in the end.