MRMARMAN

MSNTurk
Türkçe MSN Client

MSN Messenger altyapısını kullanan küçük boyutlu, dilediğiniz yere taşınabilen, kurulum gektirmeyen bir Anında Mesaj Çözümü.

Testleri devam etmekte ve geliştirilmektedir.

Konu ile İlgili Proje Geliştirmek İsteyenlere Kaynak Bilgi

Command	From	To	Description
ACK	Switchboard	Client	Sends a positive message delivery acknowledgement.
ADD	Client Notifcation	Notification Client	Adds to the user's FL, AL, and BL. Notifies the client of asynchronous additions to a user's list.
ANS	Client	Switchboard	Accepts a request for a switchboard server session.
BLP	Client Notifcation	Notification Client	Changes the user's message privacy setting, which determines how to treat messages from users not already in the BL or AL.
BYE	Switchboard	Client	Notifies a client that a user is no longer in the session.
CAL	Client	Switchboard	Initiates a switchboard server session.
CHG	Client Notifcation	Notification Client	Sends a client state change to the server. Echos the success of the client's state change request.
FLN	Notification	Client	Notifies the client when users in the FL go off-line
GTC	Client Notifcation	Notification Client	Changes the user's prompt setting, which determines how the client reacts to certain RL changes.
INF	Client Client Dispatch Notification	Dispatch Notification Client Client	Requests set of support authentication protocol from the server. Provides the set of supported authentication protocols to the client.
ILN	Notification	Client	Notifies the client of a the initial online state of a user in the FL, while either logging on or adding a user to the FL.
IRO	Switchboard	Client	Provides the initial roster information for new users joining the session.
JOI	Switchboard	Client	Notifies a client that a user is now in the session.
LST	Client Notifcation	Notification Client	Retrieves the server's version of the user's FL, RL, AL, or BL.
MSG	Client	Switchboard	Sends a message to the members of the current session.
MSG	Notification Switchboard	Client Client	Delivers a message from another client or from a server-side component.
NAK	Switchboard	Client	Sends a negative message delivery acknowledgement.
NLN	Notification	Client	Notifies the client when users in the FL go on-line or when their on-line state changes.
OUT	All	All	Ends a client-server Session.
REM	Client Notifcation	Notification Client	Removes from the user's FL, AL, and BL. Notifies the client of asynchronous removals from a user's list.
RNG	Notification	Client	Notifies the client of a request by another client to establish a session via a switchboard server.
SYN	Client Notifcation	Notification Client	Initiates client-server property synchronization.
USR	All	All	Authenticates client with server, possibly in mulitiple passes.
VER	Client Dispatch	Dispatch Client	Negotiates common protocol dialect between client and Server.
XFR	Client Notifcation	Notification Client	Requests a Switchboard server for use in establishing a session.
XFR	Dispatch Client	Notification Client	Notification of login-NS to the client or notification to move to a different NS.

7. Presence and State Protocol Details

This is a detailed list of protocol commands associated with presence functionality. They are defined in the order used by clients. Commands associated with instant messages are discussed in section 8 below.

7.1 Protocol Versioning

After the client connects to a dispatch server by opening a TCP socket to port 1863, the client and server agree on a particular protocol version before they proceed. The Client-Server protocol version handshake involves the following command exchange:

C: VER TrID dialect-name{ dialect-name...}
S: VER TrID dialect-name

The client can provide multiple dialect names in preferred order. The dialect-name parameter returned by the server is the version server is designating for this connection

The current protocol dialect-name supported by Messenger servers is "MSNP2". The dialect names are not case-sensitive.

The string "0" is a reserved dialect name and is used to indicate a failure response. E.g.:

S: VER TrID 0{ dialect-name ... }

7.2 Server Policy Information

The client next queries the server for variable "policy" information. In this version of the protocol, the only policy information returned by the server is the authentication package in use.

C: INF TrID
S: INF TrID SP{,SP...}

SP identifies a security package - the name of the SASL mechanism to use for authentication. "MD5" is used by the Notification Server, "CKI" by the Switchboard Server.

7.3 Authentication

The client needs to authenticate itself after protocol version handshake and identifying the security packages supported on the server. The following are the client server interactions involved.

C: USR TrID SP I{ AuthInitiateInfo}
S: USR TrID SP S{ AuthChallengeInfo}
C: USR TrID SP S{ AuthResponseInfo }
S: USR TrID OK UserHandle FriendlyName

The SP parameter is the name of the security package("MD5"). The next parameter is a sequence value, which must be I to (I)nitiate the authentication process and S for all (S)ubsequent messages. If authentication fails on the server, the client can start the authentication process again.

For the MD5 security package:

• The AuthInitiateInfo parameter provided by the client must be the User handle.
• The AuthChallengeInfo parameter returned by the server contains a challenge string.
• The AuthResponseInfo contains the binary response as a hexadecimal string, which the MD5 hash of the challenge and the User password strings concatenated together.

The final response from the server contains, in addition to the user handle, the current "Friendly Name" associated with the user handle. This is a "Custom User Name" as described above.

7.4 Referral

There are three cases in which clients are referred from one server to another:

1. The initial "Dispatch Server" refers the client to the Notification Server to which it is assigned.
2. Asynchronous referral by the Notification Server to reassign the client to a different Notification Server if that server is overloaded or undergoing maintenance.
3. During Switchboard Session establishment, the assigned Notification Server refers the client to a particular switchboard server for use. This is discussed below.

In the current implementation the Dispatch Server uses the user handle provided in the initial USR command above to assign the user in question to a Notification Server. Alternate implementations might not require referral at this stage.

If received, referral is of the form:

S: XFR TrID ReferralType Address[:PortNo]

