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

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