Protocol Specifications and Actual implementations
 

I wish to know which specifications of the RFC-gnutella protocol draft are acomplished by the diferents servants (gnucleus, limeware, etc).

Specifically, which of the proposals like QRP, Ultraper, HUGE, XMP Metadata are implemented.

And more specifically how QRP, and HUGE and Metadata relate each other (Hash tables policys etc).

Thanks

Re: Protocol Specifications and Actual implementations
 

You desire all of this information yet you do not disclose your intentions behind your considerable request, nor do you deign to register here.

This one goes into the 'classics folder' for consideration to keep. :p

Ursula, such negativity! Why not answer his simple question? Grudge against unregistered users?

There is more info on the_gdf about this, but it's hard to know unless you follow the_gdf posts and read the client's latest release notes.

You have to sign up, but read the "database" there also.
http://groups.yahoo.com/group/the_gdf/messages/

yes, I'd wish Urusla posts less.

Re: Protocol Specifications and Actual implementations
 

What you see on the RFC's site are only reference links to current proposals. What is going to be in the actual RFC might not encompass all or some of the variants you mentioned.

QRP and Ultrapeers go hand-in-hand. Ultrapeers will be mentioned in the RFC (currently as an "optional" implementation), per the LimeWire specs. On the GDF, there's some discussion about using SHA1 with Ultrapeers as well, but we'll have to await the outcome of that one, as not everyone was very accepting to that idea. Nonetheless, HUGE will also be included with the RFC, probably as an optional item.

The drawback of some proposals is that they don't re-use the code of another proposal or implemented feature. For example, QRP uses different hashing (albeit for obvious reasons, as they're not used in the same way) than HUGE. That would require two different hashing methods within the code. It bloats the Gnutella client unnecesary.

