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)

> De : "Max" 

> huh? even more tracking by using the mac? what about the cpu-ID? acer is
> using to start the internetexplorer over their homepage with the ID in the
> url and then forwarding to the set homepage? that is tracking like chrome...
> the the GUID needs to be deletable. In offload this is solved by a GUID and
> unique DHT position.

You have aboslutely not understood the concept. I have NEVER said to use the hardware MAC, but to use the randomized 
(possibly very shortlived) Gnet GUID as if it was a MAC, in order to build a link layer similar to Ethernet *in its 
functionalities*, the Gnet as a whole then behaving as if it was a single Ethernet segment, or as an equivalent Ipv6 
address (to allow more fine-grained routing across virtual segments, in fact more like multiple routing domains of 
distinct AS (autonomous systems). On top of this you could then reimplement or reuse much existing network software, 
even without rewriting it if this emulation layer can behve at the same level in the OS kernel as the one used by 
VPN drivers.

> > ported to IPv6-based routing network
> >
> 
> here each network cable has a unique ID, that is even more than evil...

Here also you have not understood. This is architectural, but the IPv6-like address is definetely completely 
different from the true IPv6 backbone for the Internet, as the host interfaces on this would be completely 
delocalized.

> kadc and for java mojito or the azureus java dht are well kown, the offload
> dht works as well with that direction but has some advantages. you can
> connect to the dht over the off url (magnet uri like), wich has the ip
> included. Magnets as bootstrappers are possible. Second there is a cache
> like the old bearshare has used.

Magnets are just a tool for instructing P2P application with a tracker to try locating a single resource; It is not 
a protocol, not an architecture, in fact it is just a name. A service must still be built on top to find physical 
routes, and optimize them so that the resources can be retreived fast without consuming too much bandwidth both on 
your own internet connection but also on the rest of the network (that will have to support a reasonnable overhead 
to service others).

> we can do a big action, if a p2p network is a storage network of random
> blocks, and the meaning in the url allows to extract datafiles from the big
> block cloud, that is the idea of hadoop apache and offload realizes this for
> XORed blocks, which make the sharing safe as well. the MEANING is in the off
> url and there we need just a portal or a big file distributer like any linux
> distro, to link the files with offload urls.

You still think about file distributions. My opinion is that this service is almost dead. It does not match the 
effective working model of a P2P network that will only be efficient for more interactive services, i.e. temporary 
contents interesting live communities for a small period of time.

> > Facebook is the worst service
> > ever, much worse than Google that just tracks us to display a few non
> > intrusive banners we can ignore.
> >
> 
> I am woundering why you do not say this about ipV6. please use retroshare
> for F2F and friend connections.
> libretroshare is found and developed here:
> http://Retroshare.sf.netand the wxwidgets
> gui of the messenger only is here;
> http://retromessenger.sf.net wx-me SVN.

Ipv6 is not that. In fact it has no more or less power than IPv4 in terms of privacy. It is built however to be 
routed much more efficiently, and to greatly limit the cost of maintenance of the existing very huge and costly P2P 
network that is used now to maintain the IPv4 routing rables, and maintain the Internet connected.

And effectively, the Ipv6 backbone is increasingly used to allow interchanging the fastest bandwidth between very 
large groups of Ipv4 targets, without having to parse them all in giant routing tables: it works by first taking a 
target Ipv4 address with a complex route that must be maintained and rediscovered across a long chain of routers at 
each hop (including within the same AS), then converting it very early into an Ipv6 address in a space that is much 
more dense and more efficiently structured and routable using much smaller routing tables. Many Ipv4 communications 
can then be transported in the same Ipv6 routing channel which will transit multiple routers more easily, wiithout 
forcing each of them to guess how to route them. Near the end of the pipe, the Ipv4 traffic gets unpacked and routed 
within a much smaller local IPv4 routing domain with very simple Ipv4 routing tables.

Here we are speaking of the Ipv6 backbone working with many parallel optical links traversing continents. or 
interconnecting the largest ISPs of the world in the Tier 1 or Tier 2. Tier 3 ISPs use upstream providers in IPv4 
only even if some of them already use some IPv6 blocks (but much fewer blocks, and larger blocks, than what they 
need in IPv4, so they don't pollute much the routing table of their Tier 2 provider).

In fine however, you can as easily track a user of a public IPv6 address as a user of a public IPv4 address. All the 
same tools are available on both addressing and routing spaces. But the net benefit is that Ipv6 helps maintianing 
the routing tables that need to be propagated across distinct AS to a low level (remamber: this is really a P2P 
network that has existed as soon as the Internet addressing space was no longer manually managed by editing 
configuration files, or by discussing vocally with other network admins: there was too many people to contact, it 
was impossible to find an agreement in a reasonnable time). Instead thy have decided to use a P2P protocol for 
advertizing known routes between AS. There still exists today several competing P2P protocols, but one is now 
standard for IPv4 and was slightly adapted to work also with IPv6 (whose space is much less fragmented).

Note that the Internet IPv4 addrssing space would be far from being full if it was completely used. To void the 
explosion of the space, it was allowed to allocate blocks a bit larger than what was immediately needed. But now the 
blocks are smaller, and the pressure to free unused area contradicts some physical constraints, notably the size of 
routing tables supported in routers, as well as as the needed traffic generated by advertized routes and the risks 
of failure caused by lost routes or unupdated routes, or broken routes that can allow intruders to find their path 
on the network (to send spam or propagate virus, really anonymously!), due to hardware limitations in routers 
(notably their internal memory for routing table lookup, as well as CPU ressources needed to update these tables 
atomically and maintain the performance of the lookup algorithm).