Gnutella Forums  

Go Back   Gnutella Forums > Gnutella News and Gnutelliums Forums > General Gnutella Development Discussion
Register FAQ The Twelve Commandments Members List Calendar Arcade Find the Best VPN Search Today's Posts Mark Forums Read

General Gnutella Development Discussion For general discussion about Gnutella development.


Welcome To Gnutella Forums

You are currently viewing our boards as a guest which gives you limited access to view most discussions and access our other features. By joining our free community you will have access to post topics, communicate privately with other members (PM), respond to polls, upload content, fun aspects such as the image caption contest and play in the arcade, and access many other special features after your registration and email confirmation. Registration is fast, simple and absolutely free so please, join our community today! (click here) (Note: we use Yandex mail server so make sure yandex is not on your email filter or blocklist.)

If you have any problems with the Gnutella Forum registration process or your Gnutella Forum account login, please contact us (this is not for program use questions.) Your email address must be legitimate and verified before becoming a full member of the forums. Please be sure to disable any spam filters you may have for our website, so that email messages can reach you.
Note: Any other issue with registration, etc., send a Personal Message (PM) to one of the active Administrators: Lord of the Rings or Birdy.

Once registered but before posting, members MUST READ the FORUM RULES (click here) and members should include System details - help us to help you (click on blue link) in their posts if their problem relates to using the program. Whilst forum helpers are happy to help where they can, without these system details your post might be ignored. And wise to read How to create a New Thread

Thank you

If you are a Spammer click here.
This is not a business advertising forum, all member profiles with business advertising will be banned, all their posts removed. Spamming is illegal in many countries of the world. Guests and search engines cannot view member profiles.



           Deutsch?              Español?                  Français?                   Nederlands?
   Hilfe in Deutsch,   Ayuda en español,   Aide en français et LimeWire en françaisHulp in het Nederlands

Forum Rules

Support Forums

Before you post to one of the specific Client Help and Support Conferences in Gnutella Client Forums please look through other threads and Stickies that may answer your questions. Most problems are not new. The Search function is most useful. Also the red Stickies have answers to the most commonly asked questions. (over 90 percent).
If your problem is not resolved by a search of the forums, please take the next step and post in the appropriate forum. There are many members who will be glad to help.
If you are new to the world of file sharing please do not be shy! Everyone was ‘new’ when they first started.

When posting, please include details for:
Your Operating System ....... Your version of your Gnutella Client (* this is important for helping solve problems) ....... Your Internet connection (56K, Cable, DSL) ....... The exact error message, if one pops up
Any other relevant information that you think may help ....... Try to make your post descriptive, specific, and clear so members can quickly and efficiently help you. To aid helpers in solving download/upload problems, LimeWire and Frostwire users must specify whether they are downloading a torrent file or a file from the Gnutella network.
Members need to supply these details >>> System details - help us to help you (click on blue link)


Moderators

There are senior members on the forums who serve as Moderators. These volunteers keep the board organized and moving.
Moderators are authorized to: (in order of increasing severity)
Move posts to the correct forums. Many times, members post in the wrong forum. These off-topic posts may impede the normal operation of the forum.
Edit posts. Moderators will edit posts that are offensive or break any of the House Rules.
Delete posts. Posts that cannot be edited to comply with the House Rules will be deleted.
Restrict members. This is one of the last punishments before a member is banned. Restrictions may include placing all new posts in a moderation queue or temporarily banning the offender.
Ban members. The most severe punishment. Three or more moderators or administrators must agree to the ban for this action to occur. Banning is reserved for very severe offenses and members who, after many warnings, fail to comply with the House Rules. Banning is permanent. Bans cannot be removed by the moderators and probably won't be removed by the administration.


The Rules

1. Warez, copyright violation, or any other illegal activity may NOT be linked or expressed in any form. Topics discussing techniques for violating these laws and messages containing locations of web sites or other servers hosting illegal content will be silently removed. Multiple offenses will result in consequences. File names are not required to discuss your issues. If filenames are copyright then do not belong on these forums & will be edited out or post removed. Picture sample attachments in posts must not include copyright infringement.

2. Spamming and excessive advertising will not be tolerated. Commercial advertising is not allowed in any form, including using in signatures.

3. There will be no excessive use of profanity in any forum.

4. There will be no racial, ethnic, or gender based insults, or any other personal attacks.

5. Pictures may be attached to posts and signatures if they are not sexually explicit or offensive. Picture sample attachments in posts must not include copyright infringement.

6. Remember to post in the correct forum. Take your time to look at other threads and see where your post will go. If your post is placed in the wrong forum it will be moved by a moderator. There are specific Gnutella Client sections for LimeWire, Phex, FrostWire, BearShare, Gnucleus, Morpheus, and many more. Please choose the correct section for your problem.

7. If you see a post in the wrong forum or in violation of the House Rules, please contact a moderator via Private Message or the "Report this post to a moderator" link at the bottom of every post. Please do not respond directly to the member - a moderator will do what is required.

