Using Linux I encountered a little bug. When the download of a file is complete, it remains in the download-list although I checked the 'remove completed downloads' option. Moreover, the client tells me it is still downloading the file at 0k/s although the download has reached a 100% and the downloaded file has already been moved to the shared-folder.

Thanks for reporting this Linux errror. We'll have a look at it as soon as possible. If you're a programmer, you could also take a look at the source at www.limewire.org =). We'll fix it though, thanks!

__________________
Adam Fisk
LimeWire Developer

I am not really sure why Vinnie never released Defender -- we have never really spoken with him about it at great length. The LimeWire "superpeers" are a similar concept with some slight changes here and there.

We expect to release our superpeer implementation quite soon -- sometime in the next month or so, if not sooner.

__________________
Adam Fisk
LimeWire Developer

SUPER-PEER! SUPER-PEER! SUPER-PEER! She's SUPER PEERY!!


SUPER-PEER!!.....






get it? yeah....shutup.

We didn't release it for a couple of reasons:

1) Proprietary implementation = bad

2) Inadequate discovery method for servers (relying on broadcast queries)

3) Uploading the entire index of files was expensive for modem users, and required a lot of extra work when the local file indexes changed (QRP solves this better, both technically and legally)

I think the LimeWire supernode implementation solves all of these problems and that's where we are going.

Hey Vinnie -- good to see you over hear on the LimeWire forums!

The proprietary implementation problem is definitely an issue. Hopefully the openness of the query routing proposal (the QRP that Vinnie alluded to, the underlying technology behind the old "Sparky" alpha), and of the supernode scheme and the LimeWire source code will help mitigate this problem.

As far as discovery of servers, that is one of the trickiest problems that we have faced as well, although I think that Anurag and Chris have worked out most of the issues there.

Best,

__________________
Adam Fisk
LimeWire Developer

Well, if both LimeWire and BearShare implement supernodes then discovery will be a much simpler.

The original Defender specifications called for searching for servers having certain languages or subjects but I think that the traffic it caused did not justify the feature.

After Limewire and FreePerre became best friends, maybe someone can explain some of the new ideas to the community? I have no idea of Sparky/Superpeer/Swarming implentation details, explanations or development discussion. Also I don't know who is QRP, Anurag, Chris?

Thx, Moak

The history of all of these ideas would be a bit too lengthy to go into in detail, but here's a general summary:

"Sparky" was the little codename for a LimeWire alpha release (released about 2 months ago or so) that was a test of the "Query Routing Proposal," or QRP.

The QRP is simply a way of doing a sort of distributed indexing of files on the network -- basically a way of efficiently letting the computers you're connected to know what files you have so that the computers around you only forward messages to you that they know are relevant to you (searches for files that you actually have). Just think of it as a way of routing messages on the network to the computers that the messages are relevant to as opposed to broadcasting those messages to everyone. The idea is to improve the efficiency of message passing on the network so that it doesn't take up so much bandwidth, leaving you with more bandwidth for transferring files. More information is available at:

http://www.limewire.com/developer/qu...%20routing.htm

Supernodes, or "superpeers," as discussed earlier in this thread are computers on the network that for purposes here index the "client" computers that are connected to them (see earlier diagrams). They actually use query routing for communication between clients and peers, but don't worry too much about that. Basically, the supernodes sheild client nodes from all of the messaging on the rest of the network, only forwarding searches to client nodes if they actually have the files. More information is at:

http://groups.yahoo.com/group/the_gd...upernodes.html

Swarming is simply the ability to download a single file from multiple sources. So, you download different parts of the file from different computers simultaneously. The idea here is to allow you to download files as quickly as possible (as you can try to max out your download bandwidth if the uploader is the bottleneck). Note that this doesn't help for low-bandwidth users.

So, QRP is a proposal and not a person. Chris and Anurag are superstar LimeWire developers and pillars of the community!

Links to all technical papers are at:

http://www.limewire.com/index.jsp/tech_papers

__________________
Adam Fisk
LimeWire Developer

Woops -- looks link the lnks were too long. Just go to the last one -- it links to the others.

__________________
Adam Fisk
LimeWire Developer

Thx a lot!

Maybe it would be a good idea and spread ideas to a larger community?

