Protocols/MSNP/MSNC

| style="font-size: 95%; text-align:center; color:#000000; background-color:#499feb" | MSNC |- | Overview • MSNObject |- | Client Capabilities |- | style="font-size: 95%; color:#000000; background-color:#499feb; text-align:center;"|P2P protocol |- | Transports • MSNSLP |- | style="font-size: 95%; color:#000000; background-color:#499feb; text-align:center;"|Headers |- | P2Pv1 Binary headers |- | P2Pv2 Binary headers |- | style="font-size: 95%; color:#000000; background-color:#499feb; text-align:center;"|Transfers |- | Display Pictures |- | Custom Emoticons |- | File Transfer |-

| style="font-size: 120%; color:#000000; margin-top: 0.5em; background-color:#499feb; text-align:center;"|Overview |-

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.