Since Fasttrack might be shut down soon, or at least the kazaa client is not available for download anymore. according to this: http://news.cnet.com/news/0-1005-200-8513895.html (although the linux client is still online). I was having some thoughts about if Gnutella could be shut down.

Now why am I posting this here and not in General Gnutella Discussions? My thoughts lead me to the only vulnerability, gnutella has and that is probably it's hostcaches. - It might be true, that there would be a gnutella-net after shutting down the hostcaches, but what could prevent it from breaking up into many small not interconnected networks.

What LimeWire would need in that case, would be a feature that new users to connect to the network with (ideally) only one IP of another client that is currently running and at the same time, after the smallest possible amount of time, LimeWire would have to collect as many hosts as possible, to be able to reconnect to the network after being shut down for a few days or so.

Currently the gnutella.net files contain up to 500 hosts, but reconnecting with those 500 hosts will not work for sure. (It does not work for me, at least).

On way to improve that kind of behaviour could be, to collect more hosts, but more hosts mean a lot more hosts, - e.g. 2500 or so. Another way would be, to choose say a couple of hundred of hosts, which have the longest uptime. To accomplish this, you would need an algorithm, that dynamically finds the fastest and most accessible hosts on the net.

Here is my idea, about that algorithm.

Every 30 Minutes or so an ultrapeer sends a message with IP-Adresses of a number of other ultrapeers via all incoming connections. The list of IP-Adresses, to be sent by an ultrapeer should include:
a) all ultrapeers it has outgoing connections to
b) those ultrapeers whose adresses it has received most often during let's say the last 5 hours.

In case a servant wants to connect to a new host it tries the top ranked ultrapeers from b). If the connection fails that specific host is removed from that ranking.

I have absolutely no clue whether or not this will work but to ensure the robustness of Gnutella we should do something...

gnutella is decentralized. the hostcache would only give ip addresses of other gnutella hosts, so what big deal. They have no clue what that person is sharing so no evidence. They can try to directly connect to the client but that wont likely wont b/c of the Leaf implementation. Then even if they do connect they have to find copyrighted material from that particular host. They cant browse host b/c it doenst work anymore. So there is no need to worry. Gnutella will be the biggest and best P2P yet to come. Great things are coming to the gnutella network, but remember patience is virtue.

I agree measurements should be made to prevent any attempts to shutdown or harm the network. Prevention is the best remedy.
Another idea would be for LW and the rest of the gnutella developers to develop an encryption standard. New clients would provide the user with the other host permitting the option to establish an encrypted file transfer/connection. Or the client could have an autodetect feature that will automatically encrypt the file transfer if the other host has the appropiate client. This would be ideal for musicians transfering project file s of their music who wish not to share it with everyone or other sensitive documents.
I hope Limewire will please consider this proposal.

@anti-bearshare. I think what he meant was the possibility to reconnect to the network comfortably without making use of host-caches.

@Unregistered(2). You could send a public-key with any of your Querys, so the QueryHits could be encrypted for you to decrypt again. - The problem could be I) each Query would grow by 64 to 128Bytes (512-1024Bit or would you consider a weaker encryption?). II) I don't know how that would affect for example ultrapeers sharing lot's of files and having a good connection to the net, because they would have to encrypt many QueryHits. I'm not too familiar with the performance of encryption mechanism but I can imagine it will spoil some peoples fun if gnutella clients use 90% of their system resources.

John: he just described hostcaching......


Encryption would only be useful for documents just as something you dont want other people to see except the people that should. But other than that it really doesnt have a purpose, in other words it not the highest priority.

Yes, more or less this seems to be host caching, apart from servents actively sending hostlists through the network which they do not do now.

Encrypting the documents wouldn't be that useful. You could implement authentication instead, although I would not like that for gnutella. Encrypting QueryHits can be used, so anybody passively searching gnutella (i.e. the RIAA) could not tell which files anybody is sharing without actively searching, which is not quite as effective.

Maybe there also would be some legal problems: At least in Germany it's illegal for a detective to ask anybody to do something illegal. And that is what requesting a copyrighted file through gnutella is, no?

Anyways...


The n case a servant wants to connect to a new host it tries the top ranked ultrapeers from b). If the connection fails that specific host is removed from that ranking.[ part of that is m aking gnutella centralized. B/c some host stay on 24/7 for a LONG periods of time. Then all connections would relay on those hosts. What if one drops? The topology changes and everything has to build make up again. Also if that was effective, you could find out who the centralized hosts are. Encrypting documents would be useful. Documents as in some private message to your friend or pretty much anything private. Anything other than documnets such as audio and video in the sense of public entertainment isnt really an issue. B/c those are suppose to be viewed by everyone. Anyways in America, we're not as stupid as to make it illegal for someone to tell someone else to do something illegal. Its only a crime when someone has commited the illegal action. For example, if I told you to kill someone (just as some generalized comment-not paying you to do it), it would only be a crime if you actually had gone out and killed someone. The crime would be against you not me. B/c you're the one that took action.

I would not consider that a problem, since a ranking could contain more than one host. But I believe that the algorithm for host caches should be improved. LimeWire currently saves 400 Ultrapeers, 100 normal peers and about 20 local IP-adresses in a hosts file, which is not really highly optimized.

Concerning encrypting documents: I really think authentification would be better. If some files would require some kind of authentification handshake to make the connection, you could control who downloads the file. Instead of encrypting private messages, you should use PGP and eMail ;-). But I don't want authentification implemented in clients (people could start using it).

Btw. Talking about messages, I thought of a way to use Gnutella as underlying protocol for a decentralized forum. Would you think that could be useful?

Asking somebody to commit a crime is a crime, too, in Germany. When I ask somebody to kill a person, and he actually does that, I could be found guilty, too. I thought that was common, - it is common at least in Europe. I also believe, that's the right way to handle that. But anyways I was actually talking about the police agents, who are not allowed to ask (undercover) a supposed criminal to commit a crime.

Putting higher priority on a host or any group of hosts is still centralization, doesnt matter how you word it. The hostcaching thing, works fine for me. I dont really understand the purpose you're trying to explain.


Authentification works with encryption, hence public and private keys (since you've mentioned PGP, I'll assume you know what those are).

heh, I dont really understand what you're saying here, well b/c PGP (Pretty Good Privacy) does ENCRYPT files/messages/etc!!!! So that statement didnt make any sense.


decentralized forum thing would be a cool project.

Yes, this means centralization in some ways, but I don't consider that all bad, when the network remains dynamic. What I was trying to explain was based on Unregistered's assumption that the main gnutella host cachers would fail. An improved hostcaching algorithm could ease things up in that case. Today the hostcaching thing works fine indeed, as long your client keeps running, but it won't work if you disconnect for a day or two and try to reconnect only with the IPs in your hostcache (this isn't a problem, as long there are the main host cachers you can connect to).

I'm sorry, I thought you actually meant to encrypt the file before sending it.
Which would be more trouble than it's worth (like encrypting divx-movies or other large files...). Btw Authentification can also work with sending a simple password - which is more like what I was thinking of, although that would not be very secure.

I meant instead of using Gnutella&Encryption to let others download private messages you should use eMail with PGP.

As for the GnutellaForum. I came up with some ideas I wrote down today. This is nothing serious yet, but it might become something. - I had the idea of using the LimeWire-Sources to develop a very basic client for this forum, if it worked out (since I wanted to practice some programming anyway).

ftp://whitedragon.dyndns.org/Gnutell..._prealpha.html