Protocols/MSNP/MSNC/Display pictures

From NINA Wiki
Revision as of 01:10, 2 March 2011 by Wikipedia>Admin
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

| 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 |-


Overview

Sending and receiving display pictures doesn't only depend on the MSNSLP protocol, but also on schemes being used by the binary header and footer. The scheme for sending or receiving display pictures isn't the same as for receiving files. The scheme for sending and receiving display pictures is not very difficult: Just go with the flow. If some fields of the binary string aren't discussed in a message, you should set it's value to zero.

A display picture transfer will go like this:

  • << Invitation
  • >> Acknowledgement
  • >> 200 OK
  • << Acknowledgement
  • >> Data preparation message
  • << Acknowledgement
  • >> Data piece 1
  • >> Data piece 2
  • ...
  • >> Data piece n (Actually the data is only ONE message, split in parts)
  • << Acknowledgement (Therefore only one acknowledgement is send after the last packet)
  • (The picture should now be visible)
  • << BYE
  • >> Acknowledgement

Note that all messages in this flow are mandatory: the official MSN client will refuse your display picture if you don't send acknowledgements or set the binary header fields incorrectly.

First, the receiving client (RC) sends the sending client (SC) an invitation to start a session. The Identifier field of that invitation should contain a generated BaseIdentifier, the Identifier field of the following messages should be calculated from that BaseIdentifier. The identifier of the next messages send by the SC should be BaseIdentifier - 3, BaseIdentifier - 2 and so on. If the field reaches the BaseIdentifier again, you should proceed with BaseIdentifier + 1, BaseIdentifier + 2 and so on.

The receiving client should on its turn send messages with BaseIdentifier + 1, BaseIdentifier + 2 and so on as values for the Identifier field.

Invitation message

Binary header

  • The receiving client should generate a BaseIdentifier and set is as value of the Identifier field.

Content

  • CSeq is 0
  • EUF-GUID is {A4268EEC-FEC5-49E5-95C3-F126696BDBF6} to indicate that it's an invite to send a display picture.
  • SessionID must have the Session Identifier as value.
  • AppID is 1
  • Context is the base64 encoded string of the MSNObject
  • As always when sending MSNSLP, append NUL (0x00 character) to the end of the message.

Binary footer

  • Application Identifier is 0

Example: 

MSG 1 D 800
MIME-Version: 1.0
Content-Type: application/x-msnmsgrp2p
P2P-Dest: buddy1@hotmail.com

00 00 00 00 58 A9 18 01 00 00 00 00 00 00 00 00
91 02 00 00 00 00 00 00 91 02 00 00 00 00 00 00
AB 38 1E 00 00 00 00 00 00 00 00 00 00 00 00 00
INVITE MSNMSGR:buddy1@hotmail.com MSNSLP/1.0
To: <msnmsgr:buddy1@hotmail.com>
From: <msnmsgr:me@hotmail.com>
Via: MSNSLP/1.0/TLP ;branch={33517CE4-02FC-4428-B6F4-39927229B722}
CSeq: 0
Call-ID: {9D79AE57-1BD5-444B-B14E-3FC9BB2B5D58}
Max-Forwards: 0
Content-Type: application/x-msnmsgr-sessionreqbody
Content-Length: 326

EUF-GUID: {A4268EEC-FEC5-49E5-95C3-F126696BDBF6}
SessionID: 1980589
AppID: 1
Context: PG1zbm9iaiBDcmVhdG9yPSJidWRkeTFAaG90bWFpbC5jb20iIFNpemU9IjI0NTM5IiBUeXBlPSIzIiBMb2NhdGlvbj0iVEZSMkMudG1wIiBGcmllbmRseT0iQUFBPSIgU0hBMUQ9InRyQzhTbEZ4MnNXUXhaTUlCQVdTRW5YYzhvUT0iIFNIQTFDPSJVMzJvNmJvc1p6bHVKcTgyZUF0TXB4NWRJRUk9Ii8+DQoA
00
00 00 00 00


Invitation acknowledged message

  • Identifier is the generated BaseIdentifier

Example: 

