\chapter{Related Work}
\pagestyle{myheadings}
\markright{}
\label{relatedWork}

In this thesis we are trying to put forward an architecture which will result enhancing the performance of peer to peer systems. We attempt to achieve this using techniques that exploit the relative positions of the peers in the real underlying network. In this chapter we will attempt to cover all efforts made which are geared toward similar goals of improving the performance of a P2P system.

\section{Interest-based Locality}
In \cite{contentlocation} Sripanidkulchai et al try and improve the performance of a Gnutella-like system by using interest-based locality. They do so by providing shortcuts to where the required content may be to improve the performance. If the shortcuts fail, the underlying system will always find the required content if it exists, since the shortcuts are supposed to be used only as hints. The main philosophy of creating these shortcuts is that a peer which is querying for some specific content is more likely to find that content on a peer that shares the same interests as itself. Shortcut discovery is done by piggybacking initial flooding queries with requests to create shortcuts. These shortcuts are then continuously ranked based on their perceived usefulness. This ranking is used to decide both the order in which the shortcuts are queried and also which shortcuts to evict if space is needed to create more shortcuts. The authors also mention that this same technique can be used to improve the performance of Structured Distributed Hash Table based P2P systems, such as Chord, but with the assumption that a node in the system will store only the content that it itself is interested in.

There have been various efforts to make efficient peer to peer systems which utilize the proximity between nodes in the underlying network. Castro et al \cite{exploitNetworkp2p} mention 3 different ways in which the proximity of nodes can be exploited for improving the performance of a P2P system.\\

\section{Proximity Neighbor Selection}
In a peer to peer system each node has to have some information about some other nodes in the system, in order to be able to route correctly and in the direction of the node eventually responsible for the request. For this purpose, nodes maintain routing tables. The number of entries and the manner in which these tables are arranged vary from system to system. Some of the systems mentioned earlier, like Pastry (\cite{pastry}), Tapestry(\cite{tapestry}) and CAN (\cite{CAN}) have some flexibility in the manner the entries in their routing tables are populated. Therefore, whenever there is a choice of two or more nodes for the same entry in the routing tables, the node that is physically closest to the current node is chosen. This means that in addition to the requests moving closer to the final destination in every hop, this technique also minimizes the distance that the request has to cover in each hop. The goal of such a technique is that finally, the total distance traveled by a request packet (the sum of the distance covered in each hop) should be within a constant factor of the distance between the source and destination of that request.

\section{Proximity Routing}
In this technique, the routing tables are constructed without considering any proximity information at all. While routing a request, the next hop is chosen from the existing entries in the routing table based on its proximity to the current node and also the progress it affords toward the final destination in the virtual node identifier space. This basically involves a compromise. In making large advances in the virtual space, a request may be forced to travel large distances for each hop. Using proximity routing techniques may result in covering lesser distances in the the virtual space and traveling smaller distances in the underlying Internet, but at the same time, risking additional hops to reach the final destination. A version of this protocol is used in CAN. This has also been suggested as one of the techniques that can be used to make Chord more efficient, and is used in CFS \cite{cfs}, a peer to peer wide area file system which uses the Chord protocol in its routing substrate.

\section{Geographical Layout}
This technique attempts to map the node identifier space onto a physical space while constructing a peer to peer network. The system is no longer \textit{virtual}, since the positions of the nodes within it mirror their locations in the real internetwork that they are a part of. This technique has been explored as one of several to improve the routing performance of CAN. It managed to effect an improvement in performance, but at the cost of losing its ability to be self-organizing. A set of well-known landmark servers is required to decide the coordinates of a node in the CAN space. 

The main issue that has come about in discussions of using geographical layout to organize the connections in a peer to peer network, is that it will cause an imbalance in the way the node identifiers are distributed in the identifier space. This will in turn lead to an imbalance in how the resources are distributed, which may lead to hot spots. Furthermore, protocols such as Chord and Pastry depend on the nodes that are close together in the virtual identifier space to be separated in the real world. This is because causing a set of nearby nodes to fail may lead to incorrect routing of requests and render some nodes in the system to be unreachable from some other nodes. 

In this thesis we propose a technique that uses this geographical layout information about the nodes in the system to improve the performance of the system. We do so by using geographical information in addition to the basic protocol which in our case is Chord. Chord is used unchanged as a \textit{safety net}, in case our technique fails to locate the required resource the underlying Chord system will always be able to find it. Not unlike the technique that uses shortcuts to find the nearest replica, we also attempt to locate the nearest replica and at the same time ensure that the distance traveled in finding this replica is proportional to the distance between the source and the destination (the node that holds the replica used to service the request).