8. Any impersonation of a forum member in any mode of communication is strictly prohibited and will result in banning.

9. Multiple copies of the same post will not be tolerated. Post your question, comment, or complaint only once. There is no need to express yourself more than once. Duplicate posts will be deleted with little or no warning. Keep in mind a forum censor may temporarily automatically hold up your post, if you do not see your post, do not post again, it will be dealt with by a moderator within a reasonable time. Authors of multiple copies of same post may be dealt with by moderators within their discrete judgment at the time which may result in warning or infraction points, depending on severity as adjudged by the moderators online.

10. Posts should have descriptive topics. Vague titles such as "Help!", "Why?", and the like may not get enough attention to the contents.

11. Do not divulge anyone's personal information in the forum, not even your own. This includes e-mail addresses, IP addresses, age, house address, and any other distinguishing information. Don´t use eMail addresses in your nick. Reiterating, do not post your email address in posts. This is for your own protection.

12. Signatures may be used as long as they are not offensive or sexually explicit or used for commercial advertising. Commercial weblinks cannot be used under any circumstances and will result in an immediate ban.

13. Dual accounts are not allowed. Cannot explain this more simply. Attempts to set up dual accounts will most likely result in a banning of all forum accounts.

14. Video links may only be posted after you have a tally of two forum posts. Video link posting with less than a 2 post tally are considered as spam. Video link posting with less than a 2 post tally are considered as spam.

15. Failure to show that you have read the forum rules may result in forum rules breach infraction points or warnings awarded against you which may later total up to an automatic temporary or permanent ban. Supplying system details is a prerequisite in most cases, particularly with connection or installation issues.

Violation of any of these rules will bring consequences, determined on a case-by-case basis.


Thank You! Thanks for taking the time to read these forum guidelines. We hope your visit is helpful and mutually beneficial to the entire community.


Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old January 3rd, 2002
Moak's Avatar
Guest
 
Join Date: September 7th, 2001
Location: Europe
Posts: 816
Moak is flying high
Post Gnutella Protocoll v0.7 Proposal

Moak's protocoll v0.7 proposal (REVISED, see rev 1 posting below, click here)

* Take v0.6 handshaking and leave the 3rd step away ([1]).
* Replace GIV with a real HTTP style PUT/POST header
* Document GUID tagging
* Rename Ultrapeers back to 'Superpeers' or 'Superservants'
* Use ISO Latin 1 character set (ISO 8859-1) in search queries/queryhits/HTTP filenames.
* Think about an Unicode addon, for world wide file trade (including Asia)!

Hope you like it. Comments, more ideas? Moak

PS: Okay some explanations are needed. Take a look into current 0.6 handshaking in [1] [2]. The client initates a connection together with HTTP-style headers, the other side answers with an OK and more HTTP-style headers. So far so good (great idea and very flexible)! Then there is this 3rd step (before sending binary data stream), unnecessary I think: the client sends another OK. I see no purpose for the 3rd step, kick it?

Here is a sample interaction between a client and a server with a new v0.7 handshaking:
Code:
Client                           Server
-----------------------------------------------------------
GNUTELLA CONNECT/0.7<cr><lf>
User-Agent: AOLOA<cr><lf>
Query-Routing: 0.3<cr><lf>
<cr><lf>
                                GNUTELLA/0.7 200 OK<cr><lf>
                                User-Agent: Peeranha<cr><lf>
                                Query-Routing: 0.1<cr><lf>
                                Your-IP: 194.246.250.222<cr><lf>
                                <cr><lf>
[binary messages]               [binary messages]
All information are exchanged in a two step handshaking.

In the very rare case the servants need to shake hands once more and exchange more information (does it ever happen?), they can just continue with another "GNUTELLA/0.7 200 OK" round, but they don't need to. Suprised? This works because the binary message stream will never start with "GNUTELLA" (the first 16 bytes will be the GUID in a descriptor header, which byte 9 is allways 0xFF following the modern GUID-tagging rules, pseudo code: guid[8]=0xFF). (Revised, see rev 1 posting below)

Next point, replacing GIV with PUT or POST, see [3] [4]. Should be self explanary, the HTTP protocoll [5] allready provides a "upload" functionality... we can use this instead of cooking our own HTTP. For sure Gnutella's Push descriptor is still needed, no change here.

Next point, document GUID tagging as mentioned in [6]. New developers need to have a full documented protocoll to contribute.

Next point, umm, Giga-, Hyper- and Ultrapeers [7]. Can we just forget about marketing and name them simply 'Superpeers' or 'Superservants' please. :-) Only the name 'Supernode' is trademarked (Kazaa/Morpheus/Grokster use only this term on their webpages, eDonkey uses the term 'server'), everything else is free. AFAIK good old Clip2 was first mentioning superpeers or refelectors.

