Protocols/MSNP/MSNC

MSNP Protocol

MSNC

Overview • MSNObject

Client Capabilities

P2P protocol

Transports • MSNSLP

Headers

P2Pv1 Binary headers

P2Pv2 Binary headers

Transfers

Display Pictures

Custom Emoticons

File Transfer

Overview

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)

MSN Client Protocol

History

MSNP8 is well documented and is similar to MSNP2 in its command syntax, but for the release of MSN Messenger 6 in 2003 and new versions since a new structure was developed using a new protocol called MSNC1 (Mobile Status Notification Client) along with MSNP9.

Reasons for implementation

The MSNC1 enables clients to communicate in a peer-to-peer fashion so background pictures in conversation boxes to highlight one example are easily relayed without causing extra overhead on the switchboard server. The reason for the MSNC1 protocol was so the updated Messenger client could accommodate new features including customization of the client and improved file transfer times.

Implementation

On the notification server level, MSNC1 brings the rise of the MSNObject and a client id number that identifies the client capabilities.

On the client side, there is a protocol called msn p2p, that is designed to work over different transports, such as switchboard or direct connect.

Each p2p message is encapsuled between a binary header of length 48 (which contains session identifiers, flags, and message splitting information) and a binary footer of length 4 (which is often four null chars, \0\0\0\0 or an application identifier).

The body may be empty, data itself (a PNG image in display picture transfers, for example), or another protocol called MSNSLP (similar to SIP) for negotiation messages.

The official client implementation is very strict when it finds an error in other clients implementations - and it's very easy to make a mistake. Sometimes it starts to ignore p2p messages, or stops sending data at random apparently. A powerful diff/compare util and a sniffer will be useful.