Secondary Client - File Queing System

In the case of a Secondary client being unable to either obtain or deliver a file a system of queing is employed, this is a pretty basic system but it does what is necessary.

Query origination and result handling is explained here, in this tutorial we will deal with the small subset of message packets that form the queing system and some of the basic rules governing their use.





When a file is not available for immediate download the WinMX Primary Client your connected to is able to place you in a que to obtain the requested file if your Settings are set to do so. The difference between the initial "File Request" message and the "Que Entry" message is simply a single "option" field in the 1F41 Packet as shown below.

Download Request File Indicator
[ 0x1F41 ][ Packet Data Length : 2 ][ "WinMX" : 6 ][ User IP & Port  ASCII : 12 ][ 00 : 1 ][ UserName : S ][ 00 : 1 ][ FileName : S ][ 00 : 1 ]][ Option : 1 ]

Option = 0x00 - Normal Request
Option = 0x01 - Que Entry Request



The Primary client will now reply with one of three packet types at this stage to allow for the requesting Secondary Client to follow the download/que requests progress. The three types are "Download Start", "In Que" and "Download/Que Failed". Lets look at what we will receive in more detail.


The Primary client may indicate that we can do the "Download Start" routine by sending us a 1FC2 Packet as detailed below.

Download Start Indicator
[ 0x1FC2 ][ Packet Data Length : 2 ][ Requesting Nodes UserName  String : N ][ "WinMX" : 6 ][ User IP & Port  ASCII : 12 ][ 00 : 1 ][ UserName : S ][ 00 : 1 ]
[ FileName : N ][ 00 : 1 ][ IP Address : 4 ][ TCP Port : 2 ]


In this situation we need do no more and the file transfer will continue without further notification if there are no disruptions.
There is a single exception to this however and this occurs when the TCP port indicated is zero. As with Napster clients this indicates the other user is behind a firewall and some trickery is needed to get the transfer started so we send the following.

Force Incoming Download Indicator
[ 0x1F4A ][ Packet Data Length : 2 ][ "WinMX" : 6 ][ User IP & Port  ASCII : 12 ][ 00 : 1 ][ UserName : S ][ 00 : 1 ][ FilePath&Name: N ][ 00 : 1 ]


The Primary client may indicate a successful place "In Que" by sending a 1FCC Packet as detailed below.

Download "In Que" Indicator
[ 0x1FCC : 2 ][ Packet Data Length : 2 ][ "WinMX " : 6 ][ User IP & Port  ASCII : 12 ][ 00 : 1 ][ UserName : N ][ 00 : 1 ][ FileName : N ][ 00 : 1 ][ Que Position Number In Hex : 2  ][ 00 : 2 ]


Once we have received the "In Que" notification we need to keep track of our position so we send a repeat of the 1F41 packet at 5 minute intervals with the option bits set to 1  


Download Request File Indicator
[ 0x1F41 : 2 ][ Packet Data Length : 2 ][ "WinMX " : 6 ][ User IP & Port  ASCII : 12 ][ 00 : 1 ][ UserName : S ][ 00 : 1 ][ FileName : S ][ 00 : 1 ][ Option : 1 ]


The Primary client may indicate that our "Download/Que Failed" with a descriptive error string by sending a 1FA4 Packet as detailed below. This same message will be sent regardless of whether we where attempting an initial download or trying to join a que.

Request Failed/Busy Indicator
[ 0x1FA4 ][ Packet Data Length : 2 ][ "WinMX" : 6 ][ User IP & Port  ASCII : 12 ][ 00 : 1 ][ UserName : S ][ 00 : 1 ][ FileName : N ][ 00 : 1 ][ Status String : S ][ 00 : 1 ]

Status Strings (as indicated by 1F54 packet "x" value)  = "Busy ( % in queue)", "Request timed out", "File not shared"




This concludes the brief look at how we can use the queing system and I hope it helps some of you understand the filesharing/Que mechanism in use