Last point, character set. I think we still have none and Gnutella is world wide, eeks! In a first step I suggest to orientate at the web and use ISO Latin 1 (ISO 8859-1) at least, US_ASCII or "wild wild west" isn't enough [8]. Okay, ISO Latin 1 is very selfish, I live in Europe and this will fit my needs. We also should think about a Unicode alternative, perhaps together with file hashs this will perfectly fit into a new HUGE proposal [9].

PPS: Thx to Tamama and Mike Green (Emixode), #gnutelladev

[1] Gnutella v0.6 Handshake Summary - http://www.gnucleus.com/research/connect.html
[2] Gnutella v0.6 Handshake - http://groups.yahoo.com/group/the_gd...ing%20Protocol (Yahoo account required)
[3] Gnutella V0.4/0.6 File Transfer Summary - http://www.gnucleus.com/research/transfer.html
[4] Gnutella protocoll specification v0.4 revision 1.2 - http://www.clip2.com/GnutellaProtocol04.pdf
[5] HTTP/1.0, RFC 1945 - http://www1.ics.uci.edu/pub/ietf/http/rfc1945.html
[6] Gnutella GUID tagging - http://groups.yahoo.com/group/the_gdf/message/1397
[7] "Ultra"peers - http://groups.yahoo.com/group/the_gd...ltrapeers.html (Yahoo account required)
[8] ISO 8859-1 character set - http://www.htmlhelp.com/reference/charset/
[9] "HUGE" - http://groups.yahoo.com/group/the_gd...roposals/HUGE/ (Yahoo account required)

Last edited by Moak; February 15th, 2002 at 10:05 AM.
Reply With Quote
  #2 (permalink)  
Old January 4th, 2002
Enthusiast
 
Join Date: January 1st, 2002
Posts: 34
Tamama is flying high
Default some more thought ?

Without the 3rd step in connecting to a server additional requests are very hard(read, non-conform.. like the HTTP/1.0 and GNUTELLA/0.4 on the same port.) to do. Thus one could see this as a 'future guaranty' that extensions could be implemented. However what would a server do if it would get a bad(read, unknown) header? Right!, usually they disconnect. This needs to be more documented.

However you most likely do not need the additional requests because in the two headers that are send to and from the server is all the information one would probably ever need. If one could think of a request that needs to be done outside the initial 2 handshake headers, please post them here


The Uni code character sets could be negotiated in the header. However if not all clients support unicode then searches might come out wrong (or worse, block) at a given server in the network. Also unicode is 2 bytes, so it will add extra overhead on the network.

Example:

A doesnt do unicode
B does
C does

A - B - C

B needs to 'downgrade' search requests and 'upgrade' searchhits from A to B or C. This would be very hard for example chinese to standard ASCII.

Some more thought might be usefull, but I like the idea


I didnt even know about the 0xff at byte 9. It serves no real long time purpose either. New clients will simply use the new standard, and they can be just as bad at routing (read, none) and ping/pongs as the old clients. Some non-yahoo group (emailed) based paper on these GUIDs would be nice indeed.

Tam
Reply With Quote
  #3 (permalink)  
Old January 4th, 2002
Moak's Avatar
Guest
 
Join Date: September 7th, 2001
Location: Europe
Posts: 816
Moak is flying high
Default Re: some more thought ?

Hi Tamama!

> Without the 3rd step in connecting to a server additional
> requests are very hard [...] to do.


Hmm, really? You can just repeat the first steps again and again (if you really need it, 4 steps, 6 steps, 8 steps...). So we are flexible here. In most cases two steps will be fine, I guess. The transition from connect-sequence (HTTP-headers) to binary messages (Gnutella descriptors) could be easily detected: If there is no further string "GNUTELLA/", the binary data stream starts and will run until disconnection of that peer. (Revised, see rev 1 posting below)

> However what would a server do if it would get a bad [...] header?
> Right!, usually they disconnect.


They ignore it as far as I understood the v0.6 handshaking? Each side tells what it supports or wants (2 sides = two steps), then they start to talk Gnutella. If one side doesn't know a feature of the other side, it ignores it. When both sides supports a feature (e.g. 'Query Routing'), then they can use this feature.
It's similar to what happens when a v0.4 client connects a v0.6 client. The old client will connect with "GNUTELLA CONNECT/0.4<lf><lf>", the modern client will recognize this and not continue with a 0.6 connect sequence, instead use the "common language".

> If one could think of a request that needs to be done outside
> the initial 2 handshake headers, please post them here


Dito

> B needs to 'downgrade' search requests and 'upgrade' searchhits from A to B or C.
> This would be very hard for example chinese to standard ASCII.


