So now we get to the purpose of this whole thing: messaging. Instant messages are strings of ASCII codes that get sent in very-near-real-time between users of the Basic OSCAR Service (BOS). At no time does one client directly locate another client, or even know the location of any other client. All messages are sent to the message server, which then relays them to their destination client(s).
The text of a message is usually in the form of an HTML-like encoding that AOL calls "text/x-aol-rtf" (MIME format notation). For all intents and purposes, it's a subset of HTML. But, just like with HTML, you don't have to use HTML to be HTML. Sending straight ASCII text works just fine as well. The AOL-sourced AIM clients always use HTML even if you don't type or use any. They will usually append at least the <HTML>, <BODY>, and <FONT> tags (and their appropriate closing tags) even if you didn't intend to use any. The server does not touch the message at all.
Sending and receiving instant messages (from now on called IMs), is really quite simple. There are some things that can make it go funny, though. I don't have all those things documented yet.
7.1 Sending IMs
Below is the command structure for the "Send IM" command. I have found, that depending on which message server you end up with, you may have problems when using the command structure defined below. I can't explain this behavior, but it has happened a couple of times before. Just logging out and then back in again (usually getting another server) lets you send messages just fine. Also, changing some of the fields of this command can still get it through the server, but the distant-end client will fail (actually, I've found several combinations that crash the AIM Java client quite messily). Just use with care.
Fig 7.1.1 Send IM Command (Family 0x02)
7.1.1 Errors Dealing with "Send IM" Command
|11||DWord||Unknown Purpose (leave as 0x00s)|
|17||Byte||Destination SN Length|
|18||ASCII String||Destination SN (unterminated)|
|21||Word||Message Length + 0x0D|
|30||Word||Message Length + 0x04|
|35||ASCII String||Message (unterminated)|
7.2 Receiving IMs
Receiving IMs is gernerally quite simple. The same member information that comes in the "oncoming buddy" command (see figure 5.1.1) is sent here, in the same format and same order. And because of that, the space between the SN and the start of the message will be variable depending on the class of the source SN.
Fig 7.2.1 Incoming IM Command (Family 0x02)
7.2.1 Errors Associated with Receiving IMs
|23||ASCII String||Source Screen Name|
|24*||Word||Warning Level of Sender|
|26*||Word||Class Part One|
|32*||Word||Class Part Two|
|38*||DWord||Member Since date|
|44*||DWord||On Since date|
|56||Word||Message length + 0x0D|
|65||Word||Message Length + 0x04|
|71||ASCII String||Message (unterminated)|
|* Not present for commands from AOL members|
|+ See notes in section 5.1 on these fields (they're the same)|