I think you assume that all developers or Gnutella interested users are inside the_GDF? I personally have some problems with the_GDF: The GDF is kind of hidden and still hard to find, I think no Gnutella webside has a link on it. The GDF files (e.g. as linked above) are only available together with an Yahoo account. A lot of traffic on the list are about client orientated details, while I was only interested in Gnutella ideas, concepts and development at whole.
Also it seems that development inside the_GDF is very slow and brake appart from the real world? I remembered when Xolox came up and showed the idea of segemented downloads, or details about FastTrack has been detected (especially the very interesting superpeer concept). I have seen no comment about this breakthrough (but Vinnie Falco saying how bad Xolox and there ideas are).

Personally I have been interested in Gnutella and new ideas. Months before (before I found the_GDF by acident) I was discussing with some other guys about swarming and future ideas... but the ideas were forgotten, because we didn't find other interested users.

Maybe in future you wanna read some postings in this forum (www.gnutellaforums.com, especially "General Gnutella Discussions") - or spread your research results to a bigger public. I hope a lot of interested user will now find a way to this new forum:

"General Gnutella Development Discussion"
http://www.gnutellaforums.com/forumd...?s=&forumid=42

I think dreams, ideas and knowledge are a key to an improved Gnutella (okay _hard_ work from the client developers is another!).

Greets, Moak

PS: Very interesting link collection!! Haven't checked your site a while. Btw, I'm sorry that I never could bring some ideas to Limewires research, at least the Limewire contest is not for Europeans.

Adam Fisk, what happened to the SuperNode beta? I really liked it. The reason I dont have it now is b/c I had to reinstall then I go check and its gone from limewire.com. But I have noticed in the limewire.props of 1.8b there are some strings containg the text 'SUPERNODE'. I'm making an assumption here, but does 1.8b has supernode features? But while I'm talking about the limewire.props file I would like to know what these values mean.


EVER_SUPERNODE_CAPABLE=false

SUPERNODE_MODE=true

SUPERNODE_PROBATION_TIME=300000

CLIENT_ID=(32 characters long)

The supernode beta basically got supplanted by our 1.8b beta, although you can still get it from:

http://www9.limewire.com/beta/supern...imeWireWin.exe

or

http://www9.limewire.com/beta/supern...eWireLinux.bin

or

http://www9.limewire.com/beta/supern...imeWireMac.bin

or

http://www9.limewire.com/beta/supern...imeWireOSX.sit


The values you noticed in your limewire.props file are there because we merged some of the supernode code into the main code base prior to releasing 1.8, although it is not active.

EVER_SUPERNODE_CAPABLE simply determines whether or not we have ever measured your machine to be capable of becoming a supernode or not. This is based on operating system, your measured upload and download bandwidth, the average amount of time you run the program on average, and your firewalled status. Note that this does not necessarily mean that you are incapable of being a supernode. Rather, it indicates whether or not we have ever determined that you are capable of becoming a supernode (specifically, whether you have done enough uploads and downloads for us to determine that you have high bandwidth).

I believe that the SUPERNODE_MODE key is a relic of the early code, and will not be included in the final supernode release. The SUPERNODE_PROBATION_TIME will also no longer exist in the actual release.

The CLIENT_ID is just a random number that uniquely (more or less) identifies your machine on the network (not to us, but to other Gnutella nodes). LimeWire knows nothing about this value. It is simply used to make messages work on the network.


As far as general Gnutella development goes, we do try to create as open an environment as possible by making all of our research documents publicly available on our web site and through forums like the GDF. The problem with participating in more general forums is that it starts to be very difficult to discuss technical details on a meaningful level unless the participants have a thorough understanding of the technology -- usually meaning that they have coded a Gnutella client themselves, or could easily do so. Basically, at some point it starts to become unproductive to open the discussion completely. Right now it's open, but you just have to be interested enough to find it, and technically savvy enough to understand it. If we had more resources, it might make more sense. Right now, however, we very much have our hands full!

Thanks.

__________________
Adam Fisk
LimeWire Developer

For developers interested in getting involved, there's also the open source project at www.limewire.org. This includes a general discussion list on development issues.

__________________
Adam Fisk
LimeWire Developer