Yep, veeeery hard! *g* Therfore I suggested to use only ISO LATIN 1 as a default, no negotiation in the connection header!
But within Query/Queryhits a asian client might want to use Unicode (e.g. chinese characters). All other asian clients will understand and could reply... non asian clients don't understand (they don't have asian files), but can route without problems. This type of communication does perfectly fit into the HUGE proposal. With a unicode standard all world wide servants can communicate and speak the same language. Actually also non asian clients could be part of a world wide swarming, when they understand UNICODE.
I also prefer ISO_LATIN 1 as default, because it is a one byte code per character, while UNICODE is a multibyte code! UNICODE as default would unnecessarily increase the allready high broadcast traffic.

> Some non-yahoo group (emailed) based paper on these GUIDs would be nice indeed.

Hehe, yep. At least the required Yahoo account is very anoying IMHO and doesn't help to attract new developers.

Greets, Moak

Last edited by Moak; January 5th, 2002 at 02:57 AM.
Reply With Quote
  #4 (permalink)  
Old January 4th, 2002
Enthusiast
 
Join Date: January 1st, 2002
Posts: 34
Tamama is flying high
Default

ok after some talking etc etc

[] = optional
--- = seperator, in between lines are \r\n seperated
... = repeat

client:

---
CONNECT GNUTELLA/0.7
User-Agent: FastFinder 3.4
ultrapeer: 0.1, 0.2
Gnutella: 0.7
[more header-information]

---

server:

---
GNUTELLA/0.7 OK All dandy and fine nice mister client
User-Agent: Peerhana 0.5
ultrapeer: 0.2
ultrapeer: 0.3
Gnutella: 0.7, 0.8, 0.9
[more header-information]

---
<binary data starts>

As you can see header fields are used to tag _all_ allowed extensions. The extensions that are common are automatically activated.

header fields are build up as the following:

&lt;name&gt; : &lt;content&gt;
&lt;name&gt; = &lt;string&gt;
&lt;content&gt; = &lt;string [,&lt;string&gt;...]
&lt;string&gt; = array of characters not containing special characters like \r\n : , etc.

This allows for shorter headers as version numbers can be put on 1 line


Tam

Last edited by Tamama; January 4th, 2002 at 02:53 PM.
Reply With Quote
  #5 (permalink)  
Old January 5th, 2002
Moak's Avatar
Guest
 
Join Date: September 7th, 2001
Location: Europe
Posts: 816
Moak is flying high
Post Moak's Gnutella Protocol v0.7 Proposal rev 1 - March 2002

Hi, talking with Tamama, Emixode and Bmk I found it necesarry to overwork the proposal a little bit. :-)

Main goals for a new 0.7 protocol are:
- full HTTP alike connections, to achieve an easy parser
- straight and simple connection sheme, easy and fast
- very flexible desgin for later needs, avoiding a 0.8 in near future *g*
- don't hurt old v0.4 servants, let them still be operable

Appendix A: Extended HTTP style connecting
First of all we make the connection sequence full HTTP like (to use the same parser on all incoming connections). I suggest to use 'CONNECT REQUEST GNUTELLA/0.7', the response 'GNUTELLA/0.7 200 OK' is allready correct.

Then I suggest a slightly different connection handshake to what I wrote in the original post. A v0.7 servant will implement too alternatives:

* 1st handshake alternative: Fast-Connect
Overview: Default handshake, fixed 2 steps (may be repeated in case of error codes)

Here is a sample interaction:
Code:
Client                           Server                            Comments
-----------------------------------------------------------
CONNECT REQUEST GNUTELLA/0.7&lt;cr&gt;&lt;lf&gt;                               <- step 1
User-Agent: AoloA/1.0&lt;cr&gt;&lt;lf&gt;
Query-Routing: 0.2, 0.1&lt;cr&gt;&lt;lf&gt;
&lt;cr&gt;&lt;lf&gt;
                                GNUTELLA/0.7 200 OK&lt;cr&gt;&lt;lf&gt;        <- step 2
                                User-Agent: Peeranha/1.2&lt;cr&gt;&lt;lf&gt;
                                Query-Routing: 0.1&lt;cr&gt;&lt;lf&gt;
                                Your-IP: 194.246.250.222&lt;cr&gt;&lt;lf&gt;
                                &lt;cr&gt;&lt;lf&gt;
