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

> Message du 26/02/10 20:13
> De : "Arne Babenhauserheide" 
> A : [email protected]
> Copie à : 
> Objet : Re: [the_gdf] Re: Implementing a Gnutella-structured network only with basic HTTP possible?Date: Wed, 24 
Feb 2010 09:08:15 +0000 (UTC)Date: Fri, 26 Feb 2010 12:55:15 +0000 (UTC)
> 
> 
> Am Freitag, 26. Februar 2010 14:28:17 schrieb Michael Green:
> > > i think there is already a library, which protocol we could brand to
> > 
> > > gnutella 3:
> > Well, you lost my vote just there ;-)
> 
> That was my gut reaction, too. 
> 
> Especially the “we brand” part. 
> 
> 
> I thought about using plain http (POST) as transport layer, so the basic model 
> could stay the same, because I know how much effort went into finetuning and 
> testing the advanced features in Gnutella. 

My opinion is to keep HTTP as the top layer, even if, for reachability, it gets encapsulated. The creation of the 
TCP emulation layer over UDP, in order to support HTTP on top of this was a fundamental change. The other additon 
would require adding security on top of this, i.e. supporting HTTP over SSL/TLS over (TCP emulation + ICMP emulation 
+ IGMP emulation + DNS emulation + UDP emulation) over the Gnutella messaging adopted (which interally emulates and 
behaves the same as a MAC Ethernet layer) on either UDP or TCP.

To make Gnutella really universal, it should be able to encapsulate all protocols that can work on top of a MAC 
layer (ecept that the Gnutella client GUID just replaces the Ethernet MAC address and is built to be universally 
unique and reachable, something that IEEE MAC addresses do not provide except on a single segment.

Given that the Gnutella GUID is universally unique, it also competes with an IP address (more exactly a IPv6 address 
with which it is very similar). All the facilities ported to IPv6-based routing network could work equally over the 
GUID-based routing network. Everything below the GUID should be transparent to the application, just like we never 
care about MAC addresses when writing classic TCP/IP client-server applications, even though this unique MAC also 
maps to a unique IP-like address, so that we don't need an ARP layer.

What this means is that we should have the possibility to just build a network interface layer, and to make all 
applications compatible with this architecture, have a sort of NAT layer to map the GUID to a true IPv6 address 
which can be used in applications. We could then group together to sponsor the adoption of one or more IPv6 blocks 
to get sure that they will never collide with usual IPv6 address blocks used in usuall Internet applications or 
local services used on private LANs and OSes.

If we look at this, then we already have well documented specifications for routing IPv6 between routers, we can 
build our own DNS system, we can locate various services. We can then reuse as well the existing gateway-to-gateway 
protocols, and benefit of all their improvements. The only difference is that we will have created a virtual "cloud" 
where our IP-like MAC addresses (GUIDs) are fully decentralized and replicatable.

Applications over this giant cloud could be as well sharing computing ressources on demand. As the Gnutella layer 
would in fact be implemented as a system driver, it would be no different (from as OS-level perspective) as another 
VPN layer. And then we would run any kind of applications, including all existing ones like standard browsers or 
media players. And this new network would compete directly with standard web hosting services (of course it would be 
slower, but much more resistant and failsafe dur to its huge redundancy).

It's time to think about P2P networks as an infrastructure instead of a specific service for file sharing (and this 
is what Microsoft has done in its own P2P protocol, used to extend private LANs securely to make them accessible 
from any access point where there's some Internet transport available but unpredictable IP addresses for these 
access points).

The existing tag search service of Gnutella is widely deprecated. The best service now is the Kademlia-based 
"Mojito" DHT, routed via the Gnutella infrastructure, and the host discovery system (that allows the network to 
remain fully connected, independantly of what they can transport).

But there's no reason for the tag search service that it should just return Magnet info with a tracker that can only 
try to match a Gnutella-specific GUID locator, and not allow it to converge with other IP-based locators (IPv4 and 
IPv6). If Gnutella remains so anecdoctic and badly perceived, it's because it is still not perceived as a generic 
infrastructure.

But the whole search service is bad as it cannot correctly index the ressources. A true service should behave more 
or less like a classic desktop search engine with a similar API. It should work over a smarter indexing database, 
and it should be capable of performing full text searches within documents or medias.

To make this possible, I think that all that is missing is a way to map a Gnutella GUID onto the IPv6 address space, 
as if the whole Gnutella network itself was acting itself like an ISP. Gnutella has the vokation of becoming an 
alternative to gateway-to-gateway protocols used by Autonomous Systems (AS) on the Internet backbones, except thjat 
it would be independant of all ISPs.

But can it work without a liable security center managing its own addressing space, resolving conflicts and hunting 
abusers (especially the authors of spamwares, spywares, virus and those controling of spambots) ?

Note that one of the most famous spambot network, "Storm", (which already causes very large damages) have already 
setup their own P2P network which is virtually impossible now to break, because it is already acting as a fully 
redundant cloud which is also almost invisible on the infected machines where it takes extremely small resources. 
Its resistance is also linked to the fact that it has integrated all sorts of interoperability interfaces between 
many standard networking interfaces. So it has now its own DNS-like system, its own internal IGMP protocol (that can 
be used to broadcast contents efficiently on a very large scale, for example to perform DDoS attacks against 
specific networks).

If we develop such an infrastructure and want it open, and if it works, you can be sure that it will also used by 
spambot networks like "Storm". The problem is not how we can avoid it, but how we can limit its impact, so that the 
rest of the network will still remain usable and will offer great contents and services.

If we cannot, then let's live with giant centralized servers (like Google and Facebook and their enormous databases 
of personnal information about hundred of millions of people in the world), and hope that they will not abuse it by 
selectively presenting us only the content they want us to see or want us to buy (though their paying advertizers), 
and also hope that our governments will force them to remain well-behaved to protect our privacy and all they know 
about us, so that nobody else (including themselves) will have the right to get an eye to our full profile, and that 
they will effectively delete out personal information immediately from our own request.

What I have seen about Facebook is really negative: it is extremely difficult to have it purge its database, and it 
does not correctly protect our privacy, because it shares every thing we give on it by default, it is immediately 
replicated out of control, and then only we can restrict the visibility. Facebook does not allow us to first fill a 
profile completely privately and then only decide what and when we want other to know. Facebook "friends" are 
definitely not friends, once you have accepted to show yourself past a dozen of persons you personnally know.

For this reason, after an initial try during a couple of hours, and seeing that it was impossible to limit the 
dissemination of information (and the web interface is so confusive that you won't immediately see that some info is 
already shared), I've deleted my subscription after unfilling all the elements in my profile with dummy data, and 
making them also completely private. I'll never retry this experience on such service: Facebook is the worst service 
ever, much worse than Google that just tracks us to display a few non intrusive banners we can ignore.

All these risks are inherent of any open networks: there will always be someone that will use it in a closed way for 
his own benefit, hidden behind a curtain of smoke and confusive public policy, and people that will try to abuse the 
service with very bad intents. The problem will always be the same: who do you trust, and how do you build a 
trunstable network and control at anytime the interaction and dissemination of information, and how you can enforce 
the removal of a past agreement (without having to justify it: it should be a fundamental right at any time, like in 
real life when you want to ignore a person).

Philippe.