Re: Re: Implementing a Gnutella-structured network only with basic HTTP possible?Date: Wed, 24 Feb 2010 09:08:15 +0000 (UTC)

Hi Arne, Raphael,

I think you both have excellent points. The complexity of the protocol
is too high, and it does discourage new developers and new ways of using
Gnutella - but the wire protocol's only a small part of that complexity.
The larger problem is that a peer must implement several rather
complicated features before other peers will even talk to it. There's no
equivalent in Gnutella of a dumb router that just forwards packets
without knowing about the higher-layer protocols those packets
implement, or a dumb client that uses higher-layer protocols without
knowing how they're implemented at the packet level. Layering is
completely broken, so it's all or nothing - and "all" is too much for
most developers to chew.

So we seem to have a rather unappealing choice. We can let the network
stagnate, as fewer and fewer new developers get involved. We can abandon
the network and start from scratch - but given the huge number of people
still using Gnutella and the uncertainty of persuading them to move to
another network, that seems like a desparate measure. Or we can try to
plan a gradual transition from the current network to a simpler, more
maintainable one, with lower barriers to entry.

That may not be possible, but let's talk about some ideas before we decide.

Cheers,
Michael

[email protected] wrote:
> Hello Arne,
> 
> Quoting Arne Babenhauserheide <[email protected]> from ml.gnutella.dev-forum:
> :I'd love to hear your thoughts on the idea. 
> 
> I've read your proposal in its entirety, but I'm not sure you're going to
> love hearing my thoughts. :-)
> 
> :Do you think it would be useful - and help getting more developers into 
> :Gnutella again?
> 
> I think it would be totally useless:
> 
> 1) You're talking about a major change in the way peer-to-peer communications
> in the Gnutella layer are conducted, breaking the symetry of the peers.
> 
> 2) You're slightly confused about existing Gnutella using HTTP for handshaking
> and then switching to a binary protocol.
> 
> 2.1) First, it is true that Gnutella is using an HTTP-like header format
> for handshaking, but these headers are also RFC822-like (the original
> RFC for e-mail).  You wouldn't want us to switch to a e-mail for Gnutella
> communications just because headers look alike, right?
> 
> 2.2) Second, even using a pure HTTP-type of header exchanges between peers
> would not prevent a binary stream from being exchanged between peers later on.
> It's all a matter of which content type you're negotiating.
> 
> 3) My personal view on the way Gnutella handshaking is done is that the current
> design (which is a 3-way handshake by the way, something HTTP would not give
> you for free) fits the purposes, is reasonably extensible and is rather
> easy to implement (although of course not trivial).
> 
> 3.1) As a servent developer, what would be my incentive to undergo a
> major overhaul of the peer-to-peer communication stream, and how would
> I handle a smooth transition (continuity of service) between the current
> scheme and a new scheme?
> 
> 3.2) Your proposed design as it stands breaks the symetry between peers and
> is not acceptable.  Gnutella peers need to be able to exchange data at will,
> regardless of who initiated the TCP connection: once the 3-way handshake has
> been successful, both peers have the ability to exchange and do not have to
> track who connected to whom in the first place.
> 
> 4) I believe "simplifying" the Gnutella protocol by using HTTP instead of
> the current protocol would not attract more developers into Gnutella.
> 
> 4.1) As a developer, it's good to know that some libraries exist to do the
> low-level work for you, but that's not sufficient to motivate someone into
> putting hard hours into learning these libraries and using them.
> 
> 4.2) As I hinted above, the complexity of Gnutella is not really at
> the handshaking level but lies in the proper handling of the protocol:
> understanding what messages are for (not even talking about the format
> of the messages, that's a one-shot problem you handle for each message
> and then you simply forget about it), what their semantic is, how you react
> to the reception of a given message and when you need to send one and with
> which information.
> 
> 4.3) Writing a Gnutella servent is a complex task which requires skills,
> time and dedication.  It's not just the assembly of high-level components
> or protocols (HTTP, zlib, DHT, GUI toolkit, XML, SHA-1, Tiger, hash trees,
> DIME, UDP, TCP, web or UDP host caches).
> 
> 4.4) Gnutella documentation is widespread and some of the information
> is not even written explictly but embedded in the code of popular
> open-source servents.  Without proper documentation, how do you expect
> newcomers to be able to navigate in the maze of the existing documents and
> make the right decisions when it comes to implementing?
> 
> 4.5) The "barrier of entry" for a Gnutella servent today is extremely
> high.  Before you reach the level of features of servents like LimeWire
> or gkt-gnutella, you're going to have to spend man.years of efforts.
> Using standard libraries and protocols is not going to help significantly
> reduce that amount here.  As a new servent author, how would you attract
> users when people can choose LimeWire or gtk-gnutella and use them with
> a very high level of satisfaction?  What will be your differentiator?
> 
> :Did I miss something which can't be done with basic HTTP? 
> 
> I've not even considered that question, sorry.  Like I tried to explain
> above, switching to basic HTTP for peer-to-peer exchanges is not going
> to make things simpler and is not going to be a move that will likely
> attract new developers to Gnutella.
> 
> What would be more interesting a question to answer to is: what do
> we do to attract more open-source developers to work on the existing
> open-source servents?
> 
> Cheers,
> Raphael
> 
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
>