Rkapsi, are you referring to the Magnet411.html test results page located at:

http://mantiscorp.com/people/aew/lim...agnets411.html

I believe so, and will explain what those test steps mean in more detail below with regard to your point about the IP address:

I downloaded the test files using Limewire specifically so that I could create the magnet links using Limewire's built-in feature (when a file's in the Library I right-click on it and select "Magnet Details for File...").

Then, I delete the file so that it's not in my own library -- the test files are widely available on Gnutella and so I simply delete my own copy so that I can test the magnet links that Limewire creates for them; the files are still available on Gnutella, by many users, so removing them from my own library doesn't make it impossible to find (doing so only forces Limewire to actually try and find it on the Gnutella network by using information contained in the xt magnet link attribute). I intentionally delete the file from my own library because if I try to use a magnet link (click on it from a Web page, for example) for a file that's already in my library Limewire won't even attempt to download it, which makes sense. By deleting it, I force Limewire to actually use the entire magnet link -- the files are still available from many users on the Gnutella network (I intentionally choose popular files for this test so that when I deleted them from my library Limewire would still be able to find many sources on the network).

In summary: After I've obtained a widely available file I then construct the magnet link as described and then *delete* the file from my library so I can test if the magnet link I just created actually works. Because the test files I'm using are widely available, Limewire should have no problem accessing them via the magnet link. Limewire should use this portion of the magnet link for the Macbeth.txt file, for example, to find sources for the file on the network:

xt=urn:sha1:EECI66YQYRH347K7S5O3NNFP5SSSQDUV

As you point out the xs attribute (not xt above) does contain my IP (or the IP of whatever machine the magnet link was created on if Limewire was used to create the link). This is how Limewire creates magnet links, so I didn't remove the xs attribute. However, a static IP address such as stored in the xs attribute should *not* be the *only* way the file is located. The xs attribute identifies a specific location for a file (http://###.###.###.etc) which is only one way to find the file, and that http location should be combined with the xt attribute to enable multi-source downloads (swarming).

If the file isn't available via the IP address specified in the xs attribute the download should still happen because xs contains a globally unique, location-independent identifier (urn:sha1:###) that provides Limewire with all of the information it needs to find and download the exact file specified. There's no open-ended search involved using xs. In other words, based on the urn:sha1 value stored in xt Limewire can locate and start downloading the exact file automatically even if the IP host specified by the xs attribute is not available.

This is especially important to do on a dynamic P2P network such as Gnutella where the host specified by the xs attribute can "go away" moments after the magnet link is created. Since I created these links on my own computer, for instance, if I quit Limewire the xs attribute is no longer valid since Limewire's no longer available to handle incoming those http request. Similarly, if I shut down my computer the IP specified by xs is no longer available. Even if I just restart my computer the IP address changes since I (like many other users) have a dynamic IP address that is assigned to me when I connect to my ISP: each time I connect I am assigned a different IP address. Therefore, the xs attribute can never be considered reliable. Limewire should use xs as one of many potential sources, but shouldn't rely on the xs host being available. Instead, xs should be combined with xt for multi-source downloads of a file that's precisely identified by the urn:sha1 value.

Currently Limewire 4.1.1. Beta fails to start the download after it receives and parses certain magnet links, but it does just fine with others. More precisely, it fails to start the download for magnet links that I create using Limewire itself as described in my Magnet411.html page. I can force it to do so by clicking on the "Find More Sources" (or Resume) buttons, as described in my Magnet411.html page, but the program should actually initiate the download itself and not require human intervention in this way. In these tests the magnets are created by Limewire for widely available files on the Gnutella network: it should have no problem finding them, and will do so if I manually click on the "Find More Sources" (or Resume) buttons, otherwise the download will never happen (it just waits and reports that it needs more sources although many are actually available).

Does that help clarify the testing procedures I used in the Magnet411.html file?

Aaron