1363 |
|
|
1364 |
|
|
1365 |
\parbox{90pt}{Sybil attack \cite{douceur02sybil}, \cite{castro02securerouting}} & |
\parbox{90pt}{Sybil attack \cite{douceur02sybil}, \cite{castro02securerouting}} & |
1366 |
\parbox{110pt}{Single hostile entity present multiple entities} & |
\parbox{110pt}{Single hostile entity presents multiple entities} & |
1367 |
\parbox{110pt}{Identify all nodes simultaneously across the system, collect pool of nodes which are validated, distributed node ID creation} & |
\parbox{110pt}{Identify all nodes simultaneously across the system, collect pool of nodes which are validated, distributed node ID creation} & |
1368 |
\parbox{110pt}{Not practically realizable, research focused on persistence, not on identity distinction} |
\parbox{110pt}{Not practically realizable, research focused on persistence, not on identity distinction} |
1369 |
\\ \hline |
\\ \hline |
1397 |
\\ \hline |
\\ \hline |
1398 |
|
|
1399 |
|
|
1400 |
\parbox{90pt}{Anonymity \cite{reiter98crowds}, \cite{tarzan:ccs9}, \cite{pub00}, \cite{clarke00freenet}, \cite{reiter98crowds}, \cite{352607},\cite{502002}} & |
\parbox{90pt}{Anonymity \cite{tarzan:ccs9}, \cite{pub00}, \cite{clarke00freenet}, \cite{reiter98crowds}, \cite{352607},\cite{502002}} & |
1401 |
\parbox{110pt}{Anonymity cannot be provided in all cases} & |
\parbox{110pt}{Anonymity cannot be provided in all cases} & |
1402 |
\parbox{110pt}{Remailers, pre-routing} & |
\parbox{110pt}{Remailers, pre-routing} & |
1403 |
\parbox{110pt}{Total anonymity cannot be provided yet} |
\parbox{110pt}{Total anonymity cannot be provided yet} |
1427 |
|
|
1428 |
\parbox{90pt}{Hostile groups \cite{castro02securerouting}} & |
\parbox{90pt}{Hostile groups \cite{castro02securerouting}} & |
1429 |
\parbox{110pt}{Joining node may join parallel network, formed a group of hostile nodes, hostile node(s) controls the construction of the network} & |
\parbox{110pt}{Joining node may join parallel network, formed a group of hostile nodes, hostile node(s) controls the construction of the network} & |
1430 |
\parbox{110pt}{Use trusted nodes, based on history information, Cryptography, key infrastructure} & |
\parbox{110pt}{Use trusted nodes, based on history information, cryptography, key infrastructure} & |
1431 |
\parbox{110pt}{Not 100\% sure if Central Authority (CA) is missing, not practical approach/working proposal created yet} |
\parbox{110pt}{Not 100\% sure if Central Authority (CA) is missing, not practical approach/working proposal created yet} |
1432 |
\\ \hline |
\\ \hline |
1433 |
|
|
1434 |
|
|
1435 |
\parbox{90pt}{External security threats} & |
\parbox{90pt}{External security threats} & |
1436 |
\parbox{110pt}{Viruses, Trojan, sniffers} & |
\parbox{110pt}{Viruses, trojans, sniffers} & |
1437 |
\parbox{110pt}{Data integrity/authenticity, distributed anti virus software} & |
\parbox{110pt}{Data integrity/authenticity, distributed anti virus software} & |
1438 |
\parbox{110pt}{Not much research has been done on this} |
\parbox{110pt}{Not much research has been done on this} |
1439 |
\\ \hline |
\\ \hline |
1476 |
\\ \hline |
\\ \hline |
1477 |
|
|
1478 |
|
|
1479 |
\parbox{90pt}{Efficient and scalable data discovery \cite{lv02searchreplication}, \cite{osokine02distnetworks}, \cite{yang02improvingsearch}, \cite{lv02gnutellascalable}, \cite{ganesan02yappers}, \cite{adamic02localsearch}, \cite{adamic01powerlawsearch}, \cite{ripeanu02mappinggnutella}, \cite{milgram67smallworld}, \cite{adamic99small}, \cite{sterling95beowulf}, \cite{ramanathan02goodpeers}, \cite{kleinberg99small}, \cite{nips02-Kleinberg}, \cite{zhang02using}, \cite{watts00dynamics}} & |
\parbox{90pt}{Efficient and scalable data discovery \cite{lv02searchreplication}, \cite{osokine02distnetworks}, \cite{yang02improvingsearch}, \cite{lv02gnutellascalable}, \cite{ganesan02yappers}, \cite{adamic02localsearch}, \cite{adamic01powerlawsearch}, \cite{ripeanu02mappinggnutella}, \cite{milgram67smallworld}, \cite{adamic99small}, \cite{ramanathan02goodpeers}, \cite{kleinberg99small}, \cite{nips02-Kleinberg}, \cite{zhang02using}, \cite{watts00dynamics}} & |
1480 |
\parbox{110pt}{Find resources efficiently, if resource exists (loosely structured)} & |
\parbox{110pt}{Find resources efficiently, if resource exists (loosely structured)} & |
1481 |
\parbox{110pt}{Super nodes, node clusters, caching techniques} & |
\parbox{110pt}{Super nodes, node clusters, caching techniques} & |
1482 |
\parbox{110pt}{More efficient, less network traffic, not comparable to DHT's efficiency} |
\parbox{110pt}{More efficient, less network traffic, not comparable to DHT's efficiency} |
1498 |
|
|
1499 |
|
|
1500 |
\parbox{90pt}{Quality of Service} & |
\parbox{90pt}{Quality of Service} & |
1501 |
\parbox{110pt}{The system can only provide (at most) best effort services)} & |
\parbox{110pt}{The system can only provide (at most) best effort services} & |
1502 |
\parbox{110pt}{Use network proximity for better network performance (bandwidth, latency, jitter, packet loss)} & |
\parbox{110pt}{Use network proximity for better network performance (bandwidth, latency, jitter, packet loss)} & |
1503 |
\parbox{110pt}{Increases system complexity, some initial experiences, need more research} |
\parbox{110pt}{Increases system complexity, some initial experiences, need more research} |
1504 |
\\ \hline |
\\ \hline |
1512 |
|
|
1513 |
|
|
1514 |
\parbox{90pt}{Network proximity \cite{pias03lighthouse}, \cite{ng02predicting}, \cite{ratnasamy02ght}, \cite{eriksson03peernet}, \cite{castro02networkproximity}} & |
\parbox{90pt}{Network proximity \cite{pias03lighthouse}, \cite{ng02predicting}, \cite{ratnasamy02ght}, \cite{eriksson03peernet}, \cite{castro02networkproximity}} & |
1515 |
\parbox{110pt}{Can we take account the underlying network's properties better when forming overlay network (network-awareness for performance) ?} & |
\parbox{110pt}{Can we take into account the underlying network's properties better when forming overlay network (network-awareness for performance) ?} & |
1516 |
\parbox{110pt}{Global Network Positioning, Lighthouse technique, triangulated heuristics} & |
\parbox{110pt}{Global network positioning, lighthouse technique, triangulated heuristics} & |
1517 |
\parbox{110pt}{Increases system complexity, no real world experience in a wide scale, proposed solutions are susceptible to single point of failure} |
\parbox{110pt}{Increases system complexity, no real world experience in a wide scale, proposed solutions are susceptible to single point of failure} |
1518 |
\\ \hline |
\\ \hline |
1519 |
|
|
1528 |
\parbox{90pt}{Hot spots \cite{258660}, \cite{sloppy:iptps03}, \cite{maymounkov03ratelesscodes}} & |
\parbox{90pt}{Hot spots \cite{258660}, \cite{sloppy:iptps03}, \cite{maymounkov03ratelesscodes}} & |
1529 |
\parbox{110pt}{What will happen if some resource is extremely popular and only one node is hosting it ?} & |
\parbox{110pt}{What will happen if some resource is extremely popular and only one node is hosting it ?} & |
1530 |
\parbox{110pt}{Caching, multi source downloads, replication, load balancing, sloppy hashing} & |
\parbox{110pt}{Caching, multi source downloads, replication, load balancing, sloppy hashing} & |
1531 |
\parbox{110pt}{For query hot spots, caching and multi source downloads efficiently reduces hot spots, for routing hot spots, benefits are smaller} |
\parbox{110pt}{For query hot spots, caching and multi source downloads efficiently reduce hot spots, for routing hot spots, benefits are smaller} |
1532 |
\\ \hline |
\\ \hline |
1533 |
|
|
1534 |
|
|
1535 |
\parbox{90pt}{Load balancing \cite{rao03loadbalancing}, \cite{ledlie02selfp2p}, \cite{byers03dhtbalancing}} & |
\parbox{90pt}{Load balancing \cite{rao03loadbalancing}, \cite{ledlie02selfp2p}, \cite{byers03dhtbalancing}} & |
1536 |
\parbox{110pt}{Random (but uniformly distributed) identifier selection could cause system imbalance among participants with different capabilities} & |
\parbox{110pt}{Random (but uniformly distributed) identifier selection could cause system inbalance among participants with different capabilities} & |
1537 |
\parbox{110pt}{Caching, virtual server transfers} & |
\parbox{110pt}{Caching, virtual server transfers} & |
1538 |
\parbox{110pt}{Effective, more research required in fully dynamic environment} |
\parbox{110pt}{Effective, more research required in fully dynamic environment} |
1539 |
\\ \hline |
\\ \hline |
1546 |
|
|
1547 |
\parbox{90pt}{Sudden network partition \cite{harvey03skipnet1}, \cite{harvey03skipnet2}, \cite{rowston03controlloingreliability}} & |
\parbox{90pt}{Sudden network partition \cite{harvey03skipnet1}, \cite{harvey03skipnet2}, \cite{rowston03controlloingreliability}} & |
1548 |
\parbox{110pt}{Sub network is isolated from other network because of network disconnection} & |
\parbox{110pt}{Sub network is isolated from other network because of network disconnection} & |
1549 |
\parbox{110pt}{Self-tuning, environment observatorion, localized network connection for minimum latency (backup connections)} & |
\parbox{110pt}{Self-tuning, environment observation, localized network connection for minimum latency (backup connections)} & |
1550 |
\parbox{110pt}{Creates more overhead/space requirements per node} |
\parbox{110pt}{Creates more overhead/space requirements per node} |
1551 |
\\ \hline |
\\ \hline |
1552 |
|
|
1553 |
\parbox{90pt}{Fail Stop} & |
\parbox{90pt}{Fail Stop} & |
1554 |
\parbox{110pt}{A faulty node stops working} & |
\parbox{110pt}{A faulty node stops working} & |
1555 |
\parbox{110pt}{Failure detectors, informing algorithms} & |
\parbox{110pt}{Failure detectors, informing algorithms} & |
1556 |
\parbox{110pt}{Creates more network traffics, node's information can be outdated, failure detectors not reliable} |
\parbox{110pt}{Creates more network traffic, peer's information can be outdated, failure detectors not reliable} |
1557 |
\\ \hline |
\\ \hline |
1558 |
|
|
1559 |
|
|
1560 |
\parbox{90pt}{Byzantine faults \cite{296824}} & |
\parbox{90pt}{Byzantine faults \cite{296824}} & |
1561 |
\parbox{110pt}{Faulty nodes may behave arbitrarily} & |
\parbox{110pt}{Faulty nodes may behave arbitrarily} & |
1562 |
\parbox{110pt}{Byzantine replication algorithms -> get information from multiple entities, trust majority's opinion} & |
\parbox{110pt}{Byzantine replication algorithms, get information from multiple entities, trust majority's opinion} & |
1563 |
\parbox{110pt}{Much research has been done on this field, practical solutions, decreases the performance of system slightly} |
\parbox{110pt}{Much research has been done on this field, practical solutions, decreases system performance slightly} |
1564 |
\\ \hline |
\\ \hline |
1565 |
|
|
1566 |
\caption{Performance and usability problems in Peer-to-Peer.} |
\caption{Performance and usability problems in Peer-to-Peer.} |
1595 |
\endfoot |
\endfoot |
1596 |
|
|
1597 |
|
|
1598 |
\parbox{90pt}{Mutual distrust, \cite{cornelli02reputableservents}, \cite{aberer01trust}} & |
\parbox{90pt}{Mutual distrust \cite{cornelli02reputableservents}, \cite{aberer01trust}} & |
1599 |
\parbox{110pt}{Nobody trusts anybody} & |
\parbox{110pt}{Nobody trusts anybody} & |
1600 |
\parbox{110pt}{Reputation methods, key infrastructures} & |
\parbox{110pt}{Reputation methods, key infrastructures} & |
1601 |
\parbox{110pt}{Resource demanding, not practical to implement/not working solutions, no real world experience in a wide scale} |
\parbox{110pt}{Resource demanding, not practical to implement/not working solutions, no real world experience in a wide scale} |
1624 |
|
|
1625 |
|
|
1626 |
\parbox{90pt}{Comprehensive simulations/analysis of Peer-to-Peer network} & |
\parbox{90pt}{Comprehensive simulations/analysis of Peer-to-Peer network} & |
1627 |
\parbox{110pt}{Ability to simulate whole Peer-to-Peer network's usage patterns, network traffics, flux state etc} & |
\parbox{110pt}{Ability to simulate whole Peer-to-Peer network's usage patterns, network traffics, flux state etc.} & |
1628 |
\parbox{110pt}{Use same techniques as simulating/analyzing the Internet} & |
\parbox{110pt}{Use same techniques as simulating/analyzing the Internet} & |
1629 |
\parbox{110pt}{Only small subsets of Peer-to-Peer networks has been analysed, because of ad hoc properties of network, more powerful solutions needed} |
\parbox{110pt}{Only small subsets of Peer-to-Peer networks has been analysed, because of ad hoc properties of network, more powerful solutions needed} |
1630 |
\\ \hline |
\\ \hline |
1633 |
\parbox{90pt}{Overlay management and health monitoring \cite{zhang03somo}} & |
\parbox{90pt}{Overlay management and health monitoring \cite{zhang03somo}} & |
1634 |
\parbox{110pt}{System is self-capable to monitor it's status and health for better performance} & |
\parbox{110pt}{System is self-capable to monitor it's status and health for better performance} & |
1635 |
\parbox{110pt}{Build a meta data overlay atop of structured overlay (such as SOMO for structured overlays), make local decisions about overlay (unstructured)} & |
\parbox{110pt}{Build a meta data overlay atop of structured overlay (such as SOMO for structured overlays), make local decisions about overlay (unstructured)} & |
1636 |
\parbox{110pt}{For structured overlays, efficient and simple to implement, fault-tolerance unknowns, for unstructured, not necessarily efficient because decisions are based on local knowledge} |
\parbox{110pt}{For tightly structured overlays, efficient and simple to implement, fault tolerance unknown, for loosely structured not necessarily efficient because decisions are based on local knowledge} |
1637 |
\\ \hline |
\\ \hline |
1638 |
|
|
1639 |
\parbox{90pt}{Locating Peer-to-Peer network} & |
\parbox{90pt}{Locating Peer-to-Peer network} & |
1640 |
\parbox{110pt}{How old peers or new peers are able to locate Peer-to-Peer network, if it exists} & |
\parbox{110pt}{How old peers or new peers are able to locate Peer-to-Peer network, if it exists} & |
1641 |
\parbox{110pt}{Servers maintaining online peers (e.g. gnutellahosts.com), peer's history information} & |
\parbox{110pt}{Servers maintaining online peers (e.g. gnutellahosts.com), peer's history information} & |
1642 |
\parbox{110pt}{Depends on implementation and purpose of the system, for mobile ad hoc networks more research is needed} |
\parbox{110pt}{Depends on implementation and purpose of the system, for desktop based system there are working solutions, for mobile ad hoc networks more research is needed (Mobile ad hoc |
1643 |
|
networks (MANETs) can be only connected through radio resource interface, i.e., peers which are in same geographical area)} |
1644 |
\\ \hline |
\\ \hline |
1645 |
|
|
1646 |
\caption{Miscellaneous problems in Peer-to-Peer.} |
\caption{Miscellaneous problems in Peer-to-Peer.} |
1689 |
\emph{characters}. Each character in xanalogical storage model has a |
\emph{characters}. Each character in xanalogical storage model has a |
1690 |
permanent, globally unique identifier. For instance, let's consider the following |
permanent, globally unique identifier. For instance, let's consider the following |
1691 |
scenario: ''the character 'D' typed by Janne Kujala on 10/8/97 8:37:18''. In this |
scenario: ''the character 'D' typed by Janne Kujala on 10/8/97 8:37:18''. In this |
1692 |
example, when character 'D' is is first typed in, xanalogical storage model |
example, when character 'D' is first typed in, xanalogical storage model |
1693 |
acquires a permanent identifier for that character and retains it when character |
acquires a permanent identifier for that character and retains it when character |
1694 |
is copied to different document. Thus, the identifier distinguishes character from |
is copied to different document. Thus, the identifier distinguishes character from |
1695 |
all similar characters typed in independently\footnote{Xanalogical storage model |
all similar characters typed in independently\footnote{Xanalogical storage model |
1729 |
|
|
1730 |
Storm (for \emph{STORage Module}) is a software module, which is used in Fenfire for |
Storm (for \emph{STORage Module}) is a software module, which is used in Fenfire for |
1731 |
data storage operations. Storm stores all data as \emph{blocks}, which |
data storage operations. Storm stores all data as \emph{blocks}, which |
1732 |
are immutable byte sequences. SHA-1\footnote{SHA-1 is considered a collision free |
are immutable byte sequences. SHA-1\footnote{SHA-1 is considered as a collision free |
1733 |
hash function. Therefore, it is very unlikely that two different Storm data blocks |
hash function. Therefore, it is very unlikely that two different Storm data blocks |
1734 |
would have same identifier.} cryptographic content hash \cite{fips-sha-1} is used |
would have same identifier.} cryptographic content hash \cite{fips-sha-1} is used |
1735 |
for creating location-independent, globally unique identifiers for blocks. Additionally, |
for creating location-independent, globally unique identifiers for blocks. Additionally, |
1736 |
SHA-1 \cite{fips-sha-1} is used for verifying the integrity of Storm data blocks. Storm |
SHA-1 \cite{fips-sha-1} is used for verifying the integrity of Storm data blocks. Storm |
1737 |
blocks have much in common with regular files, except Storm blocks are \emph{immutable} as |
blocks have much in common with regular files, except that Storm blocks are \emph{immutable} as |
1738 |
any change to the byte sequence would the change block's hash value, i.e., unique |
any change to the byte sequence would change block's hash value, i.e., unique |
1739 |
identifier. This mechanism creates a basis for implementing xanalogical model in |
identifier. This mechanism creates a basis for implementing xanalogical model in |
1740 |
Fenfire system. Figure \ref{fig:storm_model} illustrates simplified Storm storage model. |
Fenfire system. Figure \ref{fig:storm_model} illustrates simplified Storm storage model. |
1741 |
|
|
1806 |
Obviously, our objectives are yet simple but hard to fulfill. First, as a prerequisite |
Obviously, our objectives are yet simple but hard to fulfill. First, as a prerequisite |
1807 |
to implementing xanalogical storage model in Peer-to-Peer environment, system |
to implementing xanalogical storage model in Peer-to-Peer environment, system |
1808 |
supporting data lookups must be able to perform \emph{global} scale lookups. Thus, |
supporting data lookups must be able to perform \emph{global} scale lookups. Thus, |
1809 |
we must able to locate and fetch Storm scroll/pointer block, if it exists in the |
we must be able to locate and fetch Storm scroll/pointer block, if it exists in the |
1810 |
Peer-to-Peer overlay. Second, data lookups have to be efficient, since constructing |
Peer-to-Peer overlay. Second, data lookups have to be efficient, since constructing |
1811 |
one ''virtual file'' may need obtaining several data items, which are distributed |
one ''virtual file'' may need obtaining several data items, which are distributed |
1812 |
randomly throughout the overlay; if not efficient, construction of ''virtual file'' |
randomly throughout the overlay; if not efficient, construction of ''virtual file'' |
1813 |
may take reasonable amount time while rendering system very unusable. Third, Peer-to-Peer |
may take reasonable amount of time while rendering system very unusable. Third, Peer-to-Peer |
1814 |
infrastructure has to be scalable and robust against hostile attacks. |
infrastructure has to be scalable and robust against hostile attacks. |
1815 |
|
|
1816 |
Some research regarding to these problem has been made by Lukka et al. |
Some research regarding to these problem has been made by Lukka et al. |
1817 |
\cite{lukka02freenetguids}. Authors' work is mainly based on insight of implementing |
\cite{lukka02freenetguids}. Authors' work is mainly based on insight of implementing |
1818 |
xanalogical model in Peer-to-Peer environment with globally unique identifiers. Lukka et al. |
xanalogical model in Peer-to-Peer environment with globally unique identifiers. Lukka et al. |
1819 |
use Freenet \cite{clarke00freenet} as a example Peer-to-Peer system supporting |
use Freenet \cite{clarke00freenet} as an example Peer-to-Peer system supporting |
1820 |
globally unique identifiers. The work presented in this thesis extends their work by |
globally unique identifiers. The work presented in this thesis extends their work by |
1821 |
evaluating different Peer-to-Peer systems more extensively to Fenfire's needs. |
evaluating different Peer-to-Peer systems more extensively to Fenfire's needs. |
1822 |
|
|
1823 |
Additionally, related to non-xanalogical hypermedia systems, Bouving |
Additionally, related to non-xanalogical hypermedia systems, Bouving |
1824 |
\cite{bouvin02openhypermedia} has done initial work regarding ways in which |
\cite{bouvin02openhypermedia} has done initial work regarding ways in which |
1825 |
Peer-to-Peer can used in non-xanalogical hypermedia systems. Thompson and de Roure |
Peer-to-Peer can be used in non-xanalogical hypermedia systems. Thompson and de Roure |
1826 |
\cite{thompson01hypermedia} have studied locating documents and links in Peer-to-Peer |
\cite{thompson01hypermedia} have studied locating documents and links in Peer-to-Peer |
1827 |
environment. At the Hypertext '02 panel, moderated by Wiil \cite{wiil02p2phypertext}, |
environment. At the Hypertext '02 panel, moderated by Wiil \cite{wiil02p2phypertext}, |
1828 |
participants responded whether Peer-to-Peer systems are suitable for hypermedia |
participants responded whether Peer-to-Peer systems are suitable for hypermedia |
1833 |
In chapter 2, we discussed main differences between loosely and tightly structured |
In chapter 2, we discussed main differences between loosely and tightly structured |
1834 |
approaches. As stated, the most significant difference is that tightly structured |
approaches. As stated, the most significant difference is that tightly structured |
1835 |
approach has logarithmical properties in all internal operations, while loosely |
approach has logarithmical properties in all internal operations, while loosely |
1836 |
structured approach doesn't have always even linear properties. Furthermore, the |
structured approach doesn't always have even linear properties. Furthermore, the |
1837 |
data lookup model of tightly structured overlay scales much better than loosely |
data lookup model of tightly structured overlay scales much better than loosely |
1838 |
structured overlays; tightly structured overlay supports global data lookups |
structured overlays; tightly structured overlay supports global data lookups |
1839 |
in the overlay, whereas the data lookup model of loosely structured approach |
in the overlay, whereas the data lookup model of loosely structured approach |
1853 |
\emph{semantic free}. Finally, as said, with tightly structured systems, it is feasible to |
\emph{semantic free}. Finally, as said, with tightly structured systems, it is feasible to |
1854 |
perform \emph{global} data lookups in the overlay. To summarize, these aspects may be the most important features |
perform \emph{global} data lookups in the overlay. To summarize, these aspects may be the most important features |
1855 |
of Peer-to-Peer infrastructure with regard to Fenfire as a \emph{distributed} hypermedia system. |
of Peer-to-Peer infrastructure with regard to Fenfire as a \emph{distributed} hypermedia system. |
1856 |
Thus, we see the tightly structured approach the best alternative to locate data in Peer-to-Peer |
Thus, we see the tightly structured approach as the best alternative to locate data in Peer-to-Peer |
1857 |
environment. |
environment. |
1858 |
|
|
1859 |
Once located, for \emph{fetching} Fenfire related data from the overlay, we can use regular |
Once located, for \emph{fetching} Fenfire related data from the overlay, we can use regular |
1874 |
|
|
1875 |
Again, there are open issues with tightly structured systems which have to be |
Again, there are open issues with tightly structured systems which have to be |
1876 |
addressed, as described in chapter 3. The main concerns include decreased performance and fault |
addressed, as described in chapter 3. The main concerns include decreased performance and fault |
1877 |
tolerance when system in flux-state, non-optimal distance functions in identifier space, |
tolerance when system in presence of system flux, non-optimal distance functions in identifier space, |
1878 |
proximity routing, hostile entities and flexible search \cite{balakrishanarticle03lookupp2p}. |
proximity routing, hostile entities and flexible search \cite{balakrishanarticle03lookupp2p}. |
1879 |
Additionally, there is only little real world experiments yet with tightly structured systems |
Additionally, there is only little real world experiments yet with tightly structured systems |
1880 |
(e.g., \cite{overneturl}, \cite{edonkey2kurl}). Therefore, we can't say for sure, how well these |
(e.g., \cite{overneturl}, \cite{edonkey2kurl}). Therefore, we can't say for sure, how well these |
1885 |
|
|
1886 |
\section{Fenfire system model in Peer-to-Peer environment} |
\section{Fenfire system model in Peer-to-Peer environment} |
1887 |
|
|
1888 |
In this section present a proposal of Fenfire Peer-to-Peer system, which consists |
In this section we give a proposal of Fenfire Peer-to-Peer system, which consists |
1889 |
of several technologies presented in this thesis. Then, we introduce yet simple but |
of several technologies reviewed in this thesis. Then, we introduce yet simple but |
1890 |
effective algorithms for obtaining Fenfire data from Peer-to-Peer environment. |
effective algorithms for obtaining Fenfire data from Peer-to-Peer environment. |
1891 |
|
|
1892 |
\subsection{System proposal} |
\subsection{System proposal} |
1899 |
\cite{kato02gisp}), which means that Kademlia's algorithm is simple and easy to implement. |
\cite{kato02gisp}), which means that Kademlia's algorithm is simple and easy to implement. |
1900 |
|
|
1901 |
On top of Kademlia, we propose the usage of Sloppy hashing \cite{sloppy:iptps03} which |
On top of Kademlia, we propose the usage of Sloppy hashing \cite{sloppy:iptps03} which |
1902 |
optimized for DOLR abstraction of tightly structured overlays. With Sloppy hashing, |
is optimized for DOLR abstraction of tightly structured overlays. With Sloppy hashing, |
1903 |
we are able reduce of generation of query hot spots. Sloppy hashing enables to |
we are able to reduce the generation of query hot spots. Sloppy hashing enables to |
1904 |
locate nearby data without looking up data from distant nodes. Moreover, authors' |
locate nearby data without looking up data from distant nodes. Moreover, authors' |
1905 |
proposal for self-organizing clusters using network diameters may be useful, |
proposal for self-organizing clusters using network diameters may be useful, |
1906 |
especially within small groups of working people. Thus, with Sloppy hashing |
especially within small groups of working people. Thus, with Sloppy hashing |
1914 |
Finally, for more efficient data transfer, we can use variable techniques for this purpose. |
Finally, for more efficient data transfer, we can use variable techniques for this purpose. |
1915 |
For small amounts of data, HTTP can be used \cite{rfc2068}. For big downloads, we can use |
For small amounts of data, HTTP can be used \cite{rfc2068}. For big downloads, we can use |
1916 |
multi source downloads for better efficiency and reliability. Specifically, technology based |
multi source downloads for better efficiency and reliability. Specifically, technology based |
1917 |
on rate less erasure codes \cite{maymounkov03ratelesscodes} seems very promising. |
on rateless erasure codes \cite{maymounkov03ratelesscodes} seems very promising. |
1918 |
|
|
1919 |
\subsection{Algorithms} |
\subsection{Algorithms} |
1920 |
|
|
1921 |
We use DOLR abstraction of tightly of structured approach, i.e., each participating peer hosts |
We use DOLR abstraction of tightly structured approach, i.e., each participating peer hosts |
1922 |
the data and overlay maintains only the \emph{pointers} to the data. We decided to use DOLR in our |
the data and overlay maintains only the \emph{pointers} to the data. We decided to use DOLR in our |
1923 |
model, since DOLR systems locate data without specifying a storage policy explicitly \cite{rhea03benchmarks}. |
model, since DOLR systems locate data without specifying a storage policy explicitly \cite{rhea03benchmarks}. |
1924 |
DHT based storage systems, such as CFS \cite{dabek01widearea} and PAST \cite{rowstron01storage}, may have |
DHT based storage systems, such as CFS \cite{dabek01widearea} and PAST \cite{rowstron01storage}, may have |
1925 |
critical problems with load balancing in highly heterogeneous environment. This problem is caused by peers |
critical problems with load balancing in highly heterogeneous environment. This problem is caused by peers |
1926 |
which may not able to store relative great amount of data with key/value pair, assigned randomly by |
which may not be able to store relatively large amount of data with key/value pair, assigned randomly by |
1927 |
mapping function of the overlay. Additionally, these systems wastes both storage and bandwidth, and |
mapping function of the overlay. Additionally, these systems wastes both storage and bandwidth, and |
1928 |
are sensitive to certain attacks (e.g., DDoS attack). |
are sensitive to certain attacks (e.g., DDoS attack). |
1929 |
|
|
1961 |
\begin{itemize} |
\begin{itemize} |
1962 |
\item Data lookup with a given pointer random string returning most recent scroll block. |
\item Data lookup with a given pointer random string returning most recent scroll block. |
1963 |
\begin{enumerate} |
\begin{enumerate} |
1964 |
\item Query originator locally compute a hash for given pointer random string. |
\item Query originator locally computes a hash for given pointer random string. |
1965 |
\item Repeat until hosting peer is found: each peer forwards the data lookup to a closer peer which hosts the given hash of pointer random string. |
\item Repeat until hosting peer is found: each peer forwards the data lookup to a closer peer which hosts the given hash of pointer random string. |
1966 |
\item Pointer peer returns most recent pointer block's key/value-pair (e.g., hosting peer's IP-address) to query originator, using pointer block's own indexing schemes. |
\item Pointer peer returns most recent pointer block's key/value-pair (e.g., hosting peer's IP-address) to query originator, using pointer block's own indexing schemes. |
1967 |
\item Query originator requests hosting peer to return the scroll block. |
\item Query originator requests hosting peer to return the scroll block. |
1972 |
\item Data lookup with a given pointer random string returning scroll block(s) for a given date and time range. |
\item Data lookup with a given pointer random string returning scroll block(s) for a given date and time range. |
1973 |
\begin{enumerate} |
\begin{enumerate} |
1974 |
|
|
1975 |
\item Query originator locally compute a hash for given pointer random string. |
\item Query originator locally computes a hash for given pointer random string. |
1976 |
\item Repeat until hosting peer is found: each peer forwards the data lookup to a closer peer which hosts the given hash of pointer random string. |
\item Repeat until hosting peer is found: each peer forwards the data lookup to a closer peer which hosts the given hash of pointer random string. |
1977 |
\item Pointer peer returns pointer block's key/value-pair(s) (e.g., hosting peer's IP-addresses) to query originator, using pointer block's own indexing schemes. |
\item Pointer peer returns pointer block's key/value-pair(s) (e.g., hosting peer's IP-addresses) to query originator, using pointer block's own indexing schemes. |
1978 |
\item Query originator requests hosting peer to return the scroll block. |
\item Query originator requests hosting peer to return the scroll block. |
2009 |
security technologies. For instance, online entities cannot be identified |
security technologies. For instance, online entities cannot be identified |
2010 |
safely (e.g., the Sybil attack \cite{douceur02sybil}). For Fenfire, one |
safely (e.g., the Sybil attack \cite{douceur02sybil}). For Fenfire, one |
2011 |
security related problem occurs when user wants to perform global data lookup with a given |
security related problem occurs when user wants to perform global data lookup with a given |
2012 |
pointer random string; how user is able to verify the correctness |
pointer random string; how the user is able to verify the correctness |
2013 |
of the search results, and how do we know which one is the |
of the search results, and how do we know which one is the |
2014 |
correct Storm scroll block ? Spam attack \cite{naor03simpledht} is a variation of previously |
correct Storm scroll block ? Spam attack \cite{naor03simpledht} is a variation of previously |
2015 |
mentioned problem; data lookup is performed by a user, but there is no reply |
mentioned problem; data lookup is performed by user, but there is no reply |
2016 |
from the system. How do we are able to know if this was a spam attack, or the |
from the system. How we are able to know if this was a spam attack, or the |
2017 |
data really doesn't exist in the system ? Another problem related to Fenfire's |
data really doesn't exist in the system ? Another problem related to Fenfire's |
2018 |
security is that if a user downloads data from the network to local computer |
security is that if a user downloads data from the network to local computer |
2019 |
and after network disconnection, user wants to verify \emph{off line} the |
and after network disconnection, user wants to verify \emph{off line} the |
2050 |
hash \cite{fips-sha-1}. As the authors of \cite{balakrishnan03semanticfree}, |
hash \cite{fips-sha-1}. As the authors of \cite{balakrishnan03semanticfree}, |
2051 |
we also agree that tightly structured overlays provide general purpose |
we also agree that tightly structured overlays provide general purpose |
2052 |
interface to next-generation reference resolution services. Third, by using |
interface to next-generation reference resolution services. Third, by using |
2053 |
DOLR abstraction of tightly structured overlay, we can minimize the the lack |
DOLR abstraction of tightly structured overlay, we can minimize the lack |
2054 |
of locality in tightly structured overlays. Finally, we believe that issues |
of locality in tightly structured overlays. Finally, we believe that issues |
2055 |
related to tightly structured overlays are solved in near future, because of |
related to tightly structured overlays are solved in near future, because of |
2056 |
wide and intensive co-operation among research groups. |
wide and intensive co-operation among research groups. |
2062 |
blocks \emph{directly} from the network. Techniques used in distributed |
blocks \emph{directly} from the network. Techniques used in distributed |
2063 |
database systems may prove to be useful. Some fundamental results |
database systems may prove to be useful. Some fundamental results |
2064 |
regarding Peer-to-Peer and database systems has already been |
regarding Peer-to-Peer and database systems has already been |
2065 |
presented \cite{gribble01p2pdatabase}. |
presented \cite{gribble01p2pdatabase}. |
2066 |
|
|
2067 |
As security technologies comes more mature, we wish to apply these |
As security technologies come more mature, we wish to apply these |
2068 |
technologies with Fenfire, if applicable. |
technologies with Fenfire, if applicable. In the following months, we will |
2069 |
|
implement a Fenfire Peer-to-Peer prototype. |
|
In the following months, we will implement a Fenfire Peer-to-Peer |
|
|
prototype. |
|
2070 |
|
|
2071 |
\bibliographystyle{gradu} |
\bibliographystyle{gradu} |
2072 |
\bibliography{progradu} |
\bibliography{progradu} |