[binary messages]               [binary messages]
The Fast-Connect is default, it will be the most used connection type. Easy and simple. Each client tells usually _all_ (interesting) features it supports in the headers, once. Unknown headers are ignored, for known headers the from both highest supported version is used. After those two steps (two clients = two steps) the binary messages start automatically.
Two exceptions: a) If the server does not respond with '200 OK' the same procedure is started again (perhaps the server disconnects, but it doesn't need to). b) If the client or the server sends an Header 'Full-Handshake: Yes', they _have_ to continue with the full handshake (described next).

* 2nd handshake alternative: Full-Handshake
Overview: Optional, minimum 4 steps (+ 2*x steps)

Here is a sample interaction:
Code:
Client                           Server                             Comments
-----------------------------------------------------------
CONNECT REQUEST GNUTELLA/0.7&lt;cr&gt;&lt;lf&gt;
User-Agent: CatDog/2.4&lt;cr&gt;&lt;lf&gt;
Query-Routing: 0.1&lt;cr&gt;&lt;lf&gt;
&lt;cr&gt;&lt;lf&gt;
                                GNUTELLA/0.7 200 OK&lt;cr&gt;&lt;lf&gt;
                                User-Agent: CatDog/2.5&lt;cr&gt;&lt;lf&gt;
                                Query-Routing: 0.2, 0.1&lt;cr&gt;&lt;lf&gt;
                                Your-IP: 194.246.250.222&lt;cr&gt;&lt;lf&gt;
                                Full-Handshake: Yes&lt;cr&gt;&lt;lf&gt;         <- recognize this
                                Query-Routing-Extra: feature xyz requested&lt;cr&gt;&lt;lf&gt;
                                &lt;cr&gt;&lt;lf&gt;
CONNECT HANDSHAKE GNUTELLA/0.7&lt;cr&gt;&lt;lf&gt;                              <- more handshake
Query-Routing-Extra: feature xyz accepted&lt;cr&gt;&lt;lf&gt;
&lt;cr&gt;&lt;lf&gt;
                                GNUTELLA/0.7 200 OK&lt;cr&gt;&lt;lf&gt;
                                &lt;cr&gt;&lt;lf&gt;
START BINARY GNUTELLA/0.7&lt;cr&gt;&lt;lf&gt;                                   <- ending handshake
&lt;cr&gt;&lt;lf&gt;
                                GNUTELLA/0.7 200 OK&lt;cr&gt;&lt;lf&gt;
                                &lt;cr&gt;&lt;lf&gt;
[binary messages]               [binary messages]
The Full-Handshake is similar to number 1, optional, whenever one side needs/requests it with the 'Full-Handshake'-header (see comments above). The first 2 steps are the same as in number 1, but this alternative requires an additional 2 step ending handshake before beginning the binary messages (= 4 steps minimum). In the example above you will see two more handshakes steps in between (= 6 steps), even more are possible. The ending handshake is needed as a seperator/transition from HTTP handshaking to binary data, because this alternative allows more then 2 fixed steps. In contrast to the original v0.7 proposal, this is less "hacky". :-)

Why doing all this? The whole connection sheme was designed for easy parsing + effectivity + flexibility. The technical background: While we mostly will use the first intuitive two-step handshake, we introduced the optional flexible handshake for future/extended use (currently we do not need it, especially if someone wants to transfar proprietary data then let those clients deal with it, proprietary is nothing that a handshake should care about, better improve the protocol for the sake of everyone). Especially the second alternative may look oversized, but after long discussions I think this is the way to fit all needs and it's highly HTTP orientated (HTTP we allready use and it promises to be a robust and successfull design). Developers, plz play arround with all posibilities you could imagine, this design should hopefully make your code easy & flexible.

Summary: A V0.7 client will understand the following HTTP and GNUTELLA methods: GET, PUT, CONNECT, START (and GIV, GNUTELLA).

GET for downloading files - e.g. 'GET /get/1283/gnutti.deb HTTP/1.0'
PUT for uploading files (was GIV in v0.4) - e.g. 'PUT 1283:72814A49E69D0F43AAB400/gnutti.deb HTTP/1.0'
GIV for backwards compatibility only, see PUT - e.g. 'GIV 1283:72814A49E69D0F43AAB400/gnutti.deb HTTP/1.0'
CONNECT to initiate a connection handshake - e.g. 'CONNECT REQUEST GNUTELLA/0.7'
CONNECT to continue a started connection handshake - e.g. 'CONNECT HANDSHAKE GNUTELLA/0.7'
GNUTELLA for backwards compatibility only, see CONNECT - e.g. 'GNUTELLA CONNECT/0.4'
START to end the handshake and start the binary data stream - e.g. 'START BINARY GNUTELLA/0.7'

Notes: Do not continue an established handshake with CONNECT REQUEST (this will reset headers and start over), use CONNECT HANDSHAKE. You should not add proprietary data to a Fast-Connect, it would be ignored by all other clients and wastes bandwith, instead take a look at the Full-Handshake example.

Some geek notes: Our Gnutella specification consists of HTTP 1.0 methods (GET, PUT) and GNUTELLA specific methods (e.g. CONNECT, START), all are full HTTP like. Our Gnutella specific methods allow multiple headers, so they actually look more like a HTTP 1.1 request. We define 'Content-Length=0' if the Conten-Length header is not given in Gnutella specific methods (Tamama *g*). This avoids adding 'Content-Length=0' to every CONNECT|START request, since we have no content/payload here.

Response codes are typcial HTTP like responses including status code - e.g. 'GNUTELLA/0.7 200 OK'. [1]

Appendix B: New GUID-Tagging
We introduce a new GUID-Tagging style, first the documentation then additional explanations:

