protocol

Linux下的多协议即时通讯程序源代码

    Returns either a GOTO_URL or ERROR msg.  

toc_set_idle <idle secs>
    Set idle information. If <idle secs> is 0 then the user isn't idle at all.
    If <idle secs> is greater then 0 then the user has already been idle
    for <idle secs> number of seconds.  The server will automatically
    keep incrementing this number, so do not repeatedly call with new
    idle times.

toc_set_caps [ <Capability 1> [<Capability 2> [...]]]
    Set my capabilities.  All capabilities that we support need to
    be sent at the same time.  Capabilities are represented by
    UUIDs.  

toc_rvous_propose  - Not Implemented Yet

toc_rvous_accept <nick> <cookie> <service> <tlvlist>
    Accept a rendezvous proposal from the user <nick>.
    <cookie> is the cookie from the RVOUS_PROPOSE
    message.  <service> is the UUID the proposal was
    for. <tlvlist> contains a list of tlv tags followed by
    base64 encoded values.

toc_rvous_cancel <nick> <cookie> <service> <tlvlist>
    Cancel a rendezvous proposal from the user <nick>.
    <cookie> is the cookie from the RVOUS_PROPOSE
    message.  <service> is the UUID the proposal was
    for. <tlvlist> contains a list of tlv tags followed by
    base64 encoded values.

toc_format_nickname <new_format>
    Reformat a user's nickname.  An ADMIN_NICK_STATUS or ERROR message will 
    be sent back to the client.

toc_change_passwd <existing_passwd new_passwd>
    Change a user's password.  An ADMIN_PASSWD_STATUS or ERROR message will 
    be sent back to the client.


TOC -> Client
==============
All user names from TOC to client are NOT normalized, and are
sent as they should be displayed.  String are NOT encoded, instead
we use colons as separators.  So that you can have colons inside
of messages, everything after the colon before :<Message> should
be considered part of the message (ie don't just "split" on colons,
instead split with a max number of results.)


SIGN_ON:<Client Version Supported>
   This is sent after a successful toc_signon command is sent to TOC.
   If the command was unsuccessful either the FLAP connection will
   be dropped or you will receive a ERROR message.

CONFIG:<config>
   A user's config. Config can be empty in which case the host was not able to
   retrieve it, or a config didn't exist for the user.  See toc_set_config
   above for the format.

NICK:<Nickname>
   Tells you your correct nickname (ie how it should be capitalized and
   spacing)

IM_IN:<Source User>:<Auto Response T/F?>:<Message>
   Receive an IM from some one.  Everything after the third colon is
   the incoming message, including other colons.

UPDATE_BUDDY:<Buddy User>:<Online? T/F>:<Evil Amount>:<Signon Time>:<IdleTime>:<UC>
   This one command handles arrival/depart/updates.  Evil Amount is
   a percentage, Signon Time is UNIX epoc, idle time is in minutes, UC (User Class)
   is a two/three character string.
   uc[0]:
   ' '  - Ignore
   'A'  - On AOL
   uc[1]
   ' '  - Ignore
   'A'  - Oscar Admin
   'U'  - Oscar Unconfirmed
   'O'  - Oscar Normal
   uc[2] 
   '\0' - Ignore
   ' '  - Ignore
   'U'  - The user has set their unavailable flag.



ERROR:<Error Code>:Var args
   * General Errors *
   901   - $1 not currently available
   902   - Warning of $1 not currently available
   903   - A message has been dropped, you are exceeding
	   the server speed limit

   * Admin Errors  *
   911   - Error validating input
   912   - Invalid account
   913   - Error encountered while processing request
   914   - Service unavailable

   * Chat Errors  *
   950   - Chat in $1 is unavailable.

   * IM & Info Errors *
   960   - You are sending message too fast to $1
   961   - You missed an im from $1 because it was too big.
   962   - You missed an im from $1 because it was sent too fast.

   * Dir Errors *
   970   - Failure
   971   - Too many matches
   972   - Need more qualifiers
   973   - Dir service temporarily unavailable
   974   - Email lookup restricted
   975   - Keyword Ignored
   976   - No Keywords
   977   - Language not supported
   978   - Country not supported
   979   - Failure unknown $1

   * Auth errors *
   980   - Incorrect nickname or password.
   981   - The service is temporarily unavailable.
   982   - Your warning level is currently too high to sign on.
   983   - You have been connecting and
	   disconnecting too frequently.  Wait 10 minutes and try again.
	   If you continue to try, you will need to wait even longer.
   989   - An unknown signon error has occurred $1


