Gnutella ray update. Pdf

 
4 Additional Topics 
In this section we will discuss additional topics related to our new OurNet. First, the scalability of 
OurNet will be shown to be much greater than other decentralized P2P file-sharing programs because of 
optimizations using the inherent properties of OurNet. Next, possible directions in implementation will be 
proposed using the available open source code of Gnutella and IRC. Then issues relating to legality will be 
brought up. This will mainly focus on the avoidance of legal problems and shutdown, and protecting users 
from legal responsibilities. Also a business model exploiting unique features of our system will be 
proposed. This model will be based on intelligent advertisement targeting. Lastly, papers on security and 
multicast relating to P2P groups will be presented. The related work in P2P groups will be shown to be a 
plausible and useful addition to OurNet. 
4.1 Scalability and Performance
We know there are many reasons why Napster (central index server) has the potential to scale 
quickly, but because of the many complicated legal issues, its pace in the race has come closer to a slow-
down. For argument sake, we shall label Napster as the 1
st
Generation P2P system. Next comes along 
Gnutella and its problems with scalability. We will argue how ours scales better than Gnutella and why it 
has a high probability of success. 
Because of Napster’s near-death trend, Gnutella technology is becoming more predominantly 
researched as the next possible standard. But there still exists many issues which hold Gnutella back from 
becoming widely scalable. Our transition from Gnutella to our protocol, OurNet, is one that points out two 
clear advantages that make OurNet highly scalable. 
The Gnutella network can be challenging to manage and secure. As its size grows, limits of 
performance and fairness are affected. Our method requires even less effort in managing nodes (the 
network). Our protocol can use the idea of channels in order to categorize items. These channels represent 
sub-networks which hold the structure of a hierarchical tree. Each level of the tree represents a new sub-
network which manages its children nodes only. Not having to worry about parent nodes or grandparent 
nodes makes managing traffic and congestion a lot easier and simpler. A possible limit of users per 

---

6
channel end-node gives us ground to saying that this channel structure will maintain network stability and 
fairness, encouraging high scalability. 
We have already mentioned how a decentralized P2P system, like Gnutella, is slow because 
queries need to be broadcast to all hosts within view. Take note that OurNet could possibly resolve such 
delayed queries. Again, with our plug-in of channels into a P2P system, we see how queries could take 
much less time by using an efficient sub-network search method. This not only avoids the huge overhead 
of broadcasting queries to all hosts, but also retrieves results in just a fraction of the time. A quick example 
would be searching for a particular mp3, say Michael Jackson’s hit song “Thriller”. A sample sub-network 
search would most likely start within the ‘media’ channel and work its way down to ‘music’. From ‘music’ 
it finds ‘mp3s’ which includes ‘80’s’ as a child channel. Knowing Jackson’s music is pop, it searches 
within the ‘pop’ channel and finds it way toward ‘Jackson’. Quickly, the query finds ‘Thriller’ and notifies 
the sender that a hit has been made. With this example, we are assuming the user is sitting within the 
‘media’ channel. Say the user at the time happened to be sitting within the ‘pop’ channel, her search query 
would cost that much less time in finding that particular file. So, clearly, the use of channels can 
significantly increase the quality of searches, proving performance scalability. 
Now, we attempt to give an analysis of our algorithm, and we show why it is superior to the 
Gnutella algorithm. Unfortunately, there are a number of features to our algorithm that make it very 
difficult to analyze. First, we have that any particular servent can be in multiple channels. For the sake of 
analysis, we are going to assume that any OurNet servent is only in one channel at a time. The second 
difficulty is that the number of channels is going to be dependent upon the number of users in the network.
Just as in a chat room situation, if there are more users, there will be more content and there will be more 
channels. The assumption we make is that there are m channels and the number of servents in each channel 
is b. Thus, n = bm. The final difficulty in analysis comes from the fact that when the Gnutella network is 
broken up into smaller and smaller channels, the connectivity is going to decrease. We assume that there 
are k  connections in the n user case, and the number of connections in the group remains proportional to the 
size of the channel in which you reside. Thus, there are k/m connections in a particular channel. These 
assumptions, combined with those from the Gnutella analysis, give us a time for a song request in O(min((A 
+ k/mB + M) * t, (A + M) * log
k
b + b/B)). The amount of transmitted data goes down significantly, to 
being in O(min((k/m)
t
, b)) bits. We feel that these two improvements are enough to allow Gnutella to scale 
to hundreds of thousands or even millions of users.