* Byte 16 is used to show the highest supported protocol version, pseudo code: guid[15]=0x07 in this protocol version (up to v25.5 is possible with 8 bits, every value below 4 is treated as v0.4).

* Byte 9 is used to sign if the peer supports special features, bitcoded, low active, 0xFF means no features (backwards compatibility with older clients). The coded features in those bits are important for routing/broadcasting messages:
Bit 0: Peer acts as superpeer (important for network structure)
Bit 1: Peer acts as proxy/tunneling peer (important for firewalled or NAT-routed hosts)
Bit 2: Peer does understand and request metadata
Bit 3: Peer does understand and request file hash
Bit 4: Peer does understand and use UNICODE (UTF-8 encoded)
Bit 5: Peer does have chat support (important for community idea)
Bit 6-7: reserved
The 2 higest bits are reserved/locked and should be allways 1! Again backwards compatibilty, very old clients had a 10XXXXXX setting, which we have to avoid. The default for current v0.4/v0.6 clients is 11111111 which is also our default = no features.

Why using (oldfashioned) GUID tagging over Handshaking? No, it's a new idea behind and both work together. GUID-features are routed along the network (tell status features a far away host), while handshaking features can only used with the direct connected hosts. You can shake hands with direct connected hosts, but not with a hop=5 away peer.
Mainly the GUID feature bits are used to avoid unnecessarily routed/broadcasted messages, e.g. only when a peer understands metadata you need to send him metadata. When a peer just searches for alternative download locations (searching with a hash), the other peers should not answer with metadatas to save bandwith. Secondarily GUID protocol version provides a faster connect. A host cache will receive a PING from any host connecting, it will answer with collected PONGs. [2] Those PONGs will now carry the Gnutella protocol version of the servant inside the GUID. E.g. you can now directly connect an old 0.4 servant with the old protocol or only connect to superpeers. Connecting is faster.

Notes: Feature bits should be discussed, before finishing this protocol version. To detect client version and features use the following pseudo code (this is NO 100% guarantee!):

int protocol = 4; // fallback to v0.4
struct {
unsigned reserved : 2;
unsigned bChat : 1;
unsigned bUnicode : 1;
unsigned bFileHash : 1;
unsigned bMetadata : 1;
unsigned bProxyTunnel : 1;
unsigned bSuperpeer : 1;
} features = 0; //no features yet
if((guid[8] & 0xC0)=0x80) protocol=4;
else if(guid[15]>=0x04) protocol=guid[15];
if(protocol >= 7) features = guid[8] ^ 0xFF;

Appendix C: Character set and UNICODE expansion
While talking with some other developers, I found out that my idea was too short/confusing, here is a more detailed suggestion:
* First use ISO_LATIN 1 as basic charset in all HTTP header and/or Gnutella strings (propably you allready did this). This won't hurt anyone and will fit most European/American/Australien needs to transport national special characters (e.g äåæ). But... and this is a big "but", this character set will not fit asian, russian needs and more languages. While Gnutella messages are routed through various servants it is impossible to translate one chracter set into another, the solution is UNICODE.
* Second use optional UNICODE in Gnutella strings (Query/Queryhits), if you really need it. Unfourtunately Unicode is a two byte code per character + Unicode contains zero bytes (A = 'a', '\0') which is a problem too. So Unicode must be encoded, we use UTF-8 (see later post for details).

Why not using Unicode allways? Oops, the binary datastream would not be backwards compatible with v0.4 and it would also blow up Query/Queryhit unnecessarily compared to ISO_LATIN 1 (1 byte vs multibyte characters, bigger size = bigger query traffic, eeks). Why not using another character set than ISO_LATIN 1? Whatever you choose it wouldn't fit a world wide need. Do we need to negotiate UNICODE in the connect handshake? No, since UNICODE is routed in Query/Queryhits it will travel the whole network mesh and is not affected by direct connected hosts. Instead we use the GUI-tagging (see above).

Notes: The two step solution above is my suggestion, perhaps is is better to skip Latin1 completly and use UTF-8 only (topic of further investgations). With the two step solutions all clients speak a common character set (ISO_LATIN 1), very easy to implement, the UNICODE (UTF-8) is optional for clients which want to offer an extended language support or do not use ISO_LATIN1 codepage on their system. While UNICODE (UTF-8) is encoded inside the Query/Queryhit every "basic" client will route it without any problem. Okay, an old client will not understand it, but that is no problem, e.g. a non asian client will usually have no asian files.
I might post a new proposal for a "specialized horizons" header. This allows to group similar interests and traffic together + keep in touch world wide. In this special context here it will help to route e.g. asian unicode primary between ppl offering asian content.

