/[gzz]/gzz/Documentation/misc/hemppah-progradu/masterthesis.tex
ViewVC logotype

Diff of /gzz/Documentation/misc/hemppah-progradu/masterthesis.tex

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.87 by hemppah, Thu Feb 27 08:26:09 2003 UTC revision 1.88 by hemppah, Thu Feb 27 09:21:00 2003 UTC
# Line 218  key differences. Line 218  key differences.
218    
219  \section{Centralized}  \section{Centralized}
220    
221  Napster \cite{napsterurl} \footnote{We decided to include Napster in this section only because it has  Napster\footnote{We decided to include Napster in this section only because it has
222  historical value (see previous section).}  was designed to to allow people to share music.  historical value (see previous section).} \cite{napsterurl}  was designed to to allow
223  It was a hybrid Peer-to-Peer file-sharing system, i.e., the search index was centralized  people to share music. It was a hybrid Peer-to-Peer file-sharing system, i.e., the search
224  and the distribution storage and serving of files was distributed. Peers in the Napster  index was centralized and the distribution storage and serving of files was distributed.
225  network performed requests to the central directory server to find other peers hosting  Peers in the Napster network performed requests to the central directory server to find
226  desirable content. Since service requests was totally based on centralized index,  other peers hosting desirable content. Since service requests was totally based on
227  Napster didn't scale well because of constantly updated central directory, and had a  centralized index, Napster didn't scale well because of constantly updated central
228  possibility to single point of failure.  directory, and had a possibility to single point of failure.
229    
230    
231  \section{Loosely structured}  \section{Loosely structured}
# Line 244  data lookup works as follows: peer broad Line 244  data lookup works as follows: peer broad
244  forwards the query to their neighbors. This leads in the situation where number of messages  forwards the query to their neighbors. This leads in the situation where number of messages
245  in the network can grow with $O(n^{2})$, where $n$ is the number of participating peers in the  in the network can grow with $O(n^{2})$, where $n$ is the number of participating peers in the
246  Gnutella network. To limit the amount of network traffic, Gnutella uses Time-To-Live-limited  Gnutella network. To limit the amount of network traffic, Gnutella uses Time-To-Live-limited
247  (TTL) flooding to distributed queries. Therefore, only peers that are TTL hops away from the  (TTL) flooding to distributed queries. Gnutella uses a breadt-First traversal with depth limit
248  query originator will forward the query or respond to the query.  $T$ (e.g., 7), where T is the system-wide maximum TTL of a message in hops. Therefore, only peers that
249    are TTL hops away from the query originator will forward the query or respond to the query.
250    In Gnutella network, search results are fast, because breadt-First traversal sends queries to
251    every possible neighbor. On the other hand, this method wastes resources and doesn't scale well.
252    
253    According to \cite{lv02searchreplication}, Gnutella's way to perform data lookups, \emph{flooding}, has
254    following limitations. First, choosing the approriate TTL in practice is not easy. If the
255    TTL is too high, query originator may unnecessarily strain the network. If the TTL is too
256    low, the query originator might not find the desired data even it's available somewhere
257    in the network. Second, there are many duplicate messages generated by flooding, especially
258    in high connectivity graphs. It is obvious that with these limitations, flooding creates
259    significant message processing overhead for each query. Furthermore, as a result,
260    flooding may increase the load on participating to the point, where it has to leave the network.
261    
   
262    
263  Recently, however, there has been done research on topology properties of the Internet \cite{adamic99small}  
264  and the Gnutella network \cite{adamic02localsearch}, \cite{adamic01powerlawsearch}. Studies show  Lately, there has been done lot of research to improve Gnutella's data lookup efficiency
265  that both networks has a power law distribution of links, i.e., a few peers have high connectivity  and scalability. Adamic et. all \cite{adamic99small}, \cite{adamic02localsearch},
266  and major of peers have low connectivity.  \cite{adamic01powerlawsearch} has been studied different random walk methods in power-law
267  peers prefential attach  networks\footnote{In power-law networks only a few peers have high number of neighbor
268  to popular peers  links and major of peers have low nuber of neighbor links.} and they have found that by
269    instructing peers forwarding queries to select high degree peers the data lookup's
270    performance increases signficantly. However, it's not clear whether this algorithm
271    is scalable or not.
272    .
273    
274    
275    
276    

Legend:
Removed from v.1.87  
changed lines
  Added in v.1.88

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26