Protocols/OSCAR/SNAC/BUDDY ARRIVED
| OSCAR Protocol |
| Introduction • Terms • Clients |
| Basic |
| Datatypes • FLAP • SNAC • TLV |
| UUIDs • Errors • Tool IDs |
| Host Interaction |
| Rate Limits • Migration • Messages |
| Other Services |
| ADMIN • ADVERT • ALERT |
| BART • BOS • BUCP • CHAT |
| CHAT_NAV |
| Tutorials |
| Sign On • BART • Rendezvous |
| ICBM • Locate • Buddies |
| Foodgroups |
| OSERVICE (0x0001) |
| LOCATE (0x0002) |
| BUDDY (0x0003) |
| ICBM (0x0004) |
| ADVERT (0x0005) |
| INVITE (0x0006) |
| ADMIN (0x0007) |
| POPUP (0x0008) |
| PD (0x0009) |
| USER_LOOKUP (0x000A) |
| STATS (0x000B) |
| TRANSLATE (0x000C) |
| CHAT_NAV (0x000D) |
| CHAT (0x000E) |
| ODIR (0x000F) |
| BART (0x0010) |
| FEEDBAG (0x0013) |
| ICQ (0x0015) |
| BUCP (0x0017) |
| ALERT (0x0018) |
| PLUGIN (0x0022) |
| UNNAMED_FG_24 (0x0024) |
| MDIR (0x0025) |
| ARS (0x044A) |
| ID | Origin | Name | Foodgroup | Service | Status | Version |
|---|---|---|---|---|---|---|
| 0x0003, 0x000B | Host | BUDDY__ARRIVED | Unspecified | BOS | Active | 1.10 |
This notification, potentially batched, indicates that one or more users on the client's Buddy List has signed on or updated their information.
Due to nature of the host architecture, expect redundant arrived notifications for a given user which may, or may not contain updated information. Also, offline users with status messages or BART items may be sent as "arrived", so always check the USER_FLAGS to see if the user is online; USER_FLAGS will be zero if offline.
SNAC Header
| Foodgroup | uint16 (word) | 00 03 |
| Subgroup | uint16 (word) | 00 0B |
| Flags | uint16 (word) | 00 00 |
| Request ID | uint32 (dword) | 00 00 00 00 |
SNAC Data
One of the main AIM features is this function called the "Buddy List". It's analogous to the "Contacts" in ICQ terminology. Basically, at login, you send a list of screen names (supposedly, they're suppose to be the names of your friends, but that's certainly not a requirement) to the message server. These names get watched for login/logoff events, and you will get notified when these things happen.
The client has no requirements on how it needs to handle these things. You could easily send up an empty buddy list and ignore the feature entirely, but it's there, so you might as well use it. The AIM client has it's own client-side divisions of "groups". You classify your buddies into groups and it lists them on the buddy list window in that order. If they're on the list, they're online. If they're not, they're not. These divisions are truely client-side and the server only sees one unified list, that the AIM client sorts out when it gets notifications.
You get notified only on enter (oncoming) and exit (offgoing) of buddies, plus the initial "who's on" list after you send up your buddy list.
The "oncoming buddy" command can occur at three different times during the lifecycle of an AIM session. The first, is at the end of the login process, just after the AIM message server is notified of the contents of your buddy list (Phase 3D, Command HI). The second is if/when one of the buddies in that list comes online who wasnt' before, and the third occurs at a regular interval while the connection is otherwise idle. This third case is used for updating your buddy list to make sure you didn't miss anything before. The command syntax for all three cases is exactly the same:
| Position | Length | Data |
| 1 | Word | 0x0003 |
| 3 | Word | 0x000b |
| 5 | Word | 0x0000 |
| 7 | DWord | 32-bits of seeminly gibberish |
| 11 | Byte | Oncoming Screen Name Length |
| 12 | ASCII String | Oncoming Screen Name (NOT null terminated) |
| 13 | Word | Unsigned Int containing current Warning Level of Oncoming SN |
| 15 | Word | Class (0x0004 for Free, 0x0003 for AOL) |
| 17 | Word | 0x0001 |
| 19 | Word | 0x0002 |
| 21 | Word | Class Part Two (0x0010 for Free, 0x0004 for AOL) |
| 23 | Word | 0x0002 |
| 25 | Word | 0x0004 |
| 27 | DWord | Unsigned Long (32bit) containing "Member Since" date |
| 31 | Word | 0x0003 |
| 33 | Word | 0x0004 |
| 35 | DWord | Unsigned Long (32bit) containing "On Since" date |
| 39* | Word | 0x0004 |
| 41* | Word | 0x0002 |
| 43* | Word | 0x0000 |
| *Only existant for members of the "Free" or "Trial" classes | ||
A note about classes: Every AIM Screen Name is associated with a class. AOL members (who are really just using the AOLIM?AIM Bridge) are in the "AOL" class. Members who are using the AIM-only service are under the "Free" class. And, "Free" members who have had thier account less than thirty days or so, are in the "Trial" class.
For those who don't know what "UNIX time_t format" is, it's the format used to represent times as unsigned long's in UNIX and some DOS-based libc's. I't simply the number of seconds elapsed from the 01 January 1970 00:00:00 UTC. (This is often referred to as "the UNIX epoch".) Both of the times in this command (at positions 27 and 35) are stored in this format (and yes, these will fail because of the y2.048k bug).
Note, that there's also an "Idle for" field in this command somewhere. It may very well be the last word of the command (since I don't think you can get the idle time of an AOL member anyway). Since I've found no good way to "be idle", I can't really figure out exactly where it is.
| Name | Type | Notes |
|---|---|---|
| arrivedInfos | Rest of SNAC array of OSERVICE__USERINFO | User's state being updated |
BUDDY SNACs
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||