MSG buddy1@hotmail.com D 139
MIME-Version: 1.0
Content-Type: application/x-msnmsgrp2p
P2P-Dest: me@hotmail.com

00 00 00 00 3B 99 4F 02 00 00 00 00 00 00 00 00
91 02 00 00 00 00 00 00 00 00 00 00 02 00 00 00
58 A9 18 01 AB 38 1E 00 91 02 00 00 00 00 00 00
00 00 00 00


200 OK message

If everything is okay, the SC can respond with a 200 OK message. But if there are some things it doesn't accept, it should send another error back instead of 200 OK. For the Identifier it doesn't matter if it's a 200 OK, a 404 Not Found or something else.

Binary header

  • SessionID is 0
  • Identifier is the next available sending client sequence identifier. The other fields have the same value as those described by the invitation message.

Content

  • CSeq is the value of the CSeq field from the invitation message + 1
  • SessionID is the same as in the invitation message

Binary footer

  • Application Identifier is 0

Example: 

MSG buddy1@hotmail.com D 417
MIME-Version: 1.0
Content-Type: application/x-msnmsgrp2p
P2P-Dest: me@hotmail.com

00 00 00 00 38 99 4F 02 00 00 00 00 00 00 00 00
46 01 00 00 00 00 00 00 46 01 00 00 00 00 00 00
4B 99 4F 02 00 00 00 00 00 00 00 00 00 00 00 00
MSNSLP/1.0 200 OK
To: <msnmsgr:me@hotmail.com>
From: <msnmsgr:buddy1@hotmail.com>
Via: MSNSLP/1.0/TLP ;branch={33517CE4-02FC-4428-B6F4-39927229B722}
CSeq: 1
Call-ID: {9D79AE57-1BD5-444B-B14E-3FC9BB2B5D58}
Max-Forwards: 0
Content-Type: application/x-msnmsgr-sessionreqbody
Content-Length: 23

SessionID: 1980589

00
00 00 00 00


200 OK acknowledged message

  • Identifier is the next available receiving client sequence identifier

Example: 

MSG 2 D 143
MIME-Version: 1.0
Content-Type: application/x-msnmsgrp2p
P2P-Dest: buddy1@hotmail.com

00 00 00 00 59 A9 18 01 00 00 00 00 00 00 00 00
46 01 00 00 00 00 00 00 00 00 00 00 02 00 00 00
38 99 4F 02 4B 99 4F 02 46 01 00 00 00 00 00 00
00 00 00 00


Data preparation message

If the sending client received the 200 OK acknowledged message from the receiving client it should send a "data preparation message".

Binary header

  • SessionID is the SessionID as from the invitation message
  • Identifier is the next available sending client sequence identifier
  • Total data size is 4, because the data in this message is four bytes long.
  • Unique Identifier (seventh field) should have a random number

Content

  • This message should have 4 NUL (0x00 characters) as data.

Binary footer

  • Application identifier is differently from previous messages, 1. Because this is big endian (big end first), the binary string looks like this: 0x00 0x00 0x00 0x01

Example: 

MSG buddy1@hotmail.com D 143
MIME-Version: 1.0
Content-Type: application/x-msnmsgrp2p
P2P-Dest: me@hotmail.com

AD 38 1E 00 39 99 4F 02 00 00 00 00 00 00 00 00
04 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00
57 99 4F 02 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00
00 00 00 01


Data preparation acknowledged message

  • Identifier field is the next available receiving client sequence identifier

Example: 

MSG 3 D 143
MIME-Version: 1.0
Content-Type: application/x-msnmsgrp2p
P2P-Dest: buddy1@hotmail.com

AD 38 1E 00 5A A9 18 01 00 00 00 00 00 00 00 00
04 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00
39 99 4F 02 57 99 4F 02 04 00 00 00 00 00 00 00
00 00 00 00


Data message(s)

If everything till now was alright, the sending client can send the content of the display picture file. Although it is only one message, it is generally big enough to have to be split into several MSG commands, each with a binary header and footer:

