Protocols/MSNP/MSNC/File Transfer

From NINA Wiki
Revision as of 05:22, 31 October 2008 by AD (talk | contribs)
(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

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

  • Binary header string

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

  • MSNSLP Message

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.

  • Binary footer string

The "Application Identifier" in the footer should have 0 as value.

Example: 

Under construction...


BaseIdentifier message

  • Binary header string

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.

  • Binary footer string

The "Application Identifier" in the footer should have 0 as value.

200 OK message

  • Binary header string

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.

  • MSNSLP Message

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.

  • Binary footer string

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.

  • Binary header string

The value that the "Identifier" field should have is the next avaible SC sequence Identifier and the Session Identifier field should be 0. The other fields should be as described in "Sending Acknowledgements" under the <a href="#p2p">P2P Messages</a> section.

  • Binary footer string

The "Application Identifier" in the footer should have 0 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.

  • Binary header string

The value that the "Identifier" field should have is the next avaible SC sequence Identifier, the Session Identifier field should be 0 and the Length fields must be set to the length of the MSNSLP Message.

  • MSNSLP Message

The message specific fields of the MSNSLP Message which should be handled with care are the CSeq field which should be 0, the Call-ID which must have the same value as the first Invitation and the Content-Type field must be set to application/x-msnmsgr-transreqbody. And in the message body the Bridges field should be set to the supported transport layers, for example TRUDPv1 or TCPv1. The NetID field is 0 if the Conn-Type is Direct-Connect or Firewall, else it is a random generated number.

If you are connecting with the Internet through a firewall, you should set the value of the Conn-Type to Firewall. If you don't have a firewall or a NAT-network, you can set the value of the field to Direct-Connect. If the computer has enabled UPnP-NAT you should set the UPnPNat to true otherwise it should be set to false, so is the ICF field.

  • Binary footer string

The "Application Identifier" in the footer should have 0 as value.

Example: 

Under construction...


Direct connection invitation acknowledged message

  • Binary header string

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 Identifier field is the next avaible RC sequence Identifier.

  • Binary footer string

The "Application Identifier" in the footer should have 0 as value.

Example: 

Under construction...


Direct connection 200 OK message

  • Binary header string

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.

  • MSNSLP Message

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 Invitation Message + 1, the Content-Type field must be set to application/x-msnmsgr-transrespbody and in the message body the Bridge field should be set to the choosen transport layer, for example TCPv1. Also, the Listening must be set to true is the client is listening on the given IP address and port, the Nonce 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 IPv4Internal-Addrs and the IPv4Internal-Port fields. See also "200 OK" 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 Listening field to false, the Nonce field to {00000000-0000-0000-0000-000000000000} 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 application/x-msnmsgr-transrespbody, the RC should then acknowledge the Invitation and connect to the SC.

  • Binary footer string

The "Application Identifier" in the footer should have 0 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.

  • Binary header string

The value that the "Identifier" field should have is the next avaible SC sequence Identifier and the Session Identifier field should be 0. The other fields should be as described in "Sending Acknowledgements" under the <a href="#p2p">P2P Messages</a> section.

  • Binary footer string

The "Application Identifier" in the footer should have 0 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 binary footer 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 foo followed by a 0x00 character 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 04 00 00 00 66 6F 6F 00 which means: 4 bytes length packet, "foo\0" as packet content.


Direct connection handshake message

  • Binary header string

The value that the "Identifier" field should have is the next avaible SC sequence Identifier, the Session Identifier field should be 0 also all Length fields must have 0 as value and the last three fields of the message should contain the Nonce GUID. If the Nonce GUID is {6815559D-7C43-4D57-AB34-49868AAA805F} 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

Seventh field: 9D 55 15 68
Eigth field: 43 7C 57 4D
Ninth field: AB 34 49 86 8A AA 80 5F

And the Flags field should be set to 0x100 to indicate that it is a Direct Connection Handshake message.

Example: 

Under construction...


Direct connection handshake reply message

  • Binary header string

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

  • Binary header string

The value that the "Identifier" field should have is the next avaible SC sequence Identifier and the Session Identifier field should have the SessionID as value. The Offset field should carry the number of bytes already sent, the "Data Length" should have the length of the file as value and "Message Length" 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 "Splitting Messages" under the <a href="#sending">Sending Messages</a> section.

The "Flag" field should be set to 0x1000030 to indicate that this is the contect of a File and the "Unique Identifier" (seventh field) should have a random generated number as value.

  • Data Message

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

  • Binary header string

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 Session Identifier field contains the SessionID as value and that the Identifier field is the next avaible RC sequence Identifier. This message should be an Acknowledgement to the last Data Message!


Bye message

Binary header string 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 "Identifier" field should have is the next avaible RC sequence Identifier and the Session Identifier field should have as value 0. The other fields have the same value as those described by the Invitation Message.

  • MSNSLP Message

The message specific fields of the MSNSLP Message which should be handled with are are the CSeq field which should have the value 0 and the message body should be a CRLF followed by a 0x00 character.
See also the "BYE Request" under the <a href="#msnslp">MSNSLP</a> section for further details.


Bye acknowledged message

  • Binary header string

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 Session Identifier field is 0 and that the Identifier field is the next avaible SC sequence Identifier.

  • Binary footer string

The "Application Identifier" in the footer should have 0 as value.

Retrieved from "https://wiki.nina.chat/index.php?title=Protocols/MSNP/MSNC/File_Transfer&oldid=2526"