Protocols/MSNP/MSNC

From NINA Wiki
Jump to navigation Jump to search
MSNP Protocol
MSNC
OverviewMSNObject
Client Capabilities
P2P protocol
TransportsMSNSLP
Headers
P2Pv1 Binary headers
P2Pv2 Binary headers
Transfers
Display Pictures
Custom Emoticons
File Transfer
Overview
IntroductionTermsClients
Reference
Error ListCommandsRelying Party SuiteSpotlife
Services
XMPPHTTP GatewayTabsActivities
Documentation
Development ToolsMSNP Grid
PolygamyURLs 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
IntroductionP2PObject DescriptorDisplay PicturesFile 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.