Binary header

  • Identifier is the next available sending client sequence identifier
  • SessionID is the SessionID
  • Data offset is the bytes already sent
  • Data length is the length of the file
  • Message length is the size of the content of this P2P message
  • Flag is 0x20 to indicate that this the message content is display picture or custom emoticon data
  • Unique Identifier (seventh field) is a random number

Content

  • This message should contain the content of the display picture file. (Which is often split)

Binary footer

  • Application identifier is 1 big endian: 0x00 0x00 0x00 0x01

Example (start): 

MSG buddy1@hotmail.com D 1341
MIME-Version: 1.0
Content-Type: application/x-msnmsgrp2p
P2P-Dest: me@hotmail.com

AD 38 1E 00 3A 99 4F 02 00 00 00 00 00 00 00 00
78 05 00 00 00 00 00 00 B2 04 00 00 20 00 00 00
64 9A 4F 02 00 00 00 00 00 00 00 00 00 00 00 00
PNG File Data Start
00 00 00 01

Example (end): 

MSG buddy1@hotmail.com D 337
MIME-Version: 1.0
Content-Type: application/x-msnmsgrp2p
P2P-Dest: me@hotmail.com

AD 38 1E 00 3A 99 4F 02 B2 04 00 00 00 00 00 00
78 05 00 00 00 00 00 00 C6 00 00 00 20 00 00 00
78 9A 4F 02 00 00 00 00 00 00 00 00 00 00 00 00
PNG File Data End
00 00 00 01

When the complete data has arrived, the display picture should be visible if everything went fine. If you can't see it, check your MSN object and that every field in the messages have correct values.


Data acknowledged message

  • Identifier is the next available receiving client sequence identifier

Example: 

MSG 4 D 143
MIME-Version: 1.0
Content-Type: application/x-msnmsgrp2p
P2P-Dest: buddy1@hotmail.com

AD 38 1E 00 5B A9 18 01 00 00 00 00 00 00 00 00
78 05 00 00 00 00 00 00 00 00 00 00 02 00 00 00
3A 99 4F 02 78 9A 4F 02 78 05 00 00 00 00 00 00
00 00 00 00

Note that only one acknowledgement is sent once all parts of the split data message have been received.

Bye message

Binary header

  • Identifier is the next available receiving client sequence identifier
  • SessionID is 0
  • The other fields have the same value as those described by the Invitation Message

Content

  • CSeq is 0
  • The message body is a CRLF followed by a NUL (0x00 character)

Binary footer

  • Application identifier is 0

Example: 

MSG 5 D 472
MIME-Version: 1.0
Content-Type: application/x-msnmsgrp2p
P2P-Dest: buddy1@hotmail.com

00 00 00 00 5C A9 18 01 00 00 00 00 00 00 00 00
49 01 00 00 00 00 00 00 49 01 00 00 00 00 00 00
04 9B 4F 02 00 00 00 00 00 00 00 00 00 00 00 00
BYE MSNMSGR:buddy1@hotmail.com MSNSLP/1.0
To: <msnmsgr:buddy1@hotmail.com>
From: <msnmsgr:me@hotmail.com>
Via: MSNSLP/1.0/TLP ;branch={A0D624A6-6C0C-4283-A9E0-BC97B4B46D32}
CSeq: 0
Call-ID: {9D79AE57-1BD5-444B-B14E-3FC9BB2B5D58}
Max-Forwards: 0
Content-Type: application/x-msnmsgr-sessionclosebody
Content-Length: 3

00
00 00 00 00


Bye acknowledged message

  • Identifier is the next available sending client sequence identifier

Example: 

MSG buddy1@hotmail.com D 139
MIME-Version: 1.0
Content-Type: application/x-msnmsgrp2p
P2P-Dest: me@hotmail.com

00 00 00 00 3C 99 4F 02 00 00 00 00 00 00 00 00
49 01 00 00 00 00 00 00 00 00 00 00 02 00 00 00
5C A9 18 01 04 9B 4F 02 49 01 00 00 00 00 00 00
00 00 00 00
Retrieved from "https://wiki.nina.chat/index.php?title=Protocols/MSNP/MSNC/Display_pictures&oldid=2524"