Protocols/MSNP/MSNC/P2Pv1 Headers

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 ListCommandsRelaying 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
MSNC
IntroductionP2PObject DescriptorDisplay PicturesFile Transfer
Scenarios
Microsoft Messenger for Mac
MSNP on WebTV (MSNTV)

Binary headers

P2P messages consist of a 48-byte binary header, zero or more bytes of content, and at the end a 4-byte binary footer.

The 48-byte binary header consists of 6 DWORDs and 3 QWORDS, which are all in little endian (little end first) order, where a DWORD is a 32-bit (4 byte) unsigned integer and QWORD is 64 bits (8 bytes).

Fields in the table are index, byte offset, data type, name used for the field in this documentation, and description.

0                   1                   2                   3                   4                   5
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  SID  |  ID   | Data Offset   | Total Size    |Length | Flags | AckID |AckUID | Ack Data Size |DATA....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 0 DWORD SessionID The SessionID, which is zero when the Clients are negotiating about the session.
2 4 DWORD Identifier The first message you receive from the other client is the BaseIndentifier, the other messages contains a number near the BaseIdentifier.
3 8 QWORD Data offset Explained under Splitting big messages. Most often the messages are not split, and this value is 0.
4 16 QWORD Total data size Case 1: The byte size of all data sent between the header and footer of all of the message parts. This is the same independent of how many pieces the message is split in. Case 2: If this is an acknowledgement, this field is a copy of the same field in the message acknowledged. Sending acknowledgements
5 24 DWORD Message length The byte size of the data between the header and footer of this particular message.
6 28 DWORD Flag Identifies the message type. See the flags section
7 32 DWORD Acknowledged identifier In case the message is an acknowledgement, this is a copy of the Identifier of the acknowledged message. Else this is some random generated number.
8 36 DWORD Acknowledged unique ID In case the message is an acknowledgement, this is a copy of the previous field of the acknowledged message. Else this is 0.
9 40 QWORD Acknowledged data size In case the message is an acknowledgement, this is a copy of the Total data size field of the acknowledged message. Else this is 0.

Flags

The flags field in binary header can take the following values:

  • 0x0: no flags specified
  • 0x1: chunk out-of-order
  • 0x2: acknowledgement
  • 0x4: there is a pending invite
  • 0x8: error on the binary level
  • 0x20: display picture/custom emoticon data
  • 0x01000030: file transfer data

Splitting big messages

When the content of the message between the binary header and footer is larger then 1202 characters (or 1352 in case of a Direct Connection), the data must be sent in separate messages, each a complete P2P message with a Content-Type, P2P-dest, binary header and binary footer. The message is acknowledged from the receiving client only when all parts have been received, with the total size of the content as acknowledged data size. Here is the binary header you should use when splitting messages:

  • SessionID: The same Session ID as you've used when handshaking
  • Identifier: It must be the identifier used in the "data preparation" message + 1. It will stay the same for all parts.
  • Data Offset: Amount of data (in bytes) that has been sent up to this part.
  • Total data size: Amount of data (in bytes) that will be sent.
  • Message length: Amount of data (in bytes) in this part.
  • Message type: Type of message, see the upper paragraph.
  • Acknowledged identifier: Random number.
  • Identifier: 0
  • Acknowledged data size: 0

Sending acknowledgements

When a client sends you a P2P-message, you should always reply with a sort of Acknowledgement Message (otherwise the official MSN Client will probably refuse your datum). Let's suppose that you've received and decoded a certain binary header. The acknowledgement message you can send has the following binary header:

  • SessionID: Session ID of the received binary header
  • Identifier: You can simply invert the identifier in the received binary header (~identifier in C++)
  • Data Offset: 0
  • Total data size: Same as the "total data size" field of the received binary header
  • Message length: 0
  • Message type: 2
  • Acknowledged identifier: You can simply add one to the identifier in the received binary header
  • Identifier: Identifier of the received binary header
  • Acknowledged data size: Same as the "total data size" field of the received binary header

The footer is 4-bytes long and only contains 0s.

Note that when messages are split, you should only send one acknowledgement when the last part of the split message is received.

Footer

The 4-byte binary footer consists of 1 DWORD which is in big endian (big end first) order and that field represents the ApplicationIdentifier (AppID). If this field is zero, then the clients are negotiating about the session. The ApplicationIdentifier is 0x1 for display picture and emoticon transfer, 0x2 for file transfers, and for games it's specified by the start nenu code.