MSNC:Display pictures

From MSNPiki

Jump to: navigation, search
MSN Client Protocol

Overview · MSNObject · Client Capabilities
P2P protocol: Transports · MSNSLP
Headers: P2Pv1 Binary headers · P2Pv2 Binary headers
Transfers: Display Pictures · Custom Emoticons · File Transfer


Contents

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:

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

Content

Binary footer

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

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

Content

Binary footer

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

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

Content

Binary footer

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

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

Content

Binary footer

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

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

Content

Binary footer

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

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
Personal tools
Namespaces
Variants
Actions
Windows Live Network Protocol
Windows Live Client Protocol
Reference
Toolbox