Re: will never be accepted
 

It is as backwards compatible to v0.4, as v0.6 is to v0.4.

Protocol v0.7 proposal rev1 is full binary transparent with other/older clients and interacts with them without any problem. E.g. features like GUID tagging, ISO charset and optional UNICODE are full compatible even with v0.4, 0.5. 0.6 and 0.7 clients. To step further I think also features like hashs, metadata, tunneling and superpeers should be fixed part of a new v0.7 protocol (I prepared as much as possible for those proposals, see GUID tagging). See the v0.7 protocol as a possible replacement for v0.6. The intention/goal in my eyes is a more standardized and better documented protocol -> a step further to a Gnutella RFC.

I did also describe a upwards compatibility to a theoretical coming v0.8 protocol (see Appendix D).

Re. Appendix F: LAN Auto-find
 

PS: Gnucleus uses already UDP similar to suggested above. It is called 'Gnucleus LAN edition' and works without using an external Gnutella host cache. A qoute from their homepage: "Gnucleus LAN edition is really working great at colleges around the world, if your college is blocking gnutella, I suggest setting up a private Gnucleus LAN, I can find just about anything here on my 200 person LAN. In Germany there's a college with over 600 people using Gnucleus LAN, and in Ontario I got an email from someone on a gnucleus LAN of over 1,200 users!"

Swabby, a documentation or comment would be nice. :)

UDP, so your net admin can shut it off before it even gets started?

It took over a year to get .6 on most clients, leave it alone, please. Do you want to program low level stuff or more features on the client side?
Take existing code from gnuc and go from there, quit re-inventing the wheel and please use that brain of yours to make the user experience better (that's a compliment!)
.6 works, you can send more info like you want to now in the headers and all this was talked about a year ago. Besides, keep it simple and don't send lots of useless junk in the headers.

Hi anonymous, fearing improvements?

Yeah, the best idea is I'll quit and go over to ...perhaps Freenet or eDonkey. Gnutella development is snail slow and some developer are astonishing closed minded for an open potocol, the commercial influence is increasing.

If you don't see the necessity to envolve Gnutella and push it to a new quality... I see it and think it's so desperatly needed! Since months I pray for superpeers, hash, metadata, dynamic structure and improved routing of messages, to learn from other P2P systems... and especially for a common and well documented standart. I still have ideas, but I'm just a rebell rouser? The best that can happen to Gnutella in my eyes is a finished Gnutella RFC and stop of homebrew additions and v0.5/v0.6 chaos. Mentioned v0.6 protocol is just a few months old and a small step forward - right now just a new handshake and a construction site in heavy improvement (feel free to look behind the scenes and read the GDF message database). Sorry, that I try to help, analyze weak spots and suggest solutions. :-)

Greets, Moak

PS: Nobody forces you to use UDP. And Gnucleus is not my style of coding, then I prefer PEERanha (which I allready support).

Please DONT! You seems to be the most devoted person outhtere trying to bring a bit of structure into the so-called "development of gnutella protocol" which in my deepest believe is just a complete anarchy...

--Max

Skip UNICODE
 

Skip Latin1 and use UTF-8 instead.

UTF-8 = compatible
 

By using UTF-8 the protocoll will stay compatible with current clients. UTF also is UNICODE (Unicode Transformation Format), it uses 1, 2 or 3 bytes to express a character. Null bytes do not occur. English is rendered using one byte, Russian or the special characters of German or French with 2 byte, Chinese with 3 byte.

UTF-8 does entail higher traffic for Asian languages or other characters which need 3 bytes, but no pain no gain. And it will be compatible.

If you swith over to Latin-1, then you'd get compatibility problems when later moving to UTF-8.

So please, please do implement it now!!! You can catch a really worldwide user base with this!

Re: UTF-8 = compatible
 

Doesn't matter. Latin-1 is an extended ASCII clone, it is 1 byte ASCII using the extended 128-255 range, if you are in western europe you already use it. What are all pro/cons between UTF-8 and Unicode?

Broadcast and die!
 

<snip>
<p>No no no no! Fine point: DO NOT USE BROADCAST! Use multicast with a TTL of 1. It should work over any normal ethernet LAN with no worse effect then a broadcast, and on a smart lan, it will avoid bugging unintrested hosts. Furthermore, on more multicast enabled networks, the TTL could be increased to span discovery outside of the local subnet. There is no reason to use plain broadcast anymore except lazyness.

Doesn't work. How many LANs have an working multicast tunnel for Gnutella... UDP is the most simple and best working alternative, other protocols use it too. If an network admin needs to block broadcasts he can do anytime, no need or advantages from multicast.