Appendix D: Backwards/Upwards compatibilty
Backwards compatibility with incoming protocol v0.4 is full guranteed. All incoming v0.4 clients should be answered with the simple v0.4 handshaking. Outgoing connections should be started depending on the GUID tagging, however if v0.7 doesn't suceed try v0.4. About v0.6 backwards compatibilty, while the handshake is incompatible with v0.7, I suggest to make this decision client vendor dependent, if you wanna support v0.6 just do it, it's optional.

Here is a sample handshake, old client knocking at the door:

Code:
Client                           Server                     Comments
-----------------------------------------------------------
GNUTELLA CONNECT/0.4&lt;lf&gt;&lt;lf&gt;                                &lt;- old client
                                 GNUTELLA OK&lt;lf&gt;&lt;lf&gt;        &lt;- ok, we speak old 0.4
[binary messages]                [binary messages]
Upwards compatibility is also supported (as long as the handshake is compatible, hopefully it is).
Here is a sample handshake, newer client tries to connect:

Code:
Client                           Server                     Comments
-----------------------------------------------------------
CONNECT REQUEST GNUTELLA/0.8&lt;cr&gt;&lt;lf&gt;                        &lt;- new version!?!
User-Agent: AoloA/1.8&lt;cr&gt;&lt;lf&gt;
&lt;cr&gt;&lt;lf&gt;
                                GNUTELLA/0.7 501 Not Implemented&lt;cr&gt;&lt;lf&gt;
                                User-Agent: AoloA/1.7&lt;cr&gt;&lt;lf&gt;
                                Gnutella-Protocol: 0.7, 0.4
                                &lt;cr&gt;&lt;lf&gt;                    &lt;- Server doesn't disconnect
CONNECT REQUEST GNUTELLA/0.7&lt;cr&gt;&lt;lf&gt;                        &lt;- Client starts over
User-Agent: AoloA/1.8&lt;cr&gt;&lt;lf&gt;
&lt;cr&gt;&lt;lf&gt;
                                GNUTELLA/0.7 200 OK&lt;cr&gt;&lt;lf&gt;
                                User-Agent: Aoloa/1.7&lt;cr&gt;&lt;lf&gt;
                                Your-IP: 194.246.250.222&lt;cr&gt;&lt;lf&gt;
                                &lt;cr&gt;&lt;lf&gt;
[binary messages]               [binary messages]
Appendix E: Misc
More stuff for brainstorming and documentation....

Let's collect and write down everything that was introduced since v0.4 and is fact in modern clients! I think about blocking webbrowsers (with Referrer header), what more?

Let's think about a chat specification. Perhaps IRC based or IRC DCC for inbetween client communication, perhaps HTTP based.

Integrate the Bye-Descriptor [3] into the v0.7 protocol. Make this message also full HTTP (pure text string, no byte codes) [1]. Perhaps we should also notify downloader and send them a new HTTP BYE message?

Define clients research and retry behaviour. When a peer drops the connection, you want to resume/reconnect. Such a retry should be well defined to avoid "hammering" foreign IPs.

Most important points at the end, a big TODO, workout and define protocol features for: superpeers, dynamic traffic routing, hashs, metadata and (friendly) anti-freeloading behaviour (we had various posts in this forum discussing those topics).

Ah, don't forget to vote for 'Superpeer'... not Ultra-Hyper-Giga-Peer. :-) Keep Marketing and prorprietary ideas out of Gnutella!

Comments, more ideas? Greets, Moak

PS: I might summarize all ideas into one paper later, we still need to work out this proposal. Feedback is highly welcome! Send me a PM (private message) or meet me on IRC. :-)

[1] HTTP/1.0 Status Codes, RFC 1945 - http://www1.ics.uci.edu/pub/ietf/htt...l#Status-Codes
[2] Gnutella Host Caches - http://www.gnutellaforums.com/showth...&threadid=5807
[3] Bye Descriptor - http://groups.yahoo.com/group/the_gd...ls/BYE/Bye.txt (Yahoo account required)

Last edited by Moak; March 21st, 2002 at 03:39 PM.
Reply With Quote
  #6 (permalink)  
Old January 5th, 2002
John Blackbelt Jones's Avatar
Gnutella Veteran
 
Join Date: November 11th, 2001
Location: Germany
Posts: 103
John Blackbelt Jones is flying high
Default

I've got a couple of questions:

1) Why won't you use HTTP 1.1 (it has the one or the other advantage)?

2) Does the gnutella 0.4 spec say anything about the charset to be used for gnutella messages? I already searched for files with äöü... and also found them with LimeWire.

3) Wie heißt die Transformers Episode mit dem Hasstaub auf englisch?
Reply With Quote
  #7 (permalink)  
Old January 5th, 2002
Moak's Avatar
Guest
 
Join Date: September 7th, 2001
Location: Europe
Posts: 816
Moak is flying high
Default

1) We do not need it? Actually the new v0.7 Gnutella specific methods look more HTTP/1.1.