EVILED:<new evil>:<name of eviler, blank if anonymous>
   The user was just eviled.

CHAT_JOIN:<Chat Room Id>:<Chat Room Name>
   We were able to join this chat room.  The Chat Room Id is
   internal to TOC.

CHAT_IN:<Chat Room Id>:<Source User>:<Whisper? T/F>:<Message>
   A chat message was sent in a chat room.

CHAT_UPDATE_BUDDY:<Chat Room Id>:<Inside? T/F>:<User 1>:<User 2>...
   This one command handles arrival/departs from a chat room.  The
   very first message of this type for each chat room contains the
   users already in the room.

CHAT_INVITE:<Chat Room Name>:<Chat Room Id>:<Invite Sender>:<Message>
   We are being invited to a chat room.

CHAT_LEFT:<Chat Room Id>
   Tells tic connection to chat room has been dropped

GOTO_URL:<Window Name>:<Url>
   Goto a URL.  Window Name is the suggested internal name of the window
   to use.  (Java supports this.) 

DIR_STATUS:<Return Code>:<Optional args>
   <Return Code> is always 0 for success status.

ADMIN_NICK_STATUS:<Return Code>:<Optional args>
   <Return Code> is always 0 for success status.

ADMIN_PASSWD_STATUS:<Return Code>:<Optional args>
   <Return Code> is always 0 for success status.
   

PAUSE
   Tells TIC to pause so we can do migration

RVOUS_PROPOSE:<user>:<uuid>:<cookie>:<seq>:<rip>:<pip>:<vip>:<port>
              [:tlv tag1:tlv value1[:tlv tag2:tlv value2[:...]]]
   Another user has proposed that we rendezvous with them to
   perform the service specified by <uuid>.  They want us
   to connect to them, we have their rendezvous ip, their 
   proposer_ip, and their verified_ip. The tlv values are 
   base64 encoded.

Typical Signon Process
======================
Except for the section marked optional this is an sequential
process.  Each line MUST occur before the following line.

* Client connects to TOC
* Client sends "FLAPON\r\n\r\n"
* TOC sends Client FLAP SIGNON
* Client sends TOC FLAP SIGNON
* Client sends TOC "toc_signon" message
* if login fails TOC drops client's connection
  else TOC sends client SIGN_ON reply
* if Client doesn't support version it drops the connection

[BEGIN OPTIONAL]
    * TOC sends Client CONFIG
    * Client sends TOC permit/deny stuff
    * Client sends TOC toc_add_buddy message
[END OPTIONAL]

* Client sends TOC toc_init_done message


SFLAP Documentation
===================
SFLAP is pretty much a FLAP connection except the DATA frame payload is a null
terminated string when traveling from client to host, it is NOT null
terminated when traveling from host to client.  The FLAP Header is binary 
data, and is in network byte order.  The data portion is at offset 6, after the
header.  The sequence number is sequential in each direction.  So
packets from the server to client have one sequence number, while
the packets from the client to server have an independent
increasing number.

FLAP Header (6 bytes)
-----------
Offset   Size  Type
0        1     ASTERISK (literal ASCII '*')
1        1     Frame Type
2        2     Sequence Number
4        2     Data Length


Valid Frame Type Values
-----------------------
1   SIGNON
2   DATA
3   ERROR     (Not used by TOC)
4   SIGNOFF   (Not used by TOC)
5   KEEP_ALIVE


TOC SIGNON FRAME TYPE
---------------------
Sequence Number contains the initial sequence number used in each direction.
Data Length contains the payload length, with the payload described
below.  The payload area is NOT null terminated.

Host To Client:
    4 byte FLAP version (1)

Client To Host:  
    4 byte FLAP version (1)
    2 byte TLV Tag (1)
    2 byte Normalized User Name Length
    N byte Normalized User Name  (NOT null terminated)

    
TOC DATA FRAME TYPE
-------------------
Sequence Number contains the next sequence number.
Data Length is the length of the payload, including the null termination
from client to host.