|
|
| Line 1: |
Line 1: |
| − | {{Protocols/MSNP/MSNC_Navigation}}
| + | #REDIRECT[[Protocols/MSNP/MSNC/File transfer]] |
| − | | |
| − | | |
| − | =Overview=
| |
| − | | |
| − | File transfers are also working via a specific scheme, but this doesn't differ much from the scheme used by the User Display Images and the Emoticons.
| |
| − | | |
| − | If some fields of the binary string aren't discussed in a message, you should set its value to 0.
| |
| − | | |
| − | First, the Sending Client (SC) need to send the Receiving Client (RC) 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 fields of the next messages sent by the '''RC''' should be '''BaseIdentifier + 1''', '''BaseIdentifier + 2''' and so on.
| |
| − | | |
| − | The '''SC''' should on its turn send messages with '''BaseIdentifier + 1''', '''BaseIdentifier + 2''' and so on as values for the '''Identifier''' field. The only thing which is different here is that both Identifier fields will always be '''BaseIdentifier + a number'''.
| |
| − | | |
| − | =Invitation message=
| |
| − | | |
| − | * <u>Binary header string</u>
| |
| − | The Sending Client ('''SC''') should generate a BaseIdentifier and give the '''Identifier''' field that value, the '''Length''' fields must be set to the length of the '''MSNSLP Message'''
| |
| − | | |
| − | * <u>MSNSLP Message</u>
| |
| − | The message specific fields of the MSNSLP Message which should be handled with care are the '''CSeq''' field which should be '''0'''. And in the message body the '''EUF-GUID''' should be set to '''{5D3E02AB-6190-11D3-BBBB-00C04F795683}''' to indicate that it's a session for the File transfer, the '''SessionID''' field must have the Session Identifier as value, the '''AppID''' field should have the value '''2''' and the '''Context''' field should have the base64 encoded string of the '''File Preview Data'''.
| |
| − | | |
| − | * <u>Binary footer string</u>
| |
| − | The '''"Application Identifier"''' in the footer should have '''0''' as value.
| |
| − | | |
| − | Example:
| |
| − | Under construction...
| |
| − | | |
| − | | |
| − | =BaseIdentifier message=
| |
| − | | |
| − | * <u>Binary header string</u>
| |
| − | The Receiving Client ('''RC''') should on its turn send an Acknowlegde Message back with its BaseIdentifier on the '''Identifier''' field and the Session Identifier field should be '''0'''. See also '''"Sending Acknowledgements"''' under the [[Protocols/MSNP/MSNC/MSNSLP#P2P Messages]] section.
| |
| − | | |
| − | * <u>Binary footer string</u>
| |
| − | The '''"Application Identifier"''' in the footer should have '''0''' as value.
| |
| − | | |
| − | =200 OK message=
| |
| − | | |
| − | *<u>Binary header string</u>
| |
| − | If everything is okay, the RC 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. The value that the '''"Identifier"''' field should have is the next avaible '''RC''' sequence Identifier. The other fields have the same value as those described by the '''Invitation Message'''.
| |
| − | | |
| − | *<u>MSNSLP Message</u>
| |
| − | The message specific fields of the MSNSLP Message which should be handled with are are the '''CSeq''' field which should be the value of the '''CSeq field from the Inivation Message + 1''' and in the message body the '''SessionID''' field must have the Session Identifier as value.
| |
| − | | |
| − | *<u>Binary footer string</u>
| |
| − | The '''"Application Identifier"''' in the footer should have '''0''' as value.
| |
| − | | |
| − | Example:
| |
| − | Under construction...
| |
| − | | |
| − | | |
| − | =200 OK acknowledged message=
| |
| − | | |
| − | If everything in the 200 OK message is as supposed to be, then the SC should send an Acknowledged Message back.
| |
| − | | |
| − | *<u>Binary header string</u>
| |
| − | The value that the <b>"Identifier"</b> field should have is the next avaible <b>SC</b> sequence Identifier and the Session Identifier field should be <b>0</b>. The other fields should be as described in <b>"Sending Acknowledgements"</b> under the <a href="#p2p">P2P Messages</a> section.
| |
| − | | |
| − | *<u>Binary footer string</u>
| |
| − | The <b>"Application Identifier"</b> in the footer should have <b>0</b> as value.
| |
| − | | |
| − | Example:
| |
| − | Under construction...
| |
| − | | |
| − | | |
| − | =Direct connection invitation message=
| |
| − | | |
| − | After the 200 OK Acknowledged Message, the SC will send a new Invitation, which is a request to start a request for a Direct Connection.
| |
| − | | |
| − | *<u>Binary header string</u>
| |
| − | The value that the <b>"Identifier"</b> field should have is the next avaible <b>SC</b> sequence Identifier, the Session Identifier field should be <b>0</b> and the <b>Length</b> fields must be set to the length of the <b>MSNSLP Message</b>.
| |
| − | | |
| − | *<u>MSNSLP Message</u>
| |
| − | The message specific fields of the MSNSLP Message which should be handled with care are the <b>CSeq</b> field which should be <b>0</b>, the <b>Call-ID</b> which must have the <b>same</b> value as the first Invitation and the <b>Content-Type</b> field must be set to <b>application/x-msnmsgr-transreqbody</b>. And in the message body the <b>Bridges</b> field should be set to the supported transport layers, for example <b>TRUDPv1</b> or <b>TCPv1</b>. The <b>NetID</b> field is <b>0</b> if the <b>Conn-Type</b> is <b>Direct-Connect</b> or <b>Firewall</b>, else it is a random generated number.
| |
| − | | |
| − | If you are connecting with the Internet through a firewall, you should set the value of the <b>Conn-Type</b> to <b>Firewall</b>. If you don't have a firewall or a NAT-network, you can set the value of the field to <b>Direct-Connect</b>. If the computer has enabled UPnP-NAT you should set the <b>UPnPNat</b> to <b>true</b> otherwise it should be set to <b>false</b>, so is the <b>ICF</b> field.
| |
| − | | |
| − | *<u>Binary footer string</u>
| |
| − | The <b>"Application Identifier"</b> in the footer should have <b>0</b> as value.
| |
| − | | |
| − | Example:
| |
| − | Under construction...
| |
| − | | |
| − | | |
| − | =Direct connection invitation acknowledged message=
| |
| − | | |
| − | *<u>Binary header string</u>
| |
| − | If everything is still alright, the RC should send an Acknowledged Message back to the SC.
| |
| − | | |
| − | This message doesn't much differ from the "200 OK Acknowledged Message", except that the <b>Identifier</b> field is the next avaible <b>RC</b> sequence Identifier.
| |
| − | | |
| − | *<u>Binary footer string</u>
| |
| − | The <b>"Application Identifier"</b> in the footer should have <b>0</b> as value.
| |
| − | | |
| − | Example:
| |
| − | Under construction...
| |
| − | | |
| − | | |
| − | =Direct connection 200 OK message=
| |
| − | | |
| − | *<u>Binary header string</u>
| |
| − | If everything is okay, the RC can respond with a <b>200 OK</b> message. But if there are some things it doesn't accept, it should send another error back instead of 200 OK. The value that the <b>"Identifier"</b> field should have is the next avaible <b>RC</b> sequence Identifier. The other fields have the same value as those described by the <b>Invitation Message</b>.
| |
| − | | |
| − | *<u>MSNSLP Message</u>
| |
| − | The message specific fields of the MSNSLP Message which should be handled with are are the <b>CSeq</b> field which should be the value of the <b>CSeq field from the Invitation Message + 1</b>, the <b>Content-Type</b> field must be set to <b>application/x-msnmsgr-transrespbody</b> and in the message body the <b>Bridge</b> field should be set to the choosen transport layer, for example <b>TCPv1</b>. Also, the <b>Listening</b> must be set to <b>true</b> is the client is listening on the given IP address and port, the <b>Nonce</b> field must contain a GUID in the form of for example, the Call-ID GUID. And there must be an IP address and port field added to the message, most of the time this will be the <b>IPv4Internal-Addrs</b> and the <b>IPv4Internal-Port</b> fields. See also <b>"200 OK"</b> under the <a href="#msnslp">MSNSLP</a> section.
| |
| − | | |
| − | If the RC is behind a firewall and the SC is direct connected to the Internet, the RC should set the <b>Listening</b> field to <b>false</b>, the <b>Nonce</b> field to <b>{00000000-0000-0000-0000-000000000000}</b> and should not add the IP adress and port fields to the message body. The SC will then send an Invitation which is of the type <b>application/x-msnmsgr-transrespbody</b>, the RC should then acknowledge the Invitation and connect to the SC.
| |
| − | | |
| − | *<u>Binary footer string</u>
| |
| − | The <b>"Application Identifier"</b> in the footer should have <b>0</b> as value.
| |
| − | | |
| − | Example:
| |
| − | Under construction...
| |
| − | | |
| − | | |
| − | =Direct connection 200 OK acknowledged message=
| |
| − | | |
| − | If everything in the Direct Connection 200 OK message is as supposed to be, the SC should send an Acknowledged Message back.
| |
| − | | |
| − | *<u>Binary header string</u>
| |
| − | The value that the <b>"Identifier"</b> field should have is the next avaible <b>SC</b> sequence Identifier and the Session Identifier field should be <b>0</b>. The other fields should be as described in <b>"Sending Acknowledgements"</b> under the <a href="#p2p">P2P Messages</a> section.
| |
| − | | |
| − | *<u>Binary footer string</u>
| |
| − | The <b>"Application Identifier"</b> in the footer should have <b>0</b> as value.
| |
| − | | |
| − | Example:
| |
| − | Under construction...
| |
| − | | |
| − | | |
| − | =Direct connection: Handshake=
| |
| − | | |
| − | After a client sended a "Listening is true" field, the other client should connect to that IP address and port. In this documentation we will use the fact that the SC will connect to the RC, otherwise it would be a difficult part to read.
| |
| − | | |
| − | The messages send in a Direct Connection look a bit different then the messages send over the server, because they don't have a <b>binary footer</b> instead of that the client must send a DWORD in front of the data with the length of the total message data. For example, if you are sending and Acknowledge message (which is 48-bytes), you should put a DWORD in front of it with as value 48.
| |
| − | | |
| − | When connected, the SC should send the text <b>foo followed by a 0x00 character</b> to check if the connection is okay. After that it should send a Direct Connect Handshake message to the RC.
| |
| − | | |
| − | This means that the first 8 bytes a direct connection client will receive are <b> 04 00 00 00 66 6F 6F 00</b> which means: 4 bytes length packet, <b>"foo\0"</b> as packet content.
| |
| − | | |
| − | | |
| − | =Direct connection handshake message=
| |
| − | | |
| − | *<u>Binary header string</u>
| |
| − | The value that the <b>"Identifier"</b> field should have is the next avaible <b>SC</b> sequence Identifier, the Session Identifier field should be <b>0</b> also all <b>Length</b> fields must have <b>0</b> as value and the last three fields of the message should contain the <b>Nonce</b> GUID. If the <b>Nonce</b> GUID is <b>{6815559D-7C43-4D57-AB34-49868AAA805F}</b> for example, the last three fields should look like this:
| |
| − | | |
| − | 9D 55 15 68 43 7C 57 4D AB 34 49 86 8A AA 80 5F<br>
| |
| − | | |
| − | Seventh field: 9D 55 15 68<br>
| |
| − | Eigth field: 43 7C 57 4D<br>
| |
| − | Ninth field: AB 34 49 86 8A AA 80 5F<br>
| |
| − | | |
| − | And the <b>Flags</b> field should be set to <b>0x100</b> to indicate that it is a Direct Connection Handshake message.
| |
| − | | |
| − | Example:
| |
| − | Under construction...
| |
| − | | |
| − | | |
| − | =Direct connection handshake reply message=
| |
| − | | |
| − | *<u>Binary header string</u>
| |
| − | If the Handshake Message is okay, the RC should send a reply to that Handshake Message. The field of that message must have the same values, except the <b>Identifier</b> field, as the message received bye the SC.
| |
| − | | |
| − | Example:
| |
| − | Under construction...
| |
| − | | |
| − | | |
| − | =File data message(s)=
| |
| − | | |
| − | If everything till now was alright, the SC can start sending the requested data.
| |
| − | | |
| − | *<u>Binary header string</u>
| |
| − | The value that the <b>"Identifier"</b> field should have is the next avaible <b>SC</b> sequence Identifier and the Session Identifier field should have the <b>SessionID</b> as value. The <b>Offset</b> field should carry the number of bytes already sent, the <b>"Data Length"</b> should have the length of the file as value and <b>"Message Length"</b> should contain the length of the data which is send with this message. If the length of the data is larger then 1352 characters, it should be split. See also <b>"Splitting Messages"</b> under the <a href="#sending">Sending Messages</a> section.
| |
| − | | |
| − | The <b>"Flag"</b> field should be set to 0x1000030 to indicate that this is the contect of a File and the <b>"Unique Identifier"</b> (seventh field) should have a random generated number as value.
| |
| − | | |
| − | *<u>Data Message</u>
| |
| − | This message should have the data which was requested. If the length of the data is larger then 1352, it should be split in parts with a maximum length of 1352 charachters.
| |
| − | | |
| − | | |
| − | =Data acknowledged message=
| |
| − | | |
| − | *<u>Binary header string</u>
| |
| − | If all the data was received with success, the RC should send an Acknowledged Message back to the SC. This message doesn't much differ from the previous Acknowledged Messages, except that the <b>Session Identifier</b> field contains the <b>SessionID</b> as value and that the <b>Identifier</b> field is the next avaible <b>RC</b> sequence Identifier. This message should be an Acknowledgement to the last Data Message!
| |
| − | | |
| − | | |
| − | =Bye message=
| |
| − | | |
| − | <u>Binary header string</u>
| |
| − | After the Data Acknowledged Message, the RC must send a Bye Message to the SC to say that the session can be closed.
| |
| − | | |
| − | The value that the <b>"Identifier"</b> field should have is the next avaible <b>RC</b> sequence Identifier and the <b>Session Identifier</b> field should have as value <b>0</b>. The other fields have the same value as those described by the <b>Invitation Message</b>.
| |
| − | | |
| − | *<u>MSNSLP Message</u>
| |
| − | The message specific fields of the MSNSLP Message which should be handled with are are the <b>CSeq</b> field which should have the value <b>0</b> and the message body should be a CRLF followed by a 0x00 character.<br> See also the <b>"BYE Request"</b> under the <a href="#msnslp">MSNSLP</a> section for further details.
| |
| − | | |
| − | | |
| − | =Bye acknowledged message=
| |
| − | | |
| − | *<u>Binary header string</u>
| |
| − | And finally if the Bye message is received by the SC and everything is fine, it can send an Acknowledged Message back to the RC. This message doesn't much differ from the previous Acknowledged Messages, except that the <b>Session Identifier</b> field is <b>0</b> and that the <b>Identifier</b> field is the next avaible <b>SC</b> sequence Identifier.
| |
| − | | |
| − | *<u>Binary footer string</u>
| |
| − | The <b>"Application Identifier"</b> in the footer should have <b>0</b> as value.
| |
| − | | |
| − | [[Category:MSN]]
| |
| − | [[Category:Protocols/MSNP]]
| |
| − | [[Category:Work_In_Progress]]
| |
