LimeWire has released the beta version of our supernode implementation,
available at:

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

In our preliminary results, client nodes receive almost no traffic over
their single, supernode connection, while supernodes are not adversely
affected by the increase in connections. The supernodes and clients also
use query routing.

If people have trouble connecting, you can try connecting directly to
216.27.158.74 on port 6357. We encourage anyone who would like to connect
to give it a try. Unfortunatley, only LimeWires can currently connect to
supernodes or become supernodes themselves (due to query routing, switching
between client/supernode
state, etc). The implementation is, as always, available from our CVS. The
branch is called supernode-branch. Credit for the supernode implementation
goes to Anurag Singla.

__________________
Adam Fisk
LimeWire Developer

I am wondering: what happened to the Sparky Project? Is it dead? Is development continuing? Or is this an evolution of Sparky?
Thanks.
:-)

__________________
~TruStarWarrior~
LimeWire Forum Moderator

Hey TruStar, how's it going?

The Sparky project is still around, and it's actually incorporated into supernodes. We were having some reservations about releasing sparky given the current dynamism of the network (Chris can tell you much more than I on this part), but with the stability that supernodes add, it makes more sense. Clients communicate with supernodes using query routing (Sparky technology) that dramatically reduces the bandwidth they must use to communicate their files to the supernode.

This also makes it possible for the supernode to forward searches to the correct client nodes connected to it far more cheaply than if they had to search through a normal index, so it makes it much less costly to become a supernode (it doesn't slow down your machine as much as it otherwise would). In terms of communication between supernodes, that will likely not use the sparky technique.

So, the short answer is that it's still around and that it's getting incorporated into the client-supernode communication.

Hope that makes sense!

__________________
Adam Fisk
LimeWire Developer

Hey LimeWire Team,
U guys make a hell of a gnutella client. Its the best but the new supernode client is a serious pain in the **** to use,
I can't even get it to connect. It just sits there idle, i ve tryed adding the recommended IP address you mentioned in
this thread but no luck.I tryed to change the port through the options menu to the one u suggested but after i click "apply" and then hit "ok" it freezes up.
Could you perhaps elaborate on what to do. Im so used to just firing LimeWire up and having it autoconnect.

By the way, do u see supernodes as the future to gnutella scaling? Will the gnutella network be able to interconnect to the sheer size of Fasttrack? I can't imagine the amount of content being available with everyone connected to one another.
Keep up the good work.

Thanks,
Sweeppicker

Dear Gnutella users, dear LimeWire team,

because I'm able to provide a connection with good speed, I somehow thought that someone would like it if I run a "SuperNode" of LimeWire. But I'm missing some kind of documentation to have a developer proved this to me. So I still wonder: What is a "SuperNode", compared to a normal client? What does it do, in contrast to a normal client? Who has an advantage of me running a SuperNode? - The first difference I discovered: I don't see a client/file statistic in the lower left part (status area), only the "Connect" button count of my shared files; my SuperNode client is running fine, though - at least many many clients are being checked.

It would be nice if I could find a hint on the LimeWire web page soon - today I could not, neither with the internal search egine nor with externals.

In respnse to the first user who has had trouble connecting, I think this is related to a more general connection problem, and not specifically related to supernodes. We took out some of the "quick connect hosts" from the supernode beta and added a supernode to that list, as we wanted to increase the likelihood that you would get connected to the supernode.

I would recommend restarting LimeWire, as the code for connecting to other users can sometimes sort of get "stuck" in a waiting state. We're going to look into this code again as soon as possible.

We definitely do see supernodes as the future of Gnutella. They allow the network to function for more efficiently, with far less messaging required across the network to search for files and to connect. With this technology, Gnutella will be able to "scale" to at least the size of FastTrack. It should significantly increase the number and quality of search results.

Thanks to everyone for trying the beta!

__________________
Adam Fisk
LimeWire Developer

I've attached a diagram that gives a better picture of what supernodes do. In the diagram, each little oval is one computer, or "node," on the network, and each line is a connection between the nodes.

The larger ovals are the supernodes. The smaller nodes are the "client" nodes. Each client node only has a connection to the supernode.

I will attach a second quick diagram in the next message (I think I can only do one attachment per post) that depicts the current network.

As you will see, sending a message out on the current network makes traffic fly everywhere. With the supernodes, the client nodes also only receive searches if they actually have the requested file. Otherwise, the supernode does not forward the search to them.

Attached Images

supernode_diagram.gif (9.0 KB, 570 views)

__________________
Adam Fisk
LimeWire Developer

Here's a depiction of the current network:

Attached Images

current_diagram.gif (3.6 KB, 567 views)

__________________
Adam Fisk
LimeWire Developer

I think I got it. Of course, all supernodes need to communicate with each other and share search requests, to allow sharing between clients which are attached to different supernodes.

It's like a step towards the eDonkey2000 concept: There, servers only manage users and search requests, but don't host files. Here, a supernode is like a two-in-one request server and user client.

This concept I would expect to give a good boost to the Gnutella network - when many clients know about this technology.

when I downloaded the beta version I received a message telling me "unable to install instashield". Does that mean that it did not install the new version or just the shield?

Afisk-

I'm doing fine. Thanks for asking. I'm glad to hear Sparky will be used in later phases of the Gnutella evolution. The diagrams were especially helpful in visualizing the concept. When do you expect to see this supernode/client scheme to be realized?

Again, thanks for your reply.
:-)

I had a SuperNode running when I left the office on Friday - let's see if it is stable and still running after the weekend...

@natalie:

I found that the LimeWire installer may need to download additional components of the InstallShield system while preparing the installation - this may depend on the operating system you are running. If it is not able to download the proper components, and therefore is unable to complete the InstallShield system, then it most probably won't be able to complete the installation of LimeWire, too.

Hi Adam,

I took your advice and restarted the limewire "supernode" client but still no luck.
The auto connect hosts just dont respond for some reason. It doesnt even appear to try and connect.
Its as if it forgets to. With Limewire 1.8 it autoconnects just fine. I had this same problem with "Sparky".
If I try to change the port via the options menu Limewire will just hang.
Im really eager to test out this beta. Sice I run Limewire 24/7 and am running off a cable modem I might have the resources to be a supernode.

Thanx again,
Mark P

> When do you expect to see this supernode/client scheme to
> be realized?

It was a long time ago that FreePeers (BearShare) created something called Defender (Before Defender was Reflector, by Clip 2). Defender too used the client/server model, where these "supernodes" handled most of the traffic, allowing low bandwidth users to connect to the supernodes and chat, search, save bandwidth, etc.

But a long time ago, expecting to implement the supernode/client model was a bit unrealistic.