[Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert...

[Hermanni Hyytiälä]

CVSROOT:        /cvsroot/gzz
Module name:    gzz
Changes by:     Hermanni Hyytiälä <address@hidden>      03/03/24 06:44:59

Modified files:
        Documentation/misc/hemppah-progradu: masterthesis.tex 

Log message:
        More updates

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/Documentation/misc/hemppah-progradu/masterthesis.tex.diff?tr1=1.175&tr2=1.176&r1=text&r2=text

Patches:
Index: gzz/Documentation/misc/hemppah-progradu/masterthesis.tex
diff -u gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.175 
gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.176
--- gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.175      Mon Mar 
24 05:26:09 2003
+++ gzz/Documentation/misc/hemppah-progradu/masterthesis.tex    Mon Mar 24 
06:44:58 2003
@@ -960,24 +960,25 @@
 \subsection{Access control}
 
 Any distributed computing system must support different levels of access 
control. For instance, in a Peer-to-Peer
-system, we may want to restrict the accessibility of data to only limited 
amount of participating peers. Yet, Peer-to-Peer 
-systems do not have a working and distributed access control scheme. Moreover, 
-there has been a lot of violations of copyright laws by users of Peer-to-Peer 
file sharing systems. As a 
+system, we may want to restrict the accessibility of data to the limited 
amount of participating peers. Yet, Peer-to-Peer 
+systems do not have a working access control scheme. Moreover, 
+there have been lot of violations of copyright laws by users of Peer-to-Peer 
file sharing systems. As a 
 consequence, some law suits have been filed against the companies who have 
build popular file-sharing programs.
 
-To our knowledge, Nejdl et al. \cite{nejdl03accesscontrol} have very recently 
proposed the first practical solution to access 
-control problem in Peer-to-Peer systems. They use Resource Description 
Framework (RDF) \cite{w3rdfurl} based 
-schema policies to restrict access to certain data. Unfortunately, their 
current early prototype version only works in 
+Nejdl et al. \cite{nejdl03accesscontrol} have very recently proposed a 
practical solution to access 
+control problem. They use Resource Description Framework (RDF) \cite{w3rdfurl} 
based 
+schema policies to restrict access to certain data. Their current early 
prototype version only works in 
 loosely structured systems.
 
 
 \subsection{Hostile entities}
 
-One serious problem in Peer-to-Peer systems is the inability to identify 
hostile entities as trustworthy.
-Possible solutions include self-monitoring systems \cite{zhang03somo}, 
maintaining system invariants as
-proposed in \cite{sit02securitycons}, distributed and secure peer identifier 
assignment 
-\cite{castro02securerouting}, \cite{clarke00freenet} and self-certifying data 
using cryptographic 
-content hashes (e.g., SHA-1 \cite{fips-sha-1}). Identification of hostile 
entities is essential in the tightly structured 
+One serious problem in Peer-to-Peer systems is the inability to identify 
hostile entities.
+One possible solution is to use a self-monitoring system, such as SOMO 
\cite{zhang03somo}, in which a self-monitoring overlay
+constantly analyses the Peer-to-Peer overlay. Self-monitoring overlay is built 
on top of Peer-to-Peer overlay. Authors in
+\cite{sit02securitycons} suggest the use of system invariants. They emphasize 
that system invariants should be veriable, and if
+system invariants fail the system must have a recovery mechanism. In 
distributed peer identifier assignment \cite{castro02securerouting, 
clarke00freenet}, 
+multiple participating peers participate in a creation of peer identifier. 
Identification of hostile entities is essential in the tightly structured 
 approach, in which the fundamental (and implicit) assumption is that there is 
a random, uniform distribution 
 of peer identifiers that cannot be controlled by a hostile entity.
 
@@ -989,40 +990,37 @@
 
 \subsection{Secure query routing}
 
-Much work has been done on secure routing, especially related to tightly 
structured systems. In 
-\cite{castro02securitystructured} and \cite{castro02securerouting}, authors 
suggest the use
-of constrained routing tables and diverse routes, and the detection of faults 
during data lookup routing.
-Additionally, authors present in \cite{castro02securerouting} an important 
aspect of the tightly structured approach with regard
-to fault tolerant query routing: the probability of routing successfully 
between to arbitrary 
-correct peers, when a fraction $f$ of the other peers are faulty or hostile, 
is only $(1-f)^{h-1}$, where
-$h$ is the number of hops in the overlay.
-
-Sit and Morris \cite{sit02securitycons} discuss the possibility of allowing 
the query originator 
-to observe lookup progress and cross-check routing tables using random 
queries. However, their
- approach is not very efficient, since this method creates lot of additional 
network traffic when
-in function.
-
-Additionally, Lynch et al. \cite{lynch02atomicdataaccess} propose a solution 
for secure routing table 
-maintenance, but their solution seems to have two major problems 
\cite{castro02securitystructured}. First,
-the solution is very expensive even without faulty or hostile entities. 
Second, each group of replicas
-in their solution must have less than 1/3 of its peers faulty. Thus, this 
feature results in a low
-probability of successful routing.
+By secure routing, we mean that a Peer-to-Peer system is able to deliver a 
network message
+thoughout the overlay to a correct destination.
 
 Aspnes et al. in \cite{aspnes02faultrouting} and Kaashoek et al. in 
\cite{kaashoek03koorde} formally 
-prove the lower and upper bounds for the space requirements of locating a 
specific data item in a 
+prove the lower and upper bounds for the space requirements of locating a 
specific data item reliable in a 
 Peer-to-Peer system. They show that to provide high degree of fault tolerance 
and efficiency in the system, each 
-participating peer must maintain average of $O(\log{n})$ neighbors. 
-
-Fiat et al. in \cite{fiat02censorship, saia02dynamicfaultcontentnetwork} and 
Datar in \cite{datar02butterflies}  
-describe a tightly structured overlay with analytical results in the presence 
of hostile entities. However,
-none of these proposals address a dynamic tightly structured overlay with 
fault tolerance against multiple rounds
+participating peer must maintain average of $O(\log{n})$ neighbors. Fiat et 
al. in \cite{fiat02censorship, saia02dynamicfaultcontentnetwork} 
+and Datar in \cite{datar02butterflies} propose a tightly structured overlay 
with analytical results in the 
+presence of hostile entities. However, none of these proposals address a 
dynamic tightly structured 
+overlay with fault tolerance against multiple rounds
 of hostile attacks. Also, above mentioned proposals are not very efficient. In 
\cite{fiat02censorship}, each peer 
-must maintain information of $O(\log^3{n})$ other peers, and in 
\cite{datar02butterflies}, $O(\log^2{n})$ is required.
+must maintain information of $O(\log^3{n})$ other peers, and in 
\cite{datar02butterflies}, $O(\log^2{n})$ is required.  
 
-Finally, Ratnasamy and Gavoille \cite{ratnasamy02routing, gavoille01routing} 
list several open problems
-regarding routing in distributed networks. Obviously, more research is 
required in order to provide secure
-data lookup routing in Peer-to-Peer networks.
+Authors argue in \cite{castro02securitystructured} that with the combination 
of 
+secure peer identifer assignment, secure routing table maintenance and secure 
message forwarding
+the secure routing in tightly structured systems is possible. Additionally, 
authors cite in \cite{castro02securerouting} 
+that the probability of routing successfully between to arbitrary 
+correct peers is $(1-f)^{h-1}$, when a fraction $f$ of the other peers are 
faulty or hostile and where
+$h$ is the number of hops in the overlay. Sit and Morris 
\cite{sit02securitycons} discuss the possibility of 
+allowing the query originator to observe lookup progress and cross-check 
routing tables using random queries to achieve
+secure routing in tightly structured overlay. However, their
+approach is not very efficient, since this method creates lot of additional 
network traffic when
+in function i.e., it is unknown if this techique is realizable in a efficient 
way.
+Lynch et al. \cite{lynch02atomicdataaccess} propose a solution for secure 
routing table 
+maintenance, but their solution seems to have two major problems according to 
\cite{castro02securitystructured}. 
+First, the solution is very expensive even without faulty or hostile entities. 
Second, each group of replicas
+in their solution must have less than 1/3 of its peers faulty. Thus, this 
feature results in a low
+probability of successful routing.
 
+Finally, Gavoille \cite{gavoille01routing} lists open problems in general 
distributed systems 
+(not only in Peer-to-Peer domain).
 
 \subsection{Other security threats}
 
@@ -1030,12 +1028,136 @@
 the list includes viruses and trojans. Currently, there are not even partial 
solutions
 to the problems mentioned above.  The reason for this is that there are no 
experience about these kinds of 
 attacks. Possible solution would be a distributed anti-virus software, but 
much more intensive research is required until
-this kind of solution would be applicable. 
+this kind of solution would be applicable.
+
+\subsection{Summary}
+
+In this subsection we list security problems in Peer-to-Peer systems in the 
table.
+
+
+\scriptsize
+\begin{longtable}{|l|l|l|l|}
+
+\hline 
+\multicolumn{1}{|c|}{\textbf{Problem}} & 
+\multicolumn{1}{c|}{\textbf{Problem description}} & 
+\multicolumn{1}{c|}{\textbf{Solutions}} &
+\multicolumn{1}{c|}{\textbf{Comments/Status}}
+\\ \hline 
+\endfirsthead
+
+\multicolumn{4}{c}%
+{{\tablename\ \thetable{} -- continued from previous page}} \\
+\hline \multicolumn{1}{|c|}{\textbf{Problem}} &
+\multicolumn{1}{c|}{\textbf{Problem description}} &
+\multicolumn{1}{c|}{\textbf{Solutions}} &
+\multicolumn{1}{c|}{\textbf{Comments/Status}} 
+\\ \hline 
+\endhead
+
+\endfoot
+
+
+
+\parbox{90pt}{Query routing \cite{sit02securitycons, aspnes02faultrouting, 
castro02securerouting, ratnasamy02routing, gavoille01routing,
+lynch02atomicdataaccess, fiat02censorship, saia02dynamicfaultcontentnetwork, 
datar02butterflies}} &                    
+\parbox{110pt}{Incorrect forwarding (hostile), incorrect routing (hostile)} &
+\parbox{110pt}{Query monitoring, cross check routing tables, verify routing 
tables, create routing table invariants} &
+\parbox{110pt}{Increases system complexity} 
+\\ \hline
+
+
+\parbox{90pt}{DoS attack \cite{sit02securitycons, 
saia02dynamicfaultcontentnetwork, datar02butterflies, daswani02queryflooddos, 
juels99clientpuzzles}} &
+\parbox{110pt}{Distributed, controlled burden against specific computer(s)} &
+\parbox{110pt}{Client puzzles, load balancing, traffic measurements, traffic 
models, replication} &
+\parbox{110pt}{Only partial solutions, traffic models most effective}
+\\ \hline 
+
+
+\parbox{90pt}{Sybil attack \cite{douceur02sybil, castro02securerouting}} &
+\parbox{110pt}{Single hostile entity presents multiple entities} &
+\parbox{110pt}{Identify all peers simultaneously across the system, collect 
pool of peers which are validated, distributed peer ID creation} &
+\parbox{110pt}{Not practically realizable, research focused on persistence, 
not on identity distinction}
+\\ \hline 
+
+
+\parbox{90pt}{Spam attack \cite{naor03simpledht}} &
+\parbox{110pt}{Hostile entity creates false versions of data, or gives wrong 
information about the data which entity is responsible for/knows about} &
+\parbox{110pt}{Do not trust to single entity, get information from multiple 
entities, trust on majority's opinion} &
+\parbox{110pt}{Easy to implement, creates more network traffic} 
+\\ \hline
+
+
+\parbox{90pt}{Entity identification \cite{ajmani02conchord}, 
\cite{douceur02sybil}} &
+\parbox{110pt}{Identify participating entities reliably and efficiently        
} &
+\parbox{110pt}{Digital signatures, key infrastructure} &
+\parbox{110pt}{Not practically realizable}
+\\ \hline
+
+
+\parbox{90pt}{Data integrity/authenticity \cite{fips-sha-1}, 
\cite{rivest96sdsi}, \cite{spkiworkinggroup}} &
+\parbox{110pt}{Integrity/originality of data is unknown} &
+\parbox{110pt}{Cryptographic content hashes, key architectures} &
+\parbox{110pt}{For data integrity, there are working solutions, but for data 
authenticity, some of the solutions are partial, which may be practically 
realizable}
+\\ \hline
+
+
+\parbox{90pt}{Anonymity \cite{dingledine00free, tarzan:ccs9, pub00, 
clarke00freenet, reiter98crowds, 352607, 502002}} &
+\parbox{110pt}{Anonymity cannot be provided in all cases} &
+\parbox{110pt}{Remailers, pre-routing} &
+\parbox{110pt}{Total anonymity cannot be provided yet}
+\\ \hline
+
+
+\parbox{90pt}{Malicious peers \cite{sit02securitycons, castro02securerouting}} 
&
+\parbox{110pt}{How to identify malicious peers in the system ?} &
+\parbox{110pt}{Create invariants for peer behavior, verify invariants, 
self-certifying data} &
+\parbox{110pt}{Partial solutions, self-certifying data most reliable}
+\\ \hline
+
+
+\parbox{90pt}{Access Control \cite{nejdl03accesscontrol, 
daswani03openproblems}} &
+\parbox{110pt}{Can we define access control levels in Peer-to-Peer network ?} &
+\parbox{110pt}{Schema-based rules} &
+\parbox{110pt}{Some initial experiences, need more research}
+\\ \hline
+
+
+\parbox{90pt}{Inconsistent behavior \cite{sit02securitycons}} &
+\parbox{110pt}{Hostile peer could act correctly with its neighbors, but 
incorrectly with others} &
+\parbox{110pt}{Public keys, digital signatures} &
+\parbox{110pt}{Not practical approach/working proposal created yet}
+\\ \hline
+
+
+\parbox{90pt}{Hostile groups \cite{castro02securerouting}} &
+\parbox{110pt}{Joining peer may join parallel network, formed a group of 
hostile peers, hostile peer(s) controls the construction of the network} &
+\parbox{110pt}{Use trusted peers, based on history information, cryptography, 
key infrastructure} &
+\parbox{110pt}{Not 100\% sure if Central Authority (CA) is missing, not 
practical approach/working proposal created yet}
+\\ \hline
+
+
+\parbox{90pt}{External security threats \cite{grahamp2psecurity}} &
+\parbox{110pt}{Viruses, trojans, sniffers} &
+\parbox{110pt}{Data integrity/authenticity, distributed anti virus software} &
+\parbox{110pt}{Not much research has been done on this}
+\\ \hline
+
+\caption{Security problems in Peer-to-Peer.} 
+\label{table_security_problems_Peer-to-Peer}
+
+
+\end{longtable}
+\normalsize
+        
 
 
 \section{Performance and usability problems in Peer-to-Peer}
 
-In this section, we discuss performance issues regarding Peer-to-Peer systems.
+In this section, we discuss performance and usability issues regarding 
Peer-to-Peer systems. We start
+by describing techniques to improve data lookups in Peer-to-Peer systems. 
Then, we focus on web-like
+searches and system management problems.
+
 
 \subsection{Efficient data lookup}
 
@@ -1043,12 +1165,12 @@
 especially with the loosely structured approach. In iterative deepening 
 \cite{yang02improvingsearch}, multiple BFS searches are initiated
 with successively larger TTL depth limits, until either the query is 
satisfied, 
-or the maximum depth $D$ has been reached. To perform a data lookup, the query
-originator starts the data lookup with a small TTL value. If the search is not 
successful,
-the query originator increases the TTL value and performs another data lookup. 
This 
-process is repeated until the desired data is found or the maximum depth $D$ 
-has been reached. Expanding ring, proposed by Shenker et al. in 
\cite{lv02searchreplication}, 
-is similar to the iterative deepening technique. With these techniques, 
searches 
+or the maximum depth $D$ has been reached. 
+
+Expanding ring, proposed by Shenker et al. in \cite{lv02searchreplication}, 
+is similar to the iterative deepening technique. In this method, a peer starts 
a flood with small TTL, and 
+waits to see if the search is successful. If it is, then the peer stops the 
data lookuo. Otherwise, the peer increases 
+the TTL and starts another data lookup. With these techniques, searches 
 may not be fast when desired data item requires several consecutive flooding 
rounds.
 
 Directed BFS \cite{yang02improvingsearch} optimizes the original 
@@ -1069,8 +1191,9 @@
 has a poor response time but it doesn't generate as much network traffic as 
 the original BFS. As suggested in \cite{lv02searchreplication}, the
 random walk approach can be made more effective by introducing
-multiple ''walkers''. Freenet \cite{clarke00freenet} uses 
-random walk searches in data lookups. Freenet's data lookup model resembles
+multiple ''walkers''. 
+
+Freenet \cite{clarke00freenet} uses random walk searches in data lookups. 
Freenet's data lookup model resembles
 Depth-First-Search (DFS) and peers' routing tables are dynamically built
 using caching. This is an outcome of Freenet's main design principles, 
anonymity. 
 Another property of the Freenet's data lookup model is that
@@ -1189,184 +1312,12 @@
 call their technique as a \emph{data overlay}, since it supports several 
fundamental data structures.
 Authors have used this data overlay when building a Self-Organized Meta data 
Overlay (SOMO), which can be used
 for monitoring the health of a tightly structured overlay. The fault tolerance 
of SOMO itself is currently
-unknown. 
-
-
-\section{Miscellaneous problems in Peer-to-Peer}
-
-In this section we discuss miscellaneous problems in Peer-to-Peer systems.
-
-\subsection{Programming guidelines and benchmarks}
-
-All existing Peer-to-Peer systems have rather different interfaces even though 
they have common properties and 
-components. More important, all existing Peer-to-Peer systems are incompatible 
with each other. One
-of the most important area of future research is to create common programming 
abstractions, i.e.,
-interfaces, design patters and frameworks. Also, benchmarks are needed for 
comparing
-different algorithms equally. Recently, there have been few proposals towards 
common programming
-guidelines. This list includes \cite{zhao03api, frise02p2pframework, 
babaoglu02anthill}.
-Early experiments with Peer-to-Peer benchmarking include 
\cite{ratnasamy02routing, rhea03benchmarks}.
+unknown.
 
-\subsection{Social behavior}
+\subsection{Summary}
 
-Frequent assumption in Peer-to-Peer systems is that peers are willing to 
cooperate. Another belief 
-is that all peers would behave equally, i.e., all peers both consume and 
contribute services.
-However, these assumptions are not true as several studies show 
\cite{saroiu02measurementstudyp2p, 
-oram01harnessingpower, hearn02mojonation}. Peers rather consume than 
contribute and peers are 
-unwilling to cooperate. 
-
-Somewhat surprisingly little research has been done in this area, especially 
when considering 
-the possible impact of \emph{unwanted social behavior} to performance of a 
Peer-to-Peer 
-system. The problem is addressed by Golle et al. \cite{golle01incentivesp2p}, 
Ngan et al. 
-\cite{ngan03enforcefile} and Shneidman et al. \cite{shneidman03rationality}. 
Some 
-research has been focused on semantic properties of the overlay in order to 
increase 
-cooperation among participating peers \cite{crespo02semanticoverlay}. 
Ramanathan et al. 
-\cite{ramanathan02goodpeers} and Bernstein et al. \cite{bernstein03selection} 
use 
-empirical metrics and decision trees when teaching peers to make better 
decisions
-when contacting other peers in Peer-to-Peer system. Alpine \cite{alpineurl} is 
an example of
-Peer-to-Peer system, which uses empirical metrics for peer selection.
-
-
-\subsection{Simulating Peer-to-Peer systems}
-
-Very little research has been done on simulating a Peer-to-Peer system. 
Presumably, this
-is due to complex nature of Peer-to-Peer system, which makes comprehensive 
simulations very 
-difficult. Floyd et al. have been studying the simulation of the Internet in 
\cite{504642}. Authors
-state that simulating the Internet is very challenging task, because of its 
heterogeneity
-and rapid change. Obviously, these factors exist also in Peer-to-Peer systems 
even with higher
-rates.
-
-As long as comprehensive simulations of a Peer-to-Peer systems are lacking, we 
cannot make any detailed
-analysis on general properties of a Peer-to-Peer system, such as usage 
patterns. However, we can assume 
-that, e.g., query keywords follow the Zipf-like distribution 
\cite{breslau98implications} both in the 
-Internet and in Peer-to-Peer systems.
+In this subsection we list performance and usability problems in Peer-to-Peer 
systems in the table.
 
-\section{Summary}
-
-In this section we summarize open problems in Peer-to-Peer systems. All the 
open problem entries 
-listed in this section are not necessarily mentioned in the previous sections. 
Problems listed 
-here are variations of previously mentioned problems, or otherwise related to 
them. 
-
-In table \ref{table_security_problems_Peer-to-Peer} open problems related to 
security are listed; in 
-table \ref{table_performanceusability_problems_Peer-to-Peer} problems related 
to performance are 
-listed; in table \ref{table_Miscellaneous_problems_Peer-to-Peer} miscellaneous 
open problems are listed.
-
-
-\scriptsize
-\begin{longtable}{|l|l|l|l|}
-
-\hline 
-\multicolumn{1}{|c|}{\textbf{Problem}} & 
-\multicolumn{1}{c|}{\textbf{Problem description}} & 
-\multicolumn{1}{c|}{\textbf{Solutions}} &
-\multicolumn{1}{c|}{\textbf{Comments/Status}}
-\\ \hline 
-\endfirsthead
-
-\multicolumn{4}{c}%
-{{\tablename\ \thetable{} -- continued from previous page}} \\
-\hline \multicolumn{1}{|c|}{\textbf{Problem}} &
-\multicolumn{1}{c|}{\textbf{Problem description}} &
-\multicolumn{1}{c|}{\textbf{Solutions}} &
-\multicolumn{1}{c|}{\textbf{Comments/Status}} 
-\\ \hline 
-\endhead
-
-\endfoot
-
-
-
-\parbox{90pt}{Query routing \cite{sit02securitycons, aspnes02faultrouting, 
castro02securerouting, ratnasamy02routing, gavoille01routing,
-lynch02atomicdataaccess, fiat02censorship, saia02dynamicfaultcontentnetwork, 
datar02butterflies}} &                    
-\parbox{110pt}{Incorrect forwarding (hostile), incorrect routing (hostile)} &
-\parbox{110pt}{Query monitoring, cross check routing tables, verify routing 
tables, create routing table invariants} &
-\parbox{110pt}{Increases system complexity} 
-\\ \hline
-
-
-\parbox{90pt}{DoS attack \cite{sit02securitycons, 
saia02dynamicfaultcontentnetwork, datar02butterflies, daswani02queryflooddos, 
juels99clientpuzzles}} &
-\parbox{110pt}{Distributed, controlled burden against specific computer(s)} &
-\parbox{110pt}{Client puzzles, load balancing, traffic measurements, traffic 
models, replication} &
-\parbox{110pt}{Only partial solutions, traffic models most effective}
-\\ \hline 
-
-
-\parbox{90pt}{Sybil attack \cite{douceur02sybil, castro02securerouting}} &
-\parbox{110pt}{Single hostile entity presents multiple entities} &
-\parbox{110pt}{Identify all peers simultaneously across the system, collect 
pool of peers which are validated, distributed peer ID creation} &
-\parbox{110pt}{Not practically realizable, research focused on persistence, 
not on identity distinction}
-\\ \hline 
-
-
-\parbox{90pt}{Spam attack \cite{naor03simpledht}} &
-\parbox{110pt}{Hostile entity creates false versions of data, or gives wrong 
information about the data which entity is responsible for/knows about} &
-\parbox{110pt}{Do not trust to single entity, get information from multiple 
entities, trust on majority's opinion} &
-\parbox{110pt}{Easy to implement, creates more network traffic} 
-\\ \hline
-
-
-\parbox{90pt}{Entity identification \cite{ajmani02conchord}, 
\cite{douceur02sybil}} &
-\parbox{110pt}{Identify participating entities reliably and efficiently        
} &
-\parbox{110pt}{Digital signatures, key infrastructure} &
-\parbox{110pt}{Not practically realizable}
-\\ \hline
-
-
-\parbox{90pt}{Data integrity/authenticity \cite{fips-sha-1}, 
\cite{rivest96sdsi}, \cite{spkiworkinggroup}} &
-\parbox{110pt}{Integrity/originality of data is unknown} &
-\parbox{110pt}{Cryptographic content hashes, key architectures} &
-\parbox{110pt}{For data integrity, there are working solutions, but for data 
authenticity, some of the solutions are partial, which may be practically 
realizable}
-\\ \hline
-
-
-\parbox{90pt}{Anonymity \cite{dingledine00free, tarzan:ccs9, pub00, 
clarke00freenet, reiter98crowds, 352607, 502002}} &
-\parbox{110pt}{Anonymity cannot be provided in all cases} &
-\parbox{110pt}{Remailers, pre-routing} &
-\parbox{110pt}{Total anonymity cannot be provided yet}
-\\ \hline
-
-
-\parbox{90pt}{Malicious peers \cite{sit02securitycons, castro02securerouting}} 
&
-\parbox{110pt}{How to identify malicious peers in the system ?} &
-\parbox{110pt}{Create invariants for peer behavior, verify invariants, 
self-certifying data} &
-\parbox{110pt}{Partial solutions, self-certifying data most reliable}
-\\ \hline
-
-
-\parbox{90pt}{Access Control \cite{nejdl03accesscontrol, 
daswani03openproblems}} &
-\parbox{110pt}{Can we define access control levels in Peer-to-Peer network ?} &
-\parbox{110pt}{Schema-based rules} &
-\parbox{110pt}{Some initial experiences, need more research}
-\\ \hline
-
-
-\parbox{90pt}{Inconsistent behavior \cite{sit02securitycons}} &
-\parbox{110pt}{Hostile peer could act correctly with its neighbors, but 
incorrectly with others} &
-\parbox{110pt}{Public keys, digital signatures} &
-\parbox{110pt}{Not practical approach/working proposal created yet}
-\\ \hline
-
-
-\parbox{90pt}{Hostile groups \cite{castro02securerouting}} &
-\parbox{110pt}{Joining peer may join parallel network, formed a group of 
hostile peers, hostile peer(s) controls the construction of the network} &
-\parbox{110pt}{Use trusted peers, based on history information, cryptography, 
key infrastructure} &
-\parbox{110pt}{Not 100\% sure if Central Authority (CA) is missing, not 
practical approach/working proposal created yet}
-\\ \hline
-
-
-\parbox{90pt}{External security threats \cite{grahamp2psecurity}} &
-\parbox{110pt}{Viruses, trojans, sniffers} &
-\parbox{110pt}{Data integrity/authenticity, distributed anti virus software} &
-\parbox{110pt}{Not much research has been done on this}
-\\ \hline
-
-\caption{Security problems in Peer-to-Peer.} 
-\label{table_security_problems_Peer-to-Peer}
-
-
-\end{longtable}
-\normalsize
-       
-               
 
 \scriptsize
 \begin{longtable}{|l|l|l|l|}
@@ -1494,7 +1445,62 @@
                
 
 \end{longtable}
-\normalsize
+\normalsize 
+
+
+\section{Miscellaneous problems in Peer-to-Peer}
+
+In this section we discuss miscellaneous problems in Peer-to-Peer systems.
+
+\subsection{Programming guidelines and benchmarks}
+
+All existing Peer-to-Peer systems have rather different interfaces even though 
they have common properties and 
+components. More important, all existing Peer-to-Peer systems are incompatible 
with each other. One
+of the most important area of future research is to create common programming 
abstractions, i.e.,
+interfaces, design patters and frameworks. Also, benchmarks are needed for 
comparing
+different algorithms equally. Recently, there have been few proposals towards 
common programming
+guidelines. This list includes \cite{zhao03api, frise02p2pframework, 
babaoglu02anthill}.
+Early experiments with Peer-to-Peer benchmarking include 
\cite{ratnasamy02routing, rhea03benchmarks}.
+
+\subsection{Social behavior}
+
+Frequent assumption in Peer-to-Peer systems is that peers are willing to 
cooperate. Another belief 
+is that all peers would behave equally, i.e., all peers both consume and 
contribute services.
+However, these assumptions are not true as several studies show 
\cite{saroiu02measurementstudyp2p, 
+oram01harnessingpower, hearn02mojonation}. Peers rather consume than 
contribute and peers are 
+unwilling to cooperate. 
+
+Somewhat surprisingly little research has been done in this area, especially 
when considering 
+the possible impact of \emph{unwanted social behavior} to performance of a 
Peer-to-Peer 
+system. The problem is addressed by Golle et al. \cite{golle01incentivesp2p}, 
Ngan et al. 
+\cite{ngan03enforcefile} and Shneidman et al. \cite{shneidman03rationality}. 
Some 
+research has been focused on semantic properties of the overlay in order to 
increase 
+cooperation among participating peers \cite{crespo02semanticoverlay}. 
Ramanathan et al. 
+\cite{ramanathan02goodpeers} and Bernstein et al. \cite{bernstein03selection} 
use 
+empirical metrics and decision trees when teaching peers to make better 
decisions
+when contacting other peers in Peer-to-Peer system. Alpine \cite{alpineurl} is 
an example of
+Peer-to-Peer system, which uses empirical metrics for peer selection.
+
+
+\subsection{Simulating Peer-to-Peer systems}
+
+Very little research has been done on simulating a Peer-to-Peer system. 
Presumably, this
+is due to complex nature of Peer-to-Peer system, which makes comprehensive 
simulations very 
+difficult. Floyd et al. have been studying the simulation of the Internet in 
\cite{504642}. Authors
+state that simulating the Internet is very challenging task, because of its 
heterogeneity
+and rapid change. Obviously, these factors exist also in Peer-to-Peer systems 
even with higher
+rates.
+
+As long as comprehensive simulations of a Peer-to-Peer systems are lacking, we 
cannot make any detailed
+analysis on general properties of a Peer-to-Peer system, such as usage 
patterns. However, we can assume 
+that, e.g., query keywords follow the Zipf-like distribution 
\cite{breslau98implications} both in the 
+Internet and in Peer-to-Peer systems.
+
+
+               
+\subsection{Summary}
+
+In this subsection we list security problems in Peer-to-Peer systems in the 
table.
 
 
 \scriptsize
@@ -1578,10 +1584,9 @@
 
 \chapter{Fenfire hypermedia system}
 
-In this chapter we give an overview of the Fenfire system. We also 
-describe briefly xanalogical storage model. At the end of this chapter we 
study Storm, 
-Fenfire's software module, which is an essential part of Fenfire's 
Peer-to-Peer 
-functionality. 
+In this chapter we give an overview of the Fenfire system and 
+the xanalogical storage model. Also, we describe Storm 
+which is an essential part of Fenfire's Peer-to-Peer functionality. 
 
 \section{Overview}