| Communication protocol | |
| Purpose | Instant messaging |
|---|---|
| Developer(s) | AOL |
| Website | dev.aol.com/aim/oscar at theWayback Machine (archived 2008-03-08) |
Open System for Communication in Realtime (OSCAR) isAOL'sproprietaryinstant messaging andpresence informationprotocol. It was used by AOL'sAIM instant messaging system andICQ.
Despite its name, the specifications for the protocol remain proprietary. AOL has gone to great lengths to keep competitors (namelyMicrosoft,XMPP, and Cerulean Studios) from implementing compatible clients for their proprietary messaging systems.[1][2] In 2002, AOL signed a contract withApple, Inc., allowing them to use OSCAR (as well as AOL's own code libraries) in theiriChat application. This allowed iChat users to interact with ICQ and AIM users directly. The deal also permitted users of Apple's.Mac service tolog in to the AIM network using their .Mac email addresses. (This has carried over to Apple'sMobileMe service.)
As of 2009[update], large parts of the protocol had beenreverse-engineered and implemented by a number of third-party clients.
The OSCAR protocol can be used separately from AOL's network. In fact, AOL expands on the general concept of OSCAR, adding systems for service-side buddy lists and icons, as well as features for file transfers usingBonjour.
On March 6, 2006, AOL released the AIMSDK and launched a developer website, allowing developers to build plugins forAIM Triton, and build their own custom clients, which connect over the OSCAR protocol. They had not, at that point, however, released any information about the protocol itself.
On March 5, 2008, AOL released portions of the OSCAR protocol documentation. Google also provided the ability to sign in to AIM network via theGoogle Talk client built intoGmail.
All packets sent over OSCAR are encapsulated in the same manner. All 16-bit integers sent over the network are unsigned, and big endian (seeEndianness.) This is the same for 32-bit integers, and 8-bit integers (or bytes.)
A special Frame Layer Protocol (FLAP[3]) container encloses every packet. It carries information about packet size, channel, and its number in sequence.
| Offset (hex) | Field | Type/Size (in bytes) | Remarks |
|---|---|---|---|
| 00 | FLAP ID | byte/1 | Always equal to 2A. It marks the start of the packet. |
| 01 | Channel | byte/1 | 1 = login, 2 = SNAC layer, 3 = error, 4 = disconnect |
| 02 | Number in sequence | int16/2 | Incremented by 1 each time a packet is sent. Wraps to 0 after FFFF. |
| 04 | Data size | int16/2 | Size does not include FLAP header |
Within almost every packet sent over channel 2, packets contain a SNAC (Simple Network Atomic Communication). There is always either one or zero of these contained in a packet, and therefore they do not contain (nor do they need to) a length.
| Offset (hex) | Field | Type/Size (in bytes) | Remarks |
|---|---|---|---|
| 00 | Foodgroup | int16/2 | The general type of the packet |
| 02 | Type | int16/2 | The specific type of the packet |
| 04 | Flags | int16/2 | |
| 06 | Request ID | int32/4 | A request ID, this can be random but clients cannot send this with the Highest Order Bit set. |