2) Protocoll v0.4 mentions no character set, they speak about "ASCII encoded" strings (= wild wild west, every chat above '\127' is undefined yet). Protocoll v0.7 defines ISO_LATIN 1, which includes US_ASCII as subset (backwards compatible).
Reply With Quote
  #8 (permalink)  
Old January 6th, 2002
Abaris's Avatar
Ringwraith
 
Join Date: May 13th, 2001
Location: Europe
Posts: 86
Abaris is flying high
Default

3) Transformers Volume 7: The Return Of Optimus Prime
Reply With Quote
  #9 (permalink)  
Old January 9th, 2002
Moak's Avatar
Guest
 
Join Date: September 7th, 2001
Location: Europe
Posts: 816
Moak is flying high
Default

Appendix F: LAN Auto-find & Proxy configuration

How about an "auto-find" feature for servents running in a LAN?

The idea: Multiple servents running in a LAN could easily find each other and connect automatically. Perhaps on a LAN party or in a home network, servents will find each other without running an additional hostcache or manual configuration (plug'n'play). Similar to multiplayer games where you click on "LAN games" and then you'll see all running servers, no need to configure IP/port manually.

Implementation: Each servent sends a UDP broadcast [1] on startup to the LAN (only internal LAN devices, not to the internet) and every servent will answer with an UDP "pong". The binary data within those UDP datagrams should be identical with Gnutella's ping/pong descriptor (for reusing the existing methods/code!).

There's more... supplementary idea 2: It may usefull to define a servent which is the link to another network segment or to the internet, a superpeer with proxy/tunneling ability. All clients in the LAN will auto find this servent (LAN UDP broadcast again) and then use this superpeer all together to connect to the internet, instead of each and everyone connect on their own.
I think this last feature is very important for two reasons: a) Internet bandwith is used more efficient and b) a superpeer proxy could increase download succes for people behind a NAT router. A NAT router usually allows no incoming connections, peers behind two different NAT routed networks can not share files (also not via Gnutella's push, see here). Such hosts are the majority following Limewire's host statistics [2]. A superpeer proxy in the LAN could be the missing link and reroute/tunnel those requests to the correct servent = more shared files, higher download rate.

Implementation: Similar to UDP broadcasts above, a proxy servent will set the equivalent GUID features bits (bSuperpeer, bProxyTunnel) before answering with an UDP "pong". Additional handshaking headers are needed to negotiate proxying and tunelling [3] between clients and superpeer, topic for further investigations.

Notes: Do also cross check with the 'Your-IP' handshake header in Appendix A, this header is used to tell the local peer (or tunneling proxy peer) the external IP of your NAT router (IPs could be dynamic since most ppl do not have a static IP). Furthermore see Apendix B, the GUID tagging Byte 9 Bits 0-1 define the mentioned superpeer and proxy/tunelling ability.

Result: We achieve a full automatic LAN client find + automatic proxy configuration (elimination of today existing bottlenecks with NAT routers, traffic minimization).

[1] UDP Broadcasts - http://tangentsoft.net/wskfaq/interm...html#broadcast
[2] Limewires's Gnutella Network Size - http://www.limewire.com/index.jsp/size
[3] Gnutella Tunneling - http://groups.yahoo.com/group/the_gd..._discusion.txt (Yahoo account required)

Last edited by Moak; January 14th, 2002 at 06:09 PM.
Reply With Quote
  #10 (permalink)  
Old January 10th, 2002
Unregistered
Guest
 
Posts: n/a
Default will never be accepted

"* Take v0.6 handshaking and leave the 3rd step away (see [1]). (Revised, see rev 1 posting below)
* Replace GIV with a real HTTP style PUT/POST header
* Document GUID tagging
* Rename Ultrapeers back to 'Superpeers' or 'Superservants'
* Use ISO Latin 1 character set (ISO 8859-1) in search queries/queryhits/HTTP filenames.
* Think about an Unicode addon, for world wide file trade (including Asia)! "

The problem with this is that it's not very backward compatable. Trust me there have been hundreds of these type of proposals, none have made it.

The reason 0.6 made it was the it was backward combatible. It only involved the hadn shaking mechanism, so a servent could have both 0.6 and 0.4 connections.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Proposal for development of Gnutella (hashs) Unregistered General Gnutella Development Discussion 61 April 17th, 2002 08:35 AM
My Proposal for XoloX!!! Unregistered User Experience 1 February 6th, 2002 08:11 AM
What does 'Gnutella v0.6 protocoll' mean? Moak LimeWire Beta Archives 0 December 12th, 2001 10:03 PM
---a Radical Proposal--- Unregistered General Gnutella / Gnutella Network Discussion 0 September 21st, 2001 12:08 PM
protocol extension proposal Unregistered General Gnutella Development Discussion 3 September 16th, 2001 02:00 PM


All times are GMT -7. The time now is 02:20 AM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
SEO by vBSEO 3.6.0 ©2011, Crawlability, Inc.

Copyright © 2020 Gnutella Forums.
All Rights Reserved.