Protocols/OSCAR/SNAC: Difference between revisions
No edit summary |
No edit summary |
||
Line 99: | Line 99: | ||
| A [[Protocols/OSCAR/TLV|tlvLBlock]] immediately follows the SNAC header before the rest of the fields | | A [[Protocols/OSCAR/TLV|tlvLBlock]] immediately follows the SNAC header before the rest of the fields | ||
|} | |} | ||
=== From Aleksandr Shutko: Basic OSCAR information: SNAC === | |||
<table width=640 cellSpacing=0 cellPadding=0 border=0> | |||
<tr> | |||
<td> | |||
<table width=640 bgcolor=darkblue cellSpacing=0 cellPadding=0 border=0><tr><td> | |||
<table width=100% cellSpacing=2 cellPadding=0 border=0><tr><td bgcolor=#E9E9E9 > | |||
<table width=100% cellSpacing=0 cellPadding=0 bgcolor="#4040FF" border=0> | |||
<tr> | |||
<td><b><font size=2 color="white"> SNAC format description </font></b></td> | |||
</tr> | |||
</table> | |||
</td></tr> | |||
<tr><td bgcolor=#E9E9E9 > | |||
<table width=100% cellSpacing=0 cellPadding=0 border=0> | |||
<tr><td width=5> </td> | |||
<td><br> | |||
| |||
A SNAC is the basic communication unit that is exchanged between clients and servers. | |||
The SNAC communication layers sits on top of the FLAP layer. SNAC is the normal contents | |||
of the FLAP Data Field for channel 0x02. SNACs are only sent over channel 0x02. Data sent | |||
across other channels are not considered complete SNACs. There can be only one SNAC per | |||
FLAP frame. Here is the format of SNAC:<br><br> | |||
<table width=100% cellSpacing=0 cellPadding=0 align=center border=0> | |||
<tr><td width=20></td> | |||
<td> | |||
<table width=350 bgcolor=darkgreen cellSpacing=0 cellPadding=0 border=0><tr><td> | |||
<table width=100% cellSpacing=2 cellPadding=0 border=0><tr><td bgcolor=#fafafa > | |||
<table width=350 cellSpacing=0 cellPadding=0 align=center border=0> | |||
<tr> | |||
<td width=25%> xx xx</td> | |||
<td width=5> </td> | |||
<td width=20%>word</td> | |||
<td width=5> </td> | |||
<td width=50%>[[Protocols/OSCAR#Foodgroups|Family]] (service) id number</td> | |||
</tr> | |||
<tr> | |||
<td> xx xx</td> | |||
<td> </td> | |||
<td>word</td> | |||
<td> </td> | |||
<td>[[Protocols/OSCAR#Foodgroups|Family]] subtype id number</td> | |||
</tr> | |||
<tr> | |||
<td> xx xx</td> | |||
<td> </td> | |||
<td>word</td> | |||
<td> </td> | |||
<td>SNAC flags</td> | |||
</tr> | |||
<tr> | |||
<td> xx xx xx xx</td> | |||
<td> </td> | |||
<td>dword</td> | |||
<td> </td> | |||
<td>SNAC request id</td> | |||
</tr> | |||
</table> | |||
</td></tr> | |||
<tr><td bgcolor=#fafafa > | |||
<table width=350 cellSpacing=0 cellPadding=0 align=center border=0> | |||
<tr><td height=8 colspan=3></td></tr> | |||
<tr><td width=50> </td> | |||
<td> | |||
<table width=300 bgcolor=darkred cellSpacing=0 cellPadding=0 border=0><tr><td> | |||
<table width=100% cellSpacing=2 cellPadding=0 align=center border=0><tr><td bgcolor=#fafafa > | |||
<table width=300 cellSpacing=0 cellPadding=0 align=center border=0> | |||
<tr> | |||
<td height=40 align=center valign=middle> ......</td> | |||
<td valign=middle width=56%>SNAC data</td> | |||
</tr> | |||
</table> | |||
</td></tr> | |||
</table> | |||
</td></tr></table> | |||
</td><td width=5> </td> | |||
</tr> | |||
<tr><td height=5 colspan=3> </td></tr> | |||
</table> | |||
</td></tr> | |||
</table> | |||
</td></tr></table> | |||
</td></tr> | |||
</table> | |||
<br> | |||
| |||
There is no formal declaration of the length of the SNAC data portion (that information | |||
must be assumed from the FLAP headers). Families, identified by the "family ID", constitute | |||
a group of services. Subtypes are a subdivision of the families. Each subtype ID is different | |||
depending on the specific service or information provided in the data section.<br><br> | |||
| |||
Request IDs are 32bit values used to identify non-atomic information. The client can generate | |||
completely random reqid's as long as it remembers what the request was for. Often, though, | |||
the results of the SNAC are irrelevant, and the reqid's can be forgotten. But, in | |||
information-requestion SNACs, it is imperative you remember the reqid you sent because that's | |||
the only way to link it to the response! If this is not done, it will be impossible to have | |||
more than one pending request of the same SNAC subtype (which is unlikely at best). For | |||
server-initiated SNACs, the reqid most significant bit=1, and this num count up to zero from | |||
than from zero.<br><br> | |||
| |||
Flags is a general SNAC properties. There is not enough information about snac flags, but known | |||
that if bit1 of flags=1 there are more SNACs for this request-id was sent. Bit16=1 <b>mean that | |||
SNAC contain some unknown information at the beginning</b> (first come a length of additional data | |||
(word) and then data itself).<br><br> | |||
</td> | |||
<td width=5></td></tr> | |||
</table> | |||
</td></tr> | |||
</table> | |||
</td></tr></table> | |||
</td> | |||
</tr> | |||
</table> | |||
[[Category:With_Contrib]] | |||
[[Category:Stub]] | [[Category:Stub]] | ||
[[Category:AOL]] | [[Category:AOL]] |
Latest revision as of 10:34, 14 February 2021
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) |
SNAC notes from another
SNACs (Simple Network Atomic Communication) are used to represent the protocol messages that are sent between the client and backend. The messages are separated into different categories, called foodgroups. Within each foodgroup there are different kinds of messages related to the category.
Datatype: SNAC__Header
The FLAP Header will be immediately followed by the SNAC Header that describes what type of message it is for SNAC messages sent over FLAP. The SNAC Header is a simple 10 byte header that contains the foodgroup, type, any high level flags, and the requestId. The requestId is used to link up requests and replies and can also be used to determine the direction of traffic.
A client should never set the high bit of a requestId or use 0. The server will always set the high bit for its requestId unless it is a reply to a client query, in which case it will use the same requestId as the request. The flags field tells the client if for the same request there will be multiple replies and if there are any SNAC Header TLVs.
Name | Type | Notes |
---|---|---|
id | SNAC__ID | Foodgroup and message type |
flags | uint16 (word) | [Class: SNAC__HEADER_FLAGS] Flags |
requestId | uint32 (dword) | Used to link requests and replies |
Datatype: SNAC__ID
Describes the foodgroup and type this SNAC represents
Name | Type | Notes |
---|---|---|
foodgroup | uint16 (word) | Numeric value that represents the foodgroup the SNAC is in |
type | uint16 (word) | Numeric value that represent the SNAC type |
Class: SNAC__HEADER_FLAGS
These are the flags that let the client know details about the SNAC being received.
Name | Value | Notes |
---|---|---|
SNAC_HEADER_FLAGS_MORE_REPLIES_FOLLOW | 0x0001 | More replies follow this message using the same requestId; the last reply is easily detectable because it will not have this flag set |
SNAC_HEADER_FLAGS_CLIENT_SNAC | 0x0002 | NOT CURRENTLY DOCUMENTED |
SNAC_HEADER_FLAGS_OPT_TLV_PRESENT | 0x8000 | A tlvLBlock immediately follows the SNAC header before the rest of the fields |
From Aleksandr Shutko: Basic OSCAR information: SNAC
|