The Opennap Filesharing Reference Guide



This section is to review the OpenNap file transfers and associated management, covering important areas such file request notification and Que management.
The OpenNap file sharing system is controlled by the usage of Server management packets that manage and negotiate between clients, these are similar to the ones used by WinMX clients but some important differences exists and these are mainly because of the differences in decentralised and client-server network models.




This diagram provides a visual overview of the OpenNap Server management aspect.




Ordinary Downloading Description



To request a download, the Client sends an initial "Download Request" packet <203> to the Server, if there is no que of other users waiting for the file the Server will respond with an "Download Acknowledge" <204> containing further connection information.

In the normal case where the sharing client is not firewalled, you make a TCP connection to the data port specified in the <204> packet received from the Server.
The remote client should accept the connection and immediately send one ASCII character, `1' (ASCII 49).

Once you receive this specific character, you can proceed to send a request for the file you wish to download, in the following format.

       First send the string "GET" in a single packet, then send

         <Length><type><mynick> "<filename>" <offset>



      <mynick>   is your OpenNap UserName,
      <filename> is the name string of the file you wish to download,
      <offset>   is the byte offset in the file to begin the transfer at

      If you are downloading for the first time, and not resuming a prior transfer, you should uses offset 0 to start at the beginning of the file.

At this stage the remote file holding Client will now return the file size, or instead an error message such as "INVALID REQUEST" or "FILE NOT SHARED".

Note that the file size is not terminated in any special way, and the best way to figure out the size is to keep reading until you hit a character that is not a digit (it will usually be 0xff which is the start of the MP3 frame sync header, but if a ID3v2
tag is present it might look different).

Immediately following the file size is where the data stream for the file begins.

Once the data transfer is initiated, the Client should notify the Server that they are downloading a file by sending the <218> "Download Started Notification" packet.
Once the transfer is complete you will need to send a "File Transfer Completed" <219> packet to indicate that you have finished downloading.  
Note that this is cumulative, so that if you are downloading multiple files, it will be necessary to send one <218>/<219> pair for EACH concurrent download,
this is how the Server knows how many transfers you have going on.  
Likewise, an uploader should send a <220> "Upload Started Notification" packet per upload, and a <221> "Upload Complete Notification" when each upload has completed.


Firewalled Downloading



Its at this time that the individual client configuration comes into the equation.  If the <204> "Download Acknowledge" packet indicates that the uploaders ports is zero (0) this indicates that they are firewalled and an alternative mechanism has to be used to obtain the file, this is done in the following way.
Upon receiving the zero port indication via the <204> packet it will be necessary to send a <500> "Firewalled Download Request" to the Server requesting that the remote Client send the data to the requesting Client. You then wait for the remote uploading Client to connect to your data port.

As described above, when the file needs to be pushed from a client behind a firewall, the downloader sends the <500> message to the Server.
This causes a <501> packet to be sent from the Server to the uploader, this is similar to the <204> message for a normal download.

Once the uploader receives the <501> packet from the Server, they should make a TCP connection to the downloader's data port (given in the <501> packet.
Upon connection, the downloader's client will sent one byte, the ASCII character `1'.

       The uploader should then send the string "SEND" in a single packet, and then:

         <length><type><mynick>"<filename>" <size>



      <mynick> is the uploader's OpenNap UserName
      <filename> is the name string of the file being sent
      <size> is the size of the file in bytes

Upon receipt, the downloading client will either send the byte offset at which the transfer should start, or an error message such as
"INVALID REQUEST".
The byte offset should be sent as a single packet in plain ASCII digits. A 0 byte offset indicates the transfer should begin at the start of the file.

Each Client should notify the Server that they are uploading or downloading with the <218>/<219> (downloading) or <220>/<221>(uploading) command pairs.

©2005-2024 WinMXWorld.com. All rights reserved. Page last updated Fri Jun 06 2014