It's probably good to quitely follow the GDF's progress (see http://groups.yahoo.com/group/the_gdf). Occasionaly, there's some mud fights, but usually developers can come to an agreement or offer very good ideas. Actual participation does require you to be prepared for a mud fight tho :p

Re: Protocol Specifications and Actual implementations
 

LimeWire implemented HUGE (v2.5+), QRP/Ultrapeers (v1.9+), Metadata (no idea when), GGEP (2.5+). 2.5 is not released yet.
Bearshare implemented initial HUGE support in v2.6, QRP in v3.0 (still beta).
Gnucleus implemented initial HUGE support (I don't know when), QRP in v1.8.

This is no secret, I can only suggest (as Mike already did) that you search through the GDF archives if you are looking for more specific answers - or ask around in the clients forums.
The official gnucleus forum is at www.gnucleus.net
The official Bearshare forum is at www.bearshare.net
The official LimeWire forum is here

You've always a good chance of getting a reply of the Bearshare/Gnucleus developers. The LimeWire developers don't come here very often. You'll probably have to deal with some LimeWire zealots trolling in the LimeWire forums (my opinion is, that you gotta be completely out of your mind to use that damned LimeWire crap).

Put the blame on me
 

I'm the author of the message thats begin this thread. I didn't register at that moment only becouse i hadn't time. So, relax please.

I'm thinking about make a gnutella servant. There are my terrific "intentions behind my considerable request" (Ursula dixit).

Moak, Cultiv8r,

Yes, i enter the GDF (and see its docs and database) but the problem is that the GDF is, primarily, a running discusion about proposals, so, if one there wasn't at beginning of the discussion, then the new member need to read near 8000 posts. So, there isn't a clear bottomline from which begin to build, with or without the latest proposals (the only clear protocol implemented version is 0.4, and is clear that this version is really obsolete).

I didn't see also clear release notes where i could read the levels of the protocol that each implementations acomplish. If anyone knows about that, please tell me.

Remains the posibility or study the sources of, for example, gnucleus and limewire (i yet begun to do that), but it's hard work. And some programs like Bearshare seems to be close source (is that true?).

About hashing i don't see a problem between diferent hashing methods in HUGE and QRP, since the targets of both proposals are completely diferrent (contens, MBs of data vs keywords, some characters to binary hash tables), so it is not rare that you need two diferent hash algorithms. But i actually see a problem in metadata and HUGE mixed with QRP, since the rich metadata search were proposed and the QRP don't solve searches in the hash tables with a metadata or urn query. And this is a important problem becouse, as you said, QRP is the base of ultrapeer, and, if QRP don't discriminate thru hashtables a lot of searches, then need to broadcasting a lot and the ultrapaper schema will lose its sense.

Of course, you would say me that the only solutions of my questions is to study the GDF and so on and so forth, but, sometimes, someone had have the same problems that you and have (possibly part) the answers, so I try to ask.

Additional problems is that gnutella network seems to decrease its user since the great boom of morpheus inclusion. I am talking about limewire stats. The only comparative stats that I found was in http://www.slyck.com/. And they show gnutella don't get to ride the wave. I ask slyck about where that’s stats come from, but they don't reply me. If anyone knows other stats, and how are the sources of stats, please tell me.

Anyway, what I am trying to say, it's that I understand is normal the undefinition in a developing issue like gnutella, but its true too that is needed some type of checkpoint agreetment for the gnutella community gets a solid grown, becouse there are a competition out there and the gnutella possible advantage is cooperation.

Thanks, and sorry about my poor english.

Thanks a lot.
 

Taliban,

I didn't read your answer when i post my previous reply. So, thanks again.

I anyone could answer my others questions that would be very nice too.

And other question. Anyone knows something about the lattest fasttrack (closed) protocol, or others, and how they handle these issues.

The gnutella stats are calculated with a crawler, - that's a piece of software that connects to many gnutella nodes to gather statistical information.

The main problem of the LimeWire crawler is, that it's very inaccurate.

One reason for that is, that it's counting clients without actually knowing how long those clients are going to be online. After a while, the client address will simply expire in the crawler cache and when it encounters it again it will count it again. The other reason is, that the crawler might not reach certain regions of the network, which are poorly connected to the rest of the gnutella network.

The numbers at slyck.com (I assume they get them from limewire.com) were dropping because of the new Morpheus 1.9 which introduced ultrapeers that probably didn't affect the overall size of gnutella but only the crawlers.

The problem of the GDF is, that they are indeed not working together very well. The developers have different philosophies which lead to slightly different designs, so each client might break each other's features (Gnucleus/Morpheus for example blocks most of the ping reply messages which LimeWire clients need to stay connected to the network and calculate the size of the reachable portion of the network). There are endless discussions on what to implement and how to implement it which slow down the development of the clients.

I guess if some of the more advanced clients connected to private networks, you'd have far more efficient networks, although the networks would be much, much smaller. The heterogenous network was the decision of the client developers, although fasttrack (with a similar yet closed protocol) has the by far better performance, the gnutella protocol is probably more robust (against lawsuits and dos-attacks).

Very true tp2p. As far as beginning with Gnutella, I recommend implementing standard v0.6 Gnutella protocol. It consists of everything v0.4 has, except the handshake method, which was extended to allow more features. Whether you provide backward compatibility with the v0.4 handshake is up to you, but v0.6 is pretty much considered "de facto" now.

Once you've done that, I highly recommend implementing the Ping/Pong cache sheme. Which one you choose is pretty much up to you, as all the proposed variants have the same "external effect", just work differently internally (code wise).

After that, I'd say that it will be up to you to choose which features you'd like to include, such as Ultrapeers, HUGE, compression, etc. They are not mandatory features, although they can be very beneficial to your end users.

As far the GDF goes, yes, developers there do have a tendency to drag topics a beyond comprehension. So it's hard for newcomers to follow what exactly is going on. But it's fine to jump in and ask a question, even if the same thing has been discussed before. Plenty out there that are willing to help you out.