Secondary Client - File Transport Mechanism

Once a searching WPN Primary Client receives a required search/query result, it may initiate the direct download of one or more of the files described in the query result.
In the case of a Secondary client originating the request, the query results are relayed to the originating Secondary client via a Primary Client.
Query origination and result handling is explained here.

All Files are transacted out-of-network i.e. a direct TCP connection between the source and requesting client is established in order to perform the data transfer. File data is never transferred over the WPN.






                     

The file download protocol is HTTP/TCP. The WPN client initiating the download sends a request string of the following type.

Send:
File Request Command
[ "GET": 3 ] [ User name: N ] [ "" ": 2 ] [ Full path name: N ] [ "" M ": 3 ]



The uploading client will reply thus:

Receive:
File Size Descriptor
[ File size/length (TEXT): N ]



The WPN client initiating the download continues with the following Message

Send:
File Segment Acquisition Information.
[ Start position: 4 *] [ End position: 4 ]
* If end position = max file size then the file is complete and end of transfer should be indicated.



The uploading client will now deliver the requested file segment, the average size is a 2k chunk (2048 bytes) for Audio formats and 4k (4096 bytes) for video formats

As you can see its pretty simple at this level but what is not shown here is the encrypted Management system that operates via the Primary and so wont show up in this transaction.


                               


The file uploading area of the protocol follows the following format.

Incoming connection request :
Receive:
31  (This is to confirm the identity of a valid mx client  using 3.xx protocol)


The Uploader will now receive the GET file request

Receive:
[ "GET": 3 ] [ User name: N ] [ "" ": 2 ] [ Full File path/name: N ] [ "" M ": 3 ]


and reply thus:

Send:
[ File size/length (TEXT): N ]



The Uploader will now receive the request for an actual chunk/segment from the downloader, the average size is a 2k chunk (2048 bytes) for Audio formats and 4k (4096 bytes) for video formats

Receive:
File Segment Requested.
[ Start position: 4 *] [ End position: 4 ]
* If filesize = end position then the file is complete and end of transfer should be indicated.


The Uploader will now deliver the requested segment.




 

When a transaction is attempted between a client and a "firewalled" client a special exchange protocol is in place to enable transactions to take place despite the limitations of the firewall.

This is the method used to communicate the file request to the uploading client, note the FileSize is send with the download in this case. At this stage we can introduce the "M" Marker, this is sent to indicate acceptance of the incoming request and is followed by the segment (file chunk) request as we see in the normal transfer method above.

Receive:
[ "SEND": 4 ] [ User name: N ][ Full path name: N ][ File size (TEXT): N ]
*Username in this case is that of the uploading client not of the requesting client.




Send:
Send "M" (4D ASCII)
[ M :1 ]



The WPN client requesting the forced download continues with the following message having already gained the FileSize information from the recieved SEND packet.

Send:
File Segment Acquisition Information.
[ Start position: 4 *] [ End position: 4 ]
* If end position = max file size then the file is complete and end of transfer should be indicated.



The downloading client will now receive the requested file segment.



Here is an actual file transfer being started.






It is important to remember all file segments are exchanged in sequential order, whilst not ideal in terms of transaction efficiency it does have the benefit of allowing "previewing" of media type files and thus avoid incorrectly labeled or garbage "Spoof" files without having to obtain the whole file first.