3.10.5 Message Processing Events and Sequencing Rules

For the file receiver, several messages can arrive during the entire process. (See section 2.2.3.) When a message arrives, a string comparison can be used to determine the type of message that has arrived. The state machine shown in section 3.10 shows the expected sequence of messages; any messages that arrive out of sequence MUST cause the receiver of the message to generate a FILEXFERREJECT message to signal the error in processing the messages. If errors in the sequence are ignored, it is possible that file corruption can occur on the file receiving side.

The first message that is received is an <RCCOMMAND> message on the virtual channel 71 with the NAME attribute set to FILEXFER. The message MUST also include the attributes FILENAME, FILESIZE, and CHANNELID. The FILENAME attribute MUST be set to the original name of the file, as seen by the sender of the file. The FILESIZE attribute MUST be set to the size in bytes of the file about to be sent. The CHANNELID MUST be set to the name of the virtual channel that the file data will be sent on. Also, the CHANNELID will be the channel through which the file sender expects to get a response from the file receiver. In version 3, if the sender intended this file to be considered as internal data, it MUST be marked by setting the INTERNALDATA attribute corresponding to the type of internal data sent.

After receiving this message, the file receiver MUST send a response to the file transfer request on the channel specified in the message just received. If the file transfer is wanted, the file receiver MUST send the FILEXFERACK message to the file sender on the file transfer channel. After sending the FILEXFERACK message, the file receiver MUST prepare for file data to arrive on the same channel. If the file transfer is not wanted, the file receiver MUST send the FILEXFERREJECT message on the file transfer channel. If the FILEXFERREJECT message is sent, no additional messages or file data are to be expected by the file receiver, and no more messages are sent on the virtual channel.

When receiving file data, the file is received in discrete blocks. Version 1 of the protocol uses a block size of 409,600 bytes, while versions 2 and 3 use a block size of 1,024 bytes. The last block is a shorter length if the file data is not exactly divisible by the block size chosen. File transfer is complete when the receiver receives the FILEXFEREND message on the file transfer channel.

In all cases, the data MUST be sent serially because there is no header information to allow for odd order reassembly on the receiving side. Also, this protocol does not acknowledge receipt of the block from the receiving side.

If, while the file is being sent, the receiving user wants to cancel the transfer, the user SHOULD send the FILEXFERREJECT message to the file sender on the file transfer channel. To cancel the file transfer, the sender sends the FILEXFERREJECT message to the receiver on the file transfer channel. In either case, the sender SHOULD stop sending data blocks. No other messages are expected or sent on the file transfer channel after the sending or receiving of the FILEXFERREJECT message.

A sample follows of the messages exchanged over time between the file sender and receiver.

Figure 13: File transfer process during a Remote Assistance session