Research on send DP in MSN Protocol

In msn6, you can define your own avatar. A self-built robot can also display the Avatar. Jmsn does not provide this feature.
Can only be modified by yourselfCode.
The key is protocol. I followed the communication protocol of MSN and found that, first of all, you need to declare your profile picture information to the server. This information is implemented in the <msnobj> entity.

The other party's MSN Messenger will find you have profile information, and will send you an MSN P2P invite msnmsng request via ss. Then you respond and send the Avatar binary stream. It is a P2P communication process.
Currently, it is still under study. It is found that each P2P message contains a 48-byte header. So far, I just got a friend's advice today.
1. this is a DWORD and contains the sessionid, which is zero when the clients are negotiating about the session. this field is only used when actually sending data (DP's, CE's etc ). the value of this field in ink messages is always 64!

2. this field is again a DWORD, which identifies the message (the so called base identifier ). in ink this field has the same value in all messages. in other transfers this value will range from baseid-3 to baseid + 3. the number can range between 4 and 4, 25 billion
(4 ~ 4 250 000 ).

3. this field is a qword, and contains the offset of the data you are sending, if the size is over 1202 bytes. for example, if you send 2404 bytes, the first message wocould contain the value zero (seeing you haven'tsend something yet), and the second message wowould have the value 1202, because you just send 1202 bytes.

4. this field is once again a qword, and contains the size of total data being send in this total. if there is no data you can leave this to zero and often the flag field (Field 6) shocould be set to the value of 2.

5. this field is a DWORD and contains the size of the data being send in this message. note that "data" does not include the headers, only the data send between the header and the footer! For example, when sending a 5000 bytes file, field four wowould contain the value of 5000, and this field wowould contain only 1202, because you can't transfer more than 1202 bytes in one message. this field and the fourth field are equal to each other when you aren't sending actually file data (or ink data in our case ).

6. the sixth field, DWORD, is the flag field. the value of this field is 0 when no flags are specified. it will be 2 when the message is a reply to another message, 8 if there's an error in the binary fields of the specified ed packet. the flag will contain the value 32 if you are sending DP or CE data, and the value 16777264 when it's data of a file transfer.

7. this DWORD contains the baseid of the previous encoded message, * If * The sessionid is not supported in the binary headers, nor in the data sent in this message. seeing the sessionid is specified when sending ink you can just put a random number here (1 ~ 1 000 000 wocould be good enough ).

8. This field (a dword) contains the value of the seventh field of the previous received message.

9. The ninth field is a qword, and contains the value of the fourth field of the previous received message.

10. this DWORD comes after the data, and therefore it's the footer. this DWORD contains the value zero when there is no actual file data (DP's, CE's etc) being send. it has the value 1 before you send DP's, CE's or other data, and it has the value 3 when sending ink.