Protocols/MSNP/MSN Protocol Version 2
| MSNP Protocol |
| Introduction • Terms • Clients |
| Reference |
| Error List • Commands • Relying Party Suite • Spotlife |
| Services |
| XMPP • HTTP Gateway • Tabs • Activities |
| Documentation |
| Development Tools • MSNP Grid |
| Polygamy • URLs used by MSN |
| Documents |
| Protocol Versions |
| Version 21 |
| Version 18 |
| Version 16 |
| Version 15 |
| Version 14 |
| Version 13 |
| Version 12 |
| Version 11 |
| Version 9 |
| Version 8 |
| Version 2 |
| MSNC |
| Introduction • P2P • Object Descriptor • Display Pictures • File Transfer |
| Scenarios |
| Microsoft Messenger for Mac |
| MSNP on WebTV (MSNTV) |
Introduction
MSNP2 was the first public release of the MSNP protocol, used in MSN 1.0. MSNP2 is known to have been worked on since 1998, since there's a beta that has surfaced from 1998 that uses MSNP2 (with some big and small differences).
MSN Messenger Server Component Overview
MSN Messenger Service clients make connections to several different kinds of servers. They are separate components to facilitate running at scale - each component can be duplicated an arbitrary number of times, independently of each other, to enable large numbers of users.
Dispatch Server (DS)
The Dispatch Server is the initial point of connection between client and server. Its primary functions are protocol version negotiation, determination of which Notification Server (NS) is associated with the client making a connection (via an algorithm of the server's choosing), and referring the client to the proper NS.
Notification Server (NS)
The Notification Server is the primary server component. The client and the Notification Server authenticate, synchronize user properties, and exchange asynchronous event notifications. The client's connection to the Notification Server occurs after the referral from the Dispatch Server is completed, and persists without interruption during the user's MSN Messenger Service session.
Some of the events transmitted between a client and a Notification Server are: - State changes (e.g. client is on-line, client is offline, client is idle) - Switchboard Server invitation requests (see below) - Application-specific notifications (i.e. new e-mail has arrived)
Switchboard Server (SB)
Note: while the MSNP2's IETF draft refers to the switchboard server as "SS", the server and all subsequent documentation refers it as "SB".
The Switchboard Server is the component through which clients can establish lightweight communication sessions without requiring a direct network connection between clients. The common usage of the Switchboard Server is to provide instant messaging sessions. When a client wishes to communicate with another client, it sends a message to its Notification Server, which then refers the client to a Switchboard Server. Once the SB connection is established, the "destination" client receives a notification from its NS to connect to the same SB.
Protocol Conventions
Connection Type
The MSN Messenger Protocol currently works over TCP/IP. The MSN Messenger server components support connections over port numbers 1863, which is the registered port number assigned by the IANA (http://www.isi.edu/in-notes/iana/assignments/port-numbers).
Command Syntax
MSN Messenger Protocol command syntax is ASCII and single line- based. Commands begin with a case-sensitive, three-letter command type, followed by zero or more parameters, and terminated by CRLF. Parameters are separated by one or more whitespace characters and cannot contain whitespace characters. Parameters that contain spaces or extended (non 7-bit ASCII) characters should be encoded using URL-style encoding (e.g. "%20" for space). Some commands accept un- encoded binary data. In these cases, the length of the data is transmitted as part of the command, and the data is transmitted immediately following a CRLF of the command.
Asynchronous Requests
Commands issued from the client to the server that result in a reply are known as requests. Requests are entirely asynchronous. The client can submit several requests in sequence without waiting for the server response after submitting each request. The server is required to deliver a response or an error for each request received, but it is not required to deliver the responses in the same order as the requests were received. The client can determine the request associated with a particular response by examining the Transaction ID parameter (described below).
User Handles
MSN Messenger Protocol uses User Handles for identifying users. A user handle (also known as "account name" and "logon name") is a text representation of the user's identity that is both unique and persistent. The user handle is syntactically equivalent to an e-mail address, and as such is subject to the same restrictions for character set, as described in RFC-822. Most notable among these restrictions are the limitation to Latin alphanumeric characters and a few symbols. The maximum acceptable length of the user handle is 129 bytes.
Implementation note: In the initial release of the client and server, user handles are Hotmail account names. All user handles must contain the "@hotmail.com" domain name, and user handles that do not contain a domain name are not valid.
Custom User Names
A custom user name (also known as "custom name" and "friendly name") is a user's representation of the "friendly" textual name associated with a user handle. (E.g. "Auntie Em" instead of em123@hotmail.com). Custom user names are neither unique nor persistent, and can contain any valid Unicode characters. Custom user names are represented in UTF-8 as described in RFC-2044 and URL-encoded as described in RFC- 1738 when transmitted between the client and server. The maximum acceptable length of the encoded custom user name is 387 in the current implementation.
Transaction Identifiers
The Transaction Identifier (a.k.a. Transaction ID; TrID) is a numeric string representing a number between 0 and (2^32 - 1). It is a value that a client includes with any command that it issues to the server. In the current version of the protocol, the transaction identifier is used to associate server responses with client-issued commands. The server treats the transaction ID as an opaque number and does not assume any relationship between successive Transaction
IDs or any particular starting Transaction ID. It is the client's responsibility to guarantee the uniqueness of the Transaction IDs for the purpose of disambiguating the commands and/or responses. (A future version of the protocol could enable the client to track the status or cancel a particular transaction using the transaction ID.)
When the server sends the response to a command to the client, it must include in the response the transaction ID that the client sent to the server when the client originally issued the command. In cases where a server sends a command to a client that requires a transaction ID but is not in response to a specific client command, it will use 0 as the transaction ID. In cases where a server sends multiple responses to a single client request, the server will use the same transaction ID in each response.