ReferralType is either "NS" or "SB" and defines the type of referral to a Notification Server or Switchboard Server. Address is a valid DNS name or IP address to a referred server, with optional port# suffixed as ":PortNo".

If this command is received from the server, the client should attempt to log in to the server provided.

In the case of "NS" referrals during logon, the Server automatically closes the client connection after sending this XFR response so that the client can connect to the new IP Address.

If sent asynchronously, the client is responsible for closing the connection.

After a "NS" referral, the client will not receive any more messages from the "old" NS, and also must not send any commands to the "old" NS after receiving an XFR.

7.5 Client User Property Synchronization

Several of the user properties used by the Messenger application are stored on the server. This is done for two reasons:

1. So that users can "roam", i.e. log in from different locations and still have the appropriate data, such as their contact lists and privacy settings.
2. If changes occur to a user's Reverse List while that user was offline (the user was added to another user's list), the client can be updated with this information.

For performance reasons it is useful to cache these properties on the client, so that bandwidth usage is minimized in the typical case where the user is not roaming and there were no Reverse List changes.

These requirements are met by the SYN command - synchronization.

Once a client logs in successfully, it uses the SYN command to ensure it has the latest version of the server-stored properties. These properties include: Forward List, Reverse List, Block List, Allow List, GTC setting (privacy setting when someone adds this user to their Forward List), and BLP setting (the user's privacy mode).

The SYN command is:

C: SYN TrID Ser#
S: SYN TrID Ser#

The Ser# parameter sent by the client is the version of the properties currently cached on the client. The server responds with the current server version of the properties. If the server has a newer version, the server will immediately follow the SYN reply by updating the client with the latest version of the user properties. These updates are done as described below, and are done without the client explicitly initiating a LST, GTC or BLP command. Note that the server will update all server-stored properties to the client, regardless of how many entries have been changed.

The following "List Retrieval and Property Management" section describes the format of the user properties sent by the server. After the SYN reply from the server, the user property updates will be sent from the server in this sequence: GTC, BLP, LST FL, LST AL, LST BL, LST RL.

All the user property updates will share the same TrID as the SYN command and reply.

7.6 List Retrieval And Property Management

Synchronizing can result in a batch of user properties and lists getting sent by the server to the client. However, the client application can also initiate a request to retrieve the server-stored lists and properties. The following are the privacy property and list retrieval commands. The response formats are the same whether it is a client-initiated request, or whether it is a response to the SYN process as described above.

List Command

By issuing the LST command, the client can explicitly request that a list be sent. The server will respond with a series of LST responses, one LST response for each item in the requested list.

C: LST TrID LIST
S: LST TrID LIST Ser# Item# TtlItems UserHandle CustomUserName

• LIST is FL/RL/AL/BL for Forward List, Reverse List, Allow List, and Block List, respectively.
• The Item# parameter contains the index of the item described in this command message. (E.g. item 1 of N, 2 of N, etc.)
• The TtlItems parameter contains the total number of items in this list.
• UserHandle is the user handle for this list item.
• CustomUserName is the friendly name for this list item.

If the list is empty, the response will be:

S: LST TrID LIST Ser# 0 0

Reverse List Prompting

The client can change its persistent setting for when to prompt the user in reaction to an Reverse List change. This is accomplished via the GTC command:

C: GTC TrID [A | N]
S: GTC TrID Ser# [A | N]

The value of the A/N parameter determines how the client should behave when it discovers that a user is in its RL, but is not in its AL or BL. (Note that this occurs when a user has been added to another user's list, but has not been explicitly allowed or blocked):

A

Prompt the user as to whether the new user in the RL should be added to the AL or the BL

N

Automatically add the new user in the RL to the AL

The A/N parameter is not interpreted by the server, merely stored.

The server will respond with the current setting if the change was successful. Otherwise, it will return an error with the matching TrID. If the client tries to change the setting to the same value as the current setting, the server will respond with an error message.

The default setting is A when a new user connects to the server for the first time.

Privacy Mode

The client can change how the server handles instant messages from users via the BLP command:

C: BLP TrID [AL | BL]
S: BLP TrID Ser# [AL | BL]

The AL/BL parameter determines how the server should treat messages (MSG and RNG) from users. If the current setting is AL, messages from users who are not in BL will be delivered. If the current setting is BL, only messages from people who are in the AL will be delivered.

The server will respond with the current setting if the change was successful. Otherwise, it will return an error with the matching TrID. If the client tries to change the setting to the same value as the current setting, the server will respond with an error message.

The default setting is AL when a new user connects to the server for the first time.

7.7 Client States

After the client is authenticated and synchronized, the client establishes its initial state with the server with the CHG command. The syntax of the command is:

C: CHG TrID State
S: CHG TrID State

When the state is changed, the server will echo the settings back to client. The state shall not be considered changed until the response is received from the server.

Note that the server can send a state change message to the client at any time. If the server changes the state without a request from the client, the TrID parameter will be 0.

States are denoted by a string of three characters. The predefined states that the server recognizes are:

NLN

Make the client Online (after logging in) and send and receive notifications about buddies.

FLN

Make the client Offline. If the client is already online, offline notifications will be sent to users on the RL. No message activity is allowed. In this state, the client can only synchronize the lists as described above.

HDN

Make the client Hidden/Invisible. If the client is already online, offline notifications will be sent to users on the RL. The client will appear as Offline to others but can receive online/offline notifications from other users, and can also synchronize the lists. Clients cannot receive any instant messages in this state.

All other States are treated as sub-states of NLN (online). The other States currently supported are:

BSY

Busy.

IDL

Idle.

BRB

Be Right Back.

AWY

Away From Computer.

PHN

On The Phone.

LUN

Out To Lunch.