AOL runs a service called AIM, AOL Instant Messenger. It provides almost real time text communication between users of AIM clients. Full AIM service for clients supported by AOL currently includes a number of features such as file transfer, warning and blocking of abusive users, setting away messages and user info, maintaining a contact ("buddy") list, and so on. This system coexists and is completely incompatible with other chat systems such as IRC and ICQ.

Full AIM clients use a a protocol called OSCAR (Open System for Communication in Realtime). This is a binary protocol and contrary to what the name implies, it is closed. There is an AIM client built into the AOL program itself, but users need not use AOL to use AIM. AOL provides free of charge (but not free of advertisements) fully functioning clients for Windows and Macintosh users. Unfortunately, for UN*X users, until a year and a half ago it had only provided a buggy, slow Java client. This client was the source of many headaches because it had to be downloaded for each use and it had a tendency to crash in strange ways. Then in September 1998, AIM released an new protocol for instant messaging along with a beta Linux client. This protocol was called TOC, was string based, and to many people's surprise, was released under the GNU General Public License. TOC is much easier to use and has allowed numerous Linux based clients to be written without the need of reverse engineering. TOC does not replace OSCAR, rather, TOC servers act as a proxies for OSCAR, making life for the clients much easier.


The main protocol that drives AIM is called OSCAR. While it is a closed, binary protocol, people have managed to reverse engineer it and write Linux clients such as is FAIM and LAIM (LAIM's An Instant Messenjer[sic]). Since the various AIM services (BOS [Basic OSCAR Service], chat and advertisement, for example) exist on seperate servers, OSCAR uses a "single-login" concept for connecting. First the client connects to the authorization server,, and sends it information about the nature of the connection it wants. This includes buddy list and permit/deny information. The authorization server sends the client back a cookie which then may be used to connect to the various other servers. A more detailed description of the login procedure can be found on FAIM's site.

OSCAR uses TCP and has a special header for all its commands called a FLAP (if this is an acronym, no one has bothered to define it). Because FLAP is a higher level protocol than TCP, there may be multiple commands per packet or a command spread out over more than one packet. FLAP headers are always six bytes long and are summarized as follows:

Offset Function
0      Command start: always 0x2a '*'  
1      Frame type 0x01 through 0x05 
2      Sequence number, 2 byte word 
4      Data length, 2 byte word

Frame Types are:  
0x01   Signon 
0x02   Data 
0x03   Error 
0x04   Signoff 

Sequence numbers may start at any number and are incremented for each command and on reaching 0xFFFF they wrap around to 0x0000. The sequence numbers used for the client to server communication have no relationship to those used for the server to client communication. If a server receives a sequence number out of order, it will disconnect the client.

Frame type 0x02 contains a data type called SNAC (like FLAP, this is also undefined), which has a number of headers and a variable length data field. There are a large number of SNAC types, the ones which have been successfully decoded can be found at on FAIM's site at the FAIM web site. For example, normal IM communication is headed with 0x0004 (Messaging) 0x0006 (send message), two unused single byte flags and a 4 byte unused request ID.

No strings in this protocol suite are null terminated, so all end location must be determined by the length data fields.


In late September 1998, AOL released a new protocol for instant messaging called TOC. This protocol is open, released under the GNU General Public License, and string based. Along with this protocol they released a Tcl/Tk client called TiK. Currently, AOL no longer supports TiK, and it is [was?] being maintained privately here. Since its release, a number of other TOC clients have been written for Linux, the most popular of which is Gaim (also available is [was?] kit).

Note: Attempts at expanding TOC have yielded is TOC to OSCAR and Talk to OSCAR. The best we have for TiK is TOC is Kool.

TOC is a subset of OSCAR. All TOC commands also appear in OSCAR, but there are some OSCAR commands not implemented in TOC. For example, commands such as file transfer have been implemented in official clients but are not part of TOC. TOC uses strings for most of its communication, but it still requires each command to have an SFLAP header. There seem to only be a few differences between FLAP and SFLAP. SFLAP includes the frame type 0x05 "keep alive" which OSCAR may or may not use, and SFLAP does not use frame types 0x03 and 0x04, "error" and "signoff". Additionally, the client to server communication for frame type 0x02 (data) and some other communication, is null terminated, though the host to client communication is not. By reading the PROTOCOL file included with TiK, which is claimed to contain all the information anyone needs to write a client, it is clear that AOL expended no special effort to make writing clients an easy process (or to make their documentation grammatical). Careful decoding of this file and experiment have uncovered the actual method of doing things detailed in "how to sign on".

Once you are signed in the protocol provides a large number of commands which involve sending and receiving messages, managing your buddy list, warning people who bother you, managing chat rooms, reformatting your username (see normalization), changing your password, searching for other users, etc. The PROTOCOL file is more clear about the use of these commands than it is about signing on. Since in general, the client and server use completely different formats for their communication, special care must be paid to the parsing of commands. The only catches for client to server communication are to remember to put quotes around arguments that include spaces and to use a backspace before dollar signs, square brackets, parentheses, quotes and backslashes. Server to client communication does not encode in this manner, instead, it only allows confusing characters to exist in the last field of each command, where their purpose as plaintext is obvious. It is worth noting that although the protocol only mentions HTML for use in info and away messages, it is commonly used and interpreted in normal messages.

For example, to send a message, your frame should be:

FLAP header (frame type 0x02), null terminated string "toc_send_im <destination user's normalized name> "Message where you use \"a quotation\" you talk about M\$""

And you should expect your incoming IM's to be in the form:

FLAP header (0x01), "IM_IN:<source user's name, formatted>:<Is auto-response? T or F>:<message, unencoded (no escape sequences)>" [not null terminated]

History and the Future

AOL released TOC under GPL in March 1999. In July of the same year, it withdrew TOC from its status as an open protocol and changed it slightly to prevent Microsoft clients from connecting. This move was protested by open source advocates who noted that GPL has no termination clause. Microsoft quickly modified their client to allow it to connect using the modified protocol. In September 1999 Microsoft wrote an OSCAR client that successfully connected to AOL servers. AOL soon discovered that it could use a buffer overflow bug in its own client to detect which client was connecting and used this to deny Microsoft clients access. By November, Microsoft announced its surrender, saying it would not continue for security reasons. In December, AT&T also released an AIM client, and it was almost immediately blocked by AOL. AOL has never made any efforts to block clients, such as FAIM, which are not made by competitors.

In response to this game of AOL's and the general chaos surrounding messaging protocols, there has been a call for a unified standard. While no RFC has yet been issued, the problem is being worked on and the proposed standard will be called the Instant Messaging and Presence Protocol. Memos issued by the IETF working group can be found on their site. However, whether a useful standard emerges depends not only on the resourcefulness of the IETF, but also on the willingness of the various corporations currently using proprietary protocols to support the new standard.

Page by Matthew Strait
Last (seriously) edited: March 2000
Last HTML update: 7 Jan 2008