[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert...
From: |
Hermanni Hyytiälä |
Subject: |
[Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert... |
Date: |
Tue, 18 Mar 2003 09:12:51 -0500 |
CVSROOT: /cvsroot/gzz
Module name: gzz
Changes by: Hermanni Hyytiälä <address@hidden> 03/03/18 09:12:51
Modified files:
Documentation/misc/hemppah-progradu: masterthesis.tex
Log message:
More updates and corrections
CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/Documentation/misc/hemppah-progradu/masterthesis.tex.diff?tr1=1.153&tr2=1.154&r1=text&r2=text
Patches:
Index: gzz/Documentation/misc/hemppah-progradu/masterthesis.tex
diff -u gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.153
gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.154
--- gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.153 Mon Mar
17 10:07:39 2003
+++ gzz/Documentation/misc/hemppah-progradu/masterthesis.tex Tue Mar 18
09:12:50 2003
@@ -1008,7 +1008,7 @@
Much work has been done on secure routing, especially related to tightly
structured systems. In
\cite{castro02securitystructured} and \cite{castro02securerouting}, authors
suggest the usage
-of constrained routing tables and diverse routes, and detection of faults
during query routing.
+of constrained routing tables and diverse routes, and the detection of faults
during query 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
@@ -1022,18 +1022,18 @@
Additionally, Lynch et al. \cite{lynch02atomicdataaccess} propose a solution
to 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 peer faulty. Thus, this
feature results in a low
+in their solution must have less than 1/3 of its peers faulty. Thus, this
feature results in a low
probability of successful routing.
Aspnes et al. in \cite{aspnes02faultrouting} and Kaashoek et al. in
\cite{kaashoek03koorde} formally
-prove the lower and upper bounds for space requirements of locating a specific
data item in
-Peer-to-Peer system. They show that to provide high degree of fault tolerance
and efficiency, each
+prove the lower and upper bounds for space requirements of locating a specific
data item 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 tightly structured overlay with analytical results in the presence of
hostile entities. However,
-none of these proposals address an efficient, dynamic tightly structured
overlay and multiple rounds
-of hostile attack. Also, above mentioned proposals are not very efficient. In
\cite{fiat02censorship}, each peer
+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
+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.
Finally, Ratnasamy and Gavoille \cite{ratnasamy02routing, gavoille01routing}
list several open problems
@@ -1045,8 +1045,8 @@
Ross Lee Graham lists several external threats against Peer-to-Peer networks
\cite{grahamp2psecurity}. Most important,
the list includes viruses and trojans. Currently, there are not even partial
solutions
-to the problems mentioned above. General robustness properties of Peer-to-Peer
system is able to
-deal with software failures and hostile attack, but fault tolerance against
external threats is unknown.
+to the problems mentioned above. General robustness properties of a
Peer-to-Peer system is able to
+deal with software failures and hostile attacks, but fault tolerance against
external threats is unknown.
The reason for this is that there are no experience on these kinds of attacks.
Possible solution
would be distributed anti-virus software, but much more intensive research is
required until
this kind of solution would be applicable.
@@ -1059,56 +1059,54 @@
\subsection{Efficient data lookup}
The most intensive research in Peer-to-Peer domain has been focused on
efficient data lookup methods,
-especially with the loosely structured approach. In addition to ''super-peer''
method presented in chapter
-2, there has been other improvements also.
-In iterative deepening
+especially with the loosely structured approach. In addition to the
''super-peer'' method presented in chapter
+2, there has been other improvements also. 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, query
-originator starts a data lookup with small TTL value. If the search is not
successful,
+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 maximum depth $D$
+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 iterative deepening technique. With these techniques, search
may not be fast when desired data item requires many consecutive flooding
rounds.
Directed BFS \cite{yang02improvingsearch} optimizes the original
-BFS in a way that peer selects neighbors with many quality results are reached
in the past,
+BFS in a way that a peer selects neighbors with many quality results are
reached in the past,
thereby maintaining the quality of costs and decreasing the amount
of messages sent to network. Alpine \cite{alpineurl} and NeuroGrid
\cite{joseph02neurogrid}
are Peer-to-Peer systems which use somewhat similar method when performing
data lookups.
-Local indices \cite{yang02improvingsearch} is one variation of active caching.
+Local indices \cite{yang02improvingsearch} is a variation of active caching.
In this scheme, each peer maintains an index over the data of all peers within
$h$ hops of itself, where $h$ is a system-wide variable, called radius of the
index\footnote{In normal BFS case, the value of $h$ is 0, as peer only has
index
over its local content.}. Mutual index caching architecture, as proposed in
\cite{osokine02distnetworks}, is one variation of local indices technique.
-In random walk approach \cite{lv02searchreplication}, peer forwards query to
-randomly selected neighbor. The basic random walk approach decreases the
-overhead generated by messages. On the other hand, basic random walk approach
-has poor response time. As suggested in \cite{lv02searchreplication},
+In random walk approach \cite{lv02searchreplication}, a peer forwards query to
a
+randomly selected neighbor. The basic random walk approach
+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 query lookups. Indeed, Freenet's query resembles
Depth-First-Search (DFS) and peers' routing tables are dynamically built
-using caching. This is an outcome of Freenet's main design principles,
-i.e., anonymity. Another property of Freenet's data lookup model is that
+using caching. This is an outcome of Freenet's main design principles,
anonymity.
+Another property of the Freenet's data lookup model is that
it adapts well with varying usage patterns. Improvements to Freenet's data
lookup using
-''small-world phenomenon'' has been proposed by Zhang et al.
\cite{zhang02using}.
+the ''small-world phenomenon'' has been proposed by Zhang et al.
\cite{zhang02using}.
-
-Since tightly structured systems have efficient data lookup at the application
level overlay,
-current research efforts are focused on proximity based data lookup. In
proximity based data lookup,
+Since tightly structured systems have an efficient data lookup at the
application level overlay,
+current research efforts are focused on a proximity based data lookup. In the
proximity based data lookup,
peers try to choose entries of routing-tables referring to other peers that
are \emph{nearby} in the
underlying network. In this way, tightly structured systems are able to
decrease actual
lookup \emph{latency}. CAN \cite{ratnasamy01can}, Kademlia
\cite{maymounkov02kademlia},
Pastry \cite{rowston01pastry} and Tapestry \cite{zhao01tapestry} have advanced
heuristics for
-proximity based routing. Additionally, most recent version of Chord uses
proximity based
+the proximity based routing. Additionally, most recent version of Chord uses
proximity based
routing inspired by Karger and Ruhl \cite{karger02findingnearest}. SkipNet
\cite{harvey03skipnet1}
uses a combination of proximity and application level overlay routing when
performing data
-lookups. Authors call this feature \emph{constrained load balancing}.
+lookups. Authors call this feature as a \emph{constrained load balancing}.
Additional research related to proximity based routing include
\cite{karger02findingnearest, hildrum02distributedobject,
brinkmann02compactplacement, rhea02probabilistic, castro02networkproximity,
ng02predicting, pias03lighthouse}.
@@ -1124,20 +1122,20 @@
fact that tightly structured algorithms perform data lookups based on a
globally unique identifier (key).
Recent study has been focused on the feasibility of Peer-to-Peer Web-like
indexing and searching
-\cite{li03feasibility} on top of tightly structured overlays. Authors argue,
that it is possible to implement
+on top of tightly structured overlays \cite{li03feasibility} . Authors argue,
that it is possible to implement
Peer-to-Peer Web-like search with certain compromises. First, Peer-to-Peer
search engine may need to
-decrease result quality in order to make searching more efficient. Second,
Peer-to-Peer systems must
+decrease the result quality in order to make searching more efficient. Second,
Peer-to-Peer systems must
observe the properties of underlying network for better performance.
Some studies have been concentrated on SQL-like queries \cite{harren02complex}
-in tightly structured overlays. Other approaches include adaption of data
lookup model of the loosely
+in tightly structured overlays. Other approaches include adaption of the data
lookup model of the loosely
structured approach into tightly structured systems
\cite{ansaryefficientbroadcast03, chord:om_p-meng}.
-Some studies include additional layer upon overlay network
\cite{kronfol02fasdsearch, joseph02p2players}
+Some studies suggest additional layer upon overlay network
\cite{kronfol02fasdsearch, joseph02p2players}
and range queries \cite{andrzejak02rangequeries}.
Many techniques have been developed in order to provide more efficient search
indexing. As
several studies show, the popularity of queries in the Internet follow
Zipf-like
-distributions\footnote{Zipf distribution is a variant of power-law function.
+distributions\footnote{Zipf-distribution is a variant of power-law function.
Zipf-distribution can be used in observation of frequency of occurrence event
$E$, as a function of the rank
$i$ when the rank is determined by the frequency of occurrence, $E_i \sim
\frac{1}{i^{a}}$, where the exponent
$a$ is close to unity.} (e.g., \cite{breslau98implications}). Therefore,
caching and pre-computation
@@ -1148,7 +1146,7 @@
and clustering with their search optimizations.
-While it is expected that web-like searches can be layered on top of tightly
structured overlay, much
+While it is expected that web-like searches can be layered on a top of tightly
structured overlay, much
more research is required to make indexing and searching more efficient.
@@ -1159,60 +1157,59 @@
systems require less system management properties than tightly structured
systems; in a loosely
structured system, peers join and leave the system constantly without any
restrictions. On the
other hand, however, peers in tightly structured system join and leave the
system but have less freedom,
-i.e. overlay chooses peer's neighbors on behalf of peer itself and maps data
items randomly
+i.e., overlay chooses peer's neighbors on behalf of the peer itself and maps
data items randomly
throughout the overlay network.
-Current research has been focused on system management of tightly structured
systems, and all presented
-algorithms of the tightly structured approach have been analyzed under static
simulation environments. Furthermore, proposed
-tightly structured overlays are configured statically to achieve the desired
reliability even in uncommon and adverse environment
-\cite{rowston03controlloingreliability}. The most important factor for
-future research is to get real-life experiences from tightly structured
systems, when there are frequent
-joins and leaves in the system. Some research has been done already in this
area.
+All presented algorithms of the tightly structured approach have been analyzed
under static simulation
+environments. Furthermore, proposed tightly structured overlays are configured
statically to achieve
+the desired reliability even in a uncommon and adverse environment
\cite{rowston03controlloingreliability}.
+The most important factor for future research is to get real-life experiences
from tightly structured
+systems, when there are frequent joins and leaves in the system. Some research
has been done already in this area.
-A concept of ''half-life'' was introduced by Liben-Nowell
\cite{libennowell01observations} as Peer-to-Peer
-system is \emph{never} in ''ideal'' state as it is continiously evolving
system. Half-life is defined
+A concept of ''half-life'' was introduced by Liben-Nowell
\cite{libennowell01observations} since Peer-to-Peer
+system is \emph{never} in the ''ideal'' state as it is continiously evolving
system. Half-life is defined
as follows: let there be $N$ live peers at time $t$. The doubling from time
$t$ is the time that pass before
$N$ new additional peers arrive into the system. The halving time from time
$t$ is the time
required for half of the living peers at time $t$ to leave the system. The
half-life from
time $t$ is smaller of the properties stated above. The half-life of the
entire system is the
minimum half-life over all times $t$. Concept of half-time can be used as a
basis for developing
-more efficient analytical tools for modeling complex Peer-to-Peer systems.
+more powerful analytical tools for modelling complex Peer-to-Peer systems.
Some research has been done with regard to load balancing properties of
tightly structured
-overlays. Byers et al. suggest "power of two choices" whereby data item is
stored at the less loaded
+overlays. Byers et al. suggest an idea of ''power of two choices'' whereby
data item is stored at the less loaded
of two (or more) random peer alternatives \cite{byers03dhtbalancing}. Rao et
al. use virtual servers
-to control load balance in Peer-to-Peer systems \cite{rao03loadbalancing}.
Their work rests on the
+to control the load balance in a Peer-to-Peer system
\cite{rao03loadbalancing}. Their work rests on the
idea which was originally introduced by Chord \cite{stoica01chord} system.
Also, query and routing hot spots may be an issue in tightly structured
overlays \cite{ratnasamy02routing}.
-Hot spots happen, when specific key is being requested extremely often in
tightly structured overlays. Recent study
+Hot spots happen, when a specific key is being requested extremely often in
tightly structured overlays. Recent study
by Freedman et al. tries to reduce hot spots in the system by performing
\emph{sloppy} hashing
\cite{sloppy:iptps03}. Another key feature of their work is that peers
self-organize into clusters,
therefore enabling peers to find nearby data without looking up data from
distant peers.
As mentioned before, an implicit assumption of almost every tightly structured
system is that there is a random, uniform
distribution of peer and key identifiers. Even if participating peers are
extremely heterogeneous, e.g., in
-face of computing power or network bandwidth, all data items are distributed
uniformly. Clearly, this is
+computing power or network bandwidth, all data items are distributed
uniformly. Clearly, this is
a serious problem of tightly structured overlays in face of performance and
load balancing. Measurement study
-by Saroiu et al. shows that there is extreme heterogeneity among participating
peers in already deployed Peer-to-Peer
+by Saroiu et al. show that there is a extreme heterogeneity among
participating peers in already deployed Peer-to-Peer
systems \cite{saroiu02measurementstudyp2p}. Symphony \cite{gurmeet03symphony}
seems to be the first tightly structured overlay system
which supports heterogeneity. Zhao et al. have proposed a secondary layer on
top of structured overlay
to support heterogeneity better \cite{zhao02brocade}.
Research has been done on self-organization. Ledlie et al. propose techniques
for forming and maintaining
-groups in highly dynamic environment \cite{ledlie02selfp2p}. Unfortunately
their work relies on idea that
+groups in highly dynamic environment \cite{ledlie02selfp2p}. Unfortunately
their work relies on the idea that
participating peers would create multiple hierarchical groups. It is not clear
whether this approach
-is fault-tolerant and suitable to Peer-to-Peer environment. More promising
work has been done by Rowston et al.
+is fault tolerant and suitable for a Peer-to-Peer environment. More promising
work has been done by Rowston et al.
in \cite{rowston03controlloingreliability}. Authors propose techniques for
self-tuning, dealing with
uncommon conditions (e.g., network partition and high failure rates).
Moreover, authors argue that
with these techniques, the concerns over tightly structured overlay
maintenance costs are no more
an open issue.
Finally, little research has been done regarding self-monitoring and data
availability. Zhang et al.
-describe an arbitrary data structure on top of tightly structured overlay
\cite{zhang03somo}. They
-call their proposal as \emph{data overlay}, since it supports several
fundamental data structures.
+describe an arbitrary data structure on top of a tightly structured overlay
\cite{zhang03somo}. They
+call their proposal as a \emph{data overlay}, since it supports several
fundamental data structures.
Authors use this data overlay to build Self-Organized Meta data Overlay
(SOMO), which can be used
-for monitoring health of tightly structured overlay. Fault tolerance of SOMO
itself is currently
+for monitoring the health of a tightly structured overlay. The fault tolerance
of SOMO itself is currently
unknown.
@@ -1234,11 +1231,12 @@
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 resources.
-However, these assumptions are not true as several studies show. Peers rather
consume than contribute and
-peers are unwilling to cooperate \cite{saroiu02measurementstudyp2p,
oram01harnessingpower, hearn02mojonation}.
+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
Peer-to-Peer
+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
@@ -1258,22 +1256,20 @@
and rapid change. Obviously, these factors exist also in Peer-to-Peer systems
even with higher
rates.
-As long as comprehensive simulations of Peer-to-Peer systems are lacking, we
cannot make any detailed
+As long as comprehensive simulations of a Peer-to-Peer systems are lacking, we
cannot make any detailed
analysis on general properties of Peer-to-Peer system such as usage patterns.
However, we can assume
-that, e.g., query keywords follow the Zipf-like distributions
\cite{breslau98implications} both in the
+that, e.g., query keywords follow the Zipf-like distribution
\cite{breslau98implications} both in the
Internet and in Peer-to-Peer systems.
\section{Summary}
-In this section we summarize open problems in Peer-to-Peer systems. All open
problem entries
+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. For each entry,
-there is a brief description of the problem, possible solutions and comments
respectively.
+here are variations of previously mentioned problems, or otherwise related to
them.
-Next, we list open problems in Peer-to-Peer domain. 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.
+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
@@ -1612,11 +1608,11 @@
The Fenfire project \cite{fenfireurl} is an effort to build a location
transparent, hyperstructured desktop
environment. Fenfire uses xanalogical storage model \cite{ted-xu-model} as a
basis for hyperstructured
media. Fenfire deploys innovative user interfaces for displaying data to the
end users. All data in the Fenfire
-is stored in a unified format, i.e., blocks. This should allow making
references between data easier and more
+is stored in a unified format, blocks. This should allow making references
between data easier and more
seamlessly interoperating than in other systems. For location transparency in
a distributed system, Fenfire
uses Peer-to-Peer network for locating and fetching blocks.
-Fenfire is free software and it is licensed under GNU LGPL. Fenfire was
formerly also a partial implementation
+Fenfire is a free software and it is licensed under GNU LGPL. Fenfire was
formerly also a partial implementation
of the ZigZag\texttrademark --structure, which was originally invented
by Ted Nelson. Now, however, Fenfire uses Resource Description Framework (RDF)
\cite{w3rdfurl}
for representing internal data structures and their relationships.
@@ -1624,49 +1620,49 @@
Fenfire is a high modular software system. It consists of several independent
software modules:
\begin{itemize}
-\item \textbf{Storm}: distributed storage module for storing arbitrary data
items
-\item \textbf{Navidoc}: UML based tool for generating software documentation
-\item \textbf{Alph}: xanalogical hypertext built upon Storm storage model
-\item \textbf{GLMosaicText}: flexible OpenGL interface for font manipulation
-\item \textbf{CallGL}: wrapping library used for OpenGL calls
-\item \textbf{LibVob}: graphic library used for creating navigation interfaces
in complex data views
+\item \textbf{Storm}: a distributed storage module for storing arbitrary data
items
+\item \textbf{Navidoc}: an UML based tool for generating software
documentation
+\item \textbf{Alph}: a xanalogical hypertext built upon Storm storage model
+\item \textbf{GLMosaicText}: a flexible OpenGL interface for font manipulation
+\item \textbf{CallGL}: a wrapping library used for OpenGL calls
+\item \textbf{LibVob}: a graphic library used for creating navigation
interfaces in complex data views
\end{itemize}
In this thesis, we focus on Storm and Alph modules, since they are the
foundation of Fenfire's
Peer-to-Peer functionality. If not otherwise mentioned, we use term 'Storm'
when referring to both
Storm and Alph software modules. For location transparency in the Fenfire
system, Storm software module
-must have support for Peer-to-Peer functionality as it provides low-level data
storage operations
+must have a support for Peer-to-Peer functionality as it provides low-level
data storage operations
in the Fenfire system.
\section{Xanalogical storage model}
-Xanalogical storage \cite{nelson99xanalogicalneeded} is a different kind of
model for
-presenting data and relationships between data. While in World Wide Web links
are
-between \emph{documents}, in xanalogical model links are between individual
+Xanalogical storage model \cite{nelson99xanalogicalneeded} is a different kind
of model for
+presenting data and relationships between data. While in the World Wide Web
links are
+between \emph{documents}, in xanalogical storage model links are between
individual
\emph{characters}. Each character in xanalogical storage model has a
permanent, globally unique identifier. For instance, let's consider the
following
scenario: ''the character 'D' typed by Janne Kujala on 10/8/97 8:37:18''. In
this
example, when character 'D' is first typed in, xanalogical storage model
acquires a permanent identifier for that character and retains it when
character
-is copied to different document. Thus, the identifier distinguishes character
from
+is copied to different document. Thus, the identifier distinguishes the
character from
all similar characters typed in independently\footnote{Xanalogical storage
model
is not limited to text. It can support arbitrary data, e.g., pixels of picture
or
-frames of video.}. The connectivity in xanalogical storage model between data
content
+frames of video.}. The connectivity in the xanalogical storage model between
data content
is more substantial than in other models; a link is shown between any two data
contents
containing a specific \emph{fluid media unit} (e.g., a character) that the
link connects.
In practice, however, xanalogical storage model uses \emph{spans}, ranges of
consecutive
fluid media units to perform storage operations. This is done for better
performance as
doing expensive operations for every fluid media unit is not efficient. As a
implication,
-xanalogical storage model stores fluid media units to append-only
\emph{scrolls}.
+the xanalogical storage model stores fluid media units to append-only
\emph{scrolls}.
\emph{Enfilade} can be considered as a ''virtual file'' (or part of one),
which is a list
-of fluid media contents. In xanalogical storage model, links between content
are external
-and bidirectional. Xanadu link is an \emph{association} of two enfilades, such
as an
+of fluid media content. In the xanalogical storage model, links between
content are external
+and bidirectional. Xanalogical link is an \emph{association} of two enfilades,
such as an
annotation to a specific part of a another document. \emph{Transclusion} is an
inclusion in
enfilade of contents already used in another enfilade, i.e., current fluid
media is copied into
-different data contents. By using this mechanism, a system implementing
xanalogical storage model
-is able to show all data content that share same fluid media with current data
content
+different data contents. By using this mechanism, a system implementing the
xanalogical storage model
+is able to show all data content that share the same fluid media with current
data content
(e.g., all documents containing current document's text). Figure
\ref{fig:xanalogical_model}
illustrates xanalogical storage model with documents, text and characters.
@@ -1693,8 +1689,8 @@
for creating location-independent, globally unique identifiers for blocks.
Additionally,
SHA-1 \cite{fips-sha-1} is used for verifying the integrity of Storm data
blocks. Storm
blocks have much in common with regular files, except that Storm blocks are
\emph{immutable} as
-any change to the byte sequence would change block's hash value, i.e.,
globally unique
-identifier. This mechanism creates a basis for implementing xanalogical
storage model in
+any change to the byte sequence would change block's hash value (globally
unique
+identifier). This mechanism creates a basis for implementing xanalogical
storage model in
in Fenfire system. Figure \ref{fig:storm_model} illustrates simplified Storm
storage model.
\begin{figure}
@@ -1710,13 +1706,13 @@
we discuss only pointers as they are part of the thesis' research problems.
More information about diffs can be found from \cite{fallenstein03storm}.
-Pointer \cite{benja02urn5} is a semantic-free, updatable reference to
-Storm data block, i.e., Storm scroll block.
+Pointer \cite{benja02urn5} is a semantic-free updatable reference to
+Storm data block, named as Storm scroll block.
In practice, pointer is a random string, which resembles Universal Resource
Names
(URN) \cite{rfc2396}. Pointer itself doesn't contain any data, it is rather a
\emph{concept} of
data. Pointers are created automatically by Storm and each pointer is
associated with a collection of \emph{pointer blocks}. Pointer block has a
single
-target for the pointer. In figure \ref{fig:storm_model}, we present overall
+target for the pointer. In figure \ref{fig:storm_model}, we present the
overall
pointer creation process. Pointer block may contain zero or more obsoleted
pointer blocks, i.e., when a new version of scroll block is created, it
supersedes
one older version which has been created in the past. The most current pointer
@@ -1734,47 +1730,47 @@
\chapter{Evaluation of Peer-to-Peer for Fenfire}
-In this chapter we evaluate Fenfire in Peer-to-Peer environment.
-We start by giving a problem overview when considering Fenfire in Peer-to-Peer
+In this chapter we evaluate Fenfire in a Peer-to-Peer environment.
+We start by giving a problem overview when considering Fenfire in a
Peer-to-Peer
environment. We define Fenfire's special needs and evaluate existing
Peer-to-Peer approaches in light of these requirements. After that, we propose
a system
-model for Fenfire in Peer-to-Peer environment and present simple methods to
perform data
-lookups in Peer-to-Peer environment. In the end of this chapter, we discuss
possible problems of using Fenfire
-in Peer-to-Peer environment.
+model for Fenfire and present simple methods to perform data
+lookups in a Peer-to-Peer environment. In the end of this chapter, we discuss
possible problems of using Fenfire
+in a Peer-to-Peer environment.
\section{Problem overview}
-As already mentioned in chapter 4, xanalogical document is a ''virtual
+As already mentioned in chapter 4, a xanalogical document is a ''virtual
file'', in which parts of the document are fetched from a
-\emph{global} data repository. Thus, system implementing xanalogical model
\emph{must}
-support global data lookups efficiently in order to assemble a ''virtual file''
+\emph{global} data repository. Thus, system implementing the xanalogical
storage model \emph{must}
+support global data lookups efficiently in order to assemble the ''virtual
file''
from fragments of data.
In the xanalogical storage model, each fragment of data is identified by a
globally
-unique identifier. In the Fenfire system, data fragments are scroll blocks,
generated by Storm storage module.
+unique identifier. In the Fenfire system, data fragments are scroll blocks
generated by Storm storage module.
As we discussed already in chapter 4, Fenfire's Storm design
uses SHA-1 \cite{fips-sha-1} hash over the contents of a scroll block for
creating globally unique
identifiers for each scroll block. In our scenario, fragments of data is
distributed
throughout the Peer-to-Peer overlay. We want that user operations in Fenfire
are location transparent.
Therefore, our task is to locate and fetch (i.e. obtain) \emph{all} Storm
scroll blocks, associated to a specific ''virtual
-file'', from Peer-to-Peer overlay as efficiently as possible. In addition to
+file'' from the Peer-to-Peer overlay as efficiently as possible. In addition
to the
\emph{direct} scroll block obtaining using globally unique identifier of Storm
scroll block,
-we also must support \emph{indirect} obtaining of Storm scroll block using
pointer blocks.
+we also must support the \emph{indirect} obtaining of Storm scroll block using
pointer blocks.
-Obviously, our objectives are yet simple but hard to fulfill. First, as a
prerequisite
-to implementing xanalogical storage model in Peer-to-Peer environment, system
+Obviously, our objectives are simple but yet hard to fulfill. First, as a
prerequisite
+to implementing xanalogical storage model in a Peer-to-Peer environment, a
system
supporting data lookups must be able to perform \emph{global} scale lookups.
Thus,
-we must be able to locate and fetch Storm scroll/pointer block, if it exists
in the
+we must be able to locate and fetch Storm block, if it exists in the
Peer-to-Peer overlay. Second, data lookups have to be efficient, since
constructing
one ''virtual file'' may need obtaining several Storm blocks, which are
distributed
-randomly throughout the overlay; if not efficient, construction of ''virtual
file''
+randomly throughout the overlay; if not efficient, construction of the
''virtual file''
may take reasonable amount of time while rendering system very unusable.
Third, Peer-to-Peer
infrastructure has to be scalable and robust against hostile attacks.
Some research regarding to these problem has been made by Lukka et al.
-\cite{lukka02freenetguids}. Authors' work is mainly based on insight of
implementing
-xanalogical model in Peer-to-Peer environment with globally unique
identifiers. Lukka et al.
+\cite{lukka02freenetguids}. Authors' work is mainly based on the insight of
implementing the
+xanalogical storage model in a Peer-to-Peer environment with globally unique
identifiers. Lukka et al.
use Freenet \cite{clarke00freenet} as an example Peer-to-Peer system
supporting
globally unique identifiers. The work presented in this thesis extends their
work by
evaluating different Peer-to-Peer systems more extensively to Fenfire's needs.
@@ -1796,7 +1792,7 @@
data lookup model of tightly structured overlay scales much better than
loosely
structured overlays; tightly structured overlay supports global data lookups
in the overlay, whereas the data lookup model of the loosely structured
approach
-is limited to certain area of overlay\footnote{The area depends on where the
query
+is limited to certain area of the overlay\footnote{The area depends on where
the query
originator is located in the overlay.}.
For Fenfire's special needs for \emph{locating} data, an important advantage
of the
@@ -1806,38 +1802,38 @@
feature is almost analogical to Fenfire's (and xanalogical storage model's)
way of
handling data. Another key feature of tightly structured overlays is that they
are able
to provide general purpose \emph{interface} for Reference Resolution Services
(RRS)\footnote{
-Domain Name System (DNS) \cite{rfc1101} is widely used RRS system in the
Internet.}
+Domain Name System (DNS) \cite{rfc1101} is a widely used RRS system in the
Internet.}
\cite{balakrishnan03semanticfree}. Authors argue that next generation RRS
must be
application-independent and references itself should be \emph{unstructured}
and
\emph{semantically free}. Finally, as said, with tightly structured systems,
it is feasible to
perform \emph{global} data lookups in the overlay. To summarize, these aspects
may be the most important features
of Peer-to-Peer infrastructure with regard to Fenfire as a distributed,
location transparent hypermedia system.
-Thus, we see the tightly structured approach as 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 a Peer-to-Peer
environment.
-Once located, for \emph{fetching} Storm blocks from the overlay, we can use
regular
-TCP/IP-protocols, such as Hypertext Transfer protocol (HTTP) \cite{rfc2068}.
However, HTTP-protocol may
-not be optimal when obtaining large amounts of data from the Peer-to-Peer
network (e.g.,
+Once located, we can use regular TCP/IP-protocols, such as Hypertext Transfer
protocol (HTTP)
+\cite{rfc2068} for \emph{fetching} Storm blocks from the overlay. However,
HTTP-protocol may
+not be optimal when obtaining large amounts of data from a Peer-to-Peer
network (e.g.,
videos, images or music). In this case, multisource downloads can be very
useful
for better efficiency \cite{maymounkov03ratelesscodes, bittorrenturl}.
Furthermore,
-multisource downloads can be used for decreasing load of certain peer, thus
avoiding query
+multisource downloads can be used for decreasing load of a certain peer, thus
avoiding query
hot spots in the system \cite{ratnasamy02routing}. Current implementation of
Fenfire uses
standard single source downloads (HTTP) and SHA-1 \cite{fips-sha-1}
cryptographic content
hash for verifying the integrity of data by recomputing the content hash
for a scroll block. In face of multisource downloads, Fenfire must support
-tree-based hash\footnote{With multisource downloads, tree based hash functions
can be used
+tree-based hashes\footnote{With multisource downloads, tree based hash
functions can be used
to verify fixed length segments of data. If hash value of data segment is
incorrect,
-we need only to fetch \emph{segment} of data (instead of whole data, e.g., a
file) from
-other source.}, such as \cite{merkle87hashtree, mohr02thex} for reliable and
efficient
+we need only to fetch \emph{segment} of data (instead of whole data) from
+an other source.}, such as \cite{merkle87hashtree, mohr02thex} for reliable
and efficient
data validation.
Again, there are research challenges with tightly structured systems which
have to be
addressed, as described in chapter 3. The main concerns include decreased
performance and fault
-tolerance when system in presence of system flux, non-optimal distance
functions in identifier space,
+tolerance in presence of system flux, non-optimal distance functions in
identifier space,
proximity routing, hostile entities and flexible search
\cite{balakrishanarticle03lookupp2p}.
Additionally, there is only little real world experiments yet with tightly
structured systems
(e.g., \cite{overneturl, edonkey2kurl}). Therefore, we can't say for sure, how
well these
-systems would perform in real Peer-to-Peer environment. However, we believe
that issues are
+systems would perform in real Peer-to-Peer environment. However, we believe
that these issues are
solved, since there is a strong and wide research community towards to tightly
structured
overlays \cite{projectirisurl}.
@@ -1845,15 +1841,15 @@
\section{Fenfire system model in Peer-to-Peer environment}
In this section we give a proposal for Fenfire Peer-to-Peer system, which
consists
-of several technologies reviewed in this thesis. Then, we introduce yet
simple but
-effective methods for obtaining Fenfire data from Peer-to-Peer environment.
+of several technologies reviewed in this thesis. Then, we introduce simple
but
+yet effective methods for obtaining Fenfire data from a Peer-to-Peer
environment.
\subsection{System proposal}
Currently, we see Kademlia \cite{maymounkov02kademlia} as the best algorithm
for
-locating data efficiently in the Peer-to-Peer overlay. There are two main
+locating data efficiently in the Peer-to-Peer overlay. There are two
reasons for this. First, Kademlia's XOR-based distance function is superior
-over the distance functions of other systems (see section 2.4). Second, there
exist already
+over distance functions of other systems (see section 2.4). Second, there
exist already
deployed real-life systems using Kademlia (e.g., \cite{overneturl,
edonkey2kurl, kashmirurl,
kato02gisp}), which means that Kademlia's algorithm is simple and easy to
implement.
@@ -1871,35 +1867,35 @@
as sudden network partition, or highly dynamic and heterogeneous environment.
Finally, for more efficient data transfer, we can use variable techniques for
this purpose.
-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 amounts of
data, we can use
multisource downloads for better efficiency and reliability. Specifically,
technology based
on rateless erasure codes \cite{maymounkov03ratelesscodes} seems very
promising.
\subsection{Methods}
We use the DOLR abstraction of the tightly structured approach, i.e., each
participating peer hosts
-the data and overlay maintains only the \emph{pointers} to the data. We
decided to use the DOLR
+the data and the overlay maintains only the \emph{pointers} to the data. We
decided to use the DOLR
abstraction in our model, since DOLR systems locate data without specifying a
storage policy explicitly \cite{rhea03benchmarks}.
DHT based storage systems, such as CFS \cite{dabek01widearea} and PAST
\cite{rowstron01storage}, may have
-critical problems with load balancing in highly heterogeneous environment.
This problem is caused by peers
-which may not be able to store relatively large amount of data with key/value
pair, assigned randomly by
-mapping function of the overlay. These systems waste both storage and
bandwidth, and
+critical problems with load balancing in a highly heterogeneous environment.
This problem is caused by peers
+which may not be able to store relatively large amount of data with key-value
pair, assigned randomly by
+the mapping function of the overlay. These systems waste both storage and
bandwidth, and
are sensitive to certain attacks (e.g., DDoS attack). Additionally, we
emphasize that we prefer \emph{abstraction}
level analysis as very recently better and better tightly structured
algorithms have been proposed.
Thus, we don't want to bind our system proposal to a specific algorithm
definitively as we expect
that this development continues.
In the following subsections we assume that we know the structure of
-''virtual file'' before hand, i.e., when assembling a ''virtual file'', we
know all Storm
-scroll/pointer blocks, which are required when building the ''virtual file''.
Also, we don't
+the ''virtual file'' before hand, i.e., when assembling the ''virtual file'',
we know all Storm
+blocks, which are required when building the ''virtual file''. Also, we don't
respond to security issues related to Peer-to-Peer systems, since there is no
working solution
available yet; we either assume that Fenfire has a reliable technique for
identifying individual entities, or
there are no hostile entities among participating peers.
-In our model, each peer maintains following data structures for local
operations: data structure for listing all
-key/value-pairs which peer maintains; data structure for listing all
key/value-pair in
+In our model, each peer maintains following data structures for local
operations: a data structure for listing all
+key-value pairs which peer maintains; a data structure for listing all
key-value pairs in the
chronological order (the most recent block is topmost) which peer maintains.
We use Storm blocks' identifiers
-as \emph{keys} of the overlay. Every key/value-pairs consists of either a hash
of pointer random string
+as \emph{keys} of the overlay. Every key-value pair consists of either a hash
of pointer random string
(pointer blocks), or a hash of block's content (scroll blocks) as a key. Value
is always a reference to a hosting
peer (e.g., IP address). We use Kademlia's \cite{maymounkov02kademlia}
algorithm for locating data in the overlay.
Finally, we assume that all local operations can be done in a constant time.
@@ -1909,39 +1905,39 @@
\item Data lookup with a given identifier of Storm scroll block.
\begin{enumerate}
\item Submit data lookup using scroll block's identifier.
-\item Repeat until hosting peer is found: each peer forwards the data lookup
to a closer peer which hosts the given scroll block identifier.
-\item Pointer peer returns value (e.g., the IP address of provider peer) to
query originator.
-\item Query originator requests provider peer to return the scroll block.
+\item Repeat until the pointer peer is found: each peer forwards the data
lookup to a closer peer which hosts the given scroll block identifier.
+\item The pointer peer returns value (e.g., the IP address of provider peer)
to the query originator.
+\item The query originator requests the provider peer to return the scroll
block.
\end{enumerate}
\end{itemize}
-Figure \ref{fig:storm_query_blockid} illustrates how Storm scroll block is
located
-in tightly structured overlay using the DOLR abstraction, where identifier of
Storm scroll
+Figure \ref{fig:storm_query_blockid} illustrates how a Storm scroll block is
located
+in tightly structured overlay using the DOLR abstraction, where the identifier
of Storm scroll
block is known.
\begin{itemize}
\item Data lookup with a given pointer random string returning most recent
scroll block.
\begin{enumerate}
-\item Query originator locally computes a hash for given 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.
-\item Pointer peer returns most recent pointer block's key/value-pair (e.g.,
the IP address of provider peer) to query originator, using pointer block's own
indexing schemes.
-\item Query originator requests provider peer to return the scroll block.
+\item The query originator locally computes a hash for given pointer random
string.
+\item Repeat until the pointer peer is found: each peer forwards the data
lookup to a closer peer which hosts the given hash of pointer random string.
+\item The pointer peer returns most recent pointer block's key-value pair
(e.g., the IP address of provider peer) to the query originator, using pointer
block's own indexing schemes.
+\item The query originator requests the provider peer to return the scroll
block.
\end{enumerate}
\end{itemize}
\begin{itemize}
-\item Data lookup with a given pointer random string returning scroll block(s)
for a given date and/or time range.
+\item Data lookup with a given pointer random string returning scroll block(s)
for a given date or time range.
\begin{enumerate}
-\item Query originator locally computes a hash for given 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.
-\item Pointer peer returns pointer block's key/value-pair(s) (e.g., the IP
address of provider peer) to query originator, using pointer block's own
indexing schemes.
-\item Query originator requests provider peer to return the scroll block.
+\item The query originator locally computes a hash for given pointer random
string.
+\item Repeat until the pointer peer is found: each peer forwards the data
lookup to a closer peer which hosts the given hash of pointer random string.
+\item Pointer peer returns pointer block's key-value pair(s) (e.g., the IP
address of provider peer) to the query originator, using pointer block's own
indexing schemes.
+\item The query originator requests the provider peer to return the scroll
block.
\end{enumerate}
\end{itemize}
Figure \ref{fig:storm_query_urn5} illustrates how Storm scroll block is
located
-in tightly structured overlay using the DOLR abstraction, where pointer random
string is known.
+in tightly structured overlay using the DOLR abstraction, where the pointer
random string is known.
Each of these algorithms can locate Fenfire data in $O(\log{n})$ time at
application level overlay:
$O(\log{n})$ time for query routing to pointer peer and constant time for
@@ -1968,15 +1964,15 @@
Perhaps the most biggest issue in Peer-to-Peer systems is non-maturity of
security technologies. For instance, online entities cannot be identified
safely (e.g., the Sybil attack \cite{douceur02sybil}). For Fenfire, one
-security related problem occurs when user wants to perform global data lookup
with a given
-pointer random string; how can the user verify the correctness
+security related problem occurs when user wants to perform a global data
lookup with a given
+pointer random string; how can a user verify the correctness
of the search results ? Specifically, how she or he knows which one is the
-correct Storm scroll block ? Spam attack \cite{naor03simpledht} is a variation
of previously
+correct Storm scroll block ? The Spam attack \cite{naor03simpledht} is a
variation of previously
mentioned problem; data lookup is performed by a user, but there is no reply
from the system. How are we able to know if this was a spam attack, or the
data really doesn't exist in the system ? Another problem related to the
Fenfire's
security is that if a user downloads data from the network to local computer
-and after network disconnection, user wants to verify \emph{off line} the
+and after a network disconnection, user wants to verify \emph{off line} the
authenticity of data. Obviously, optimal solution to all security issues would
be that digital signatures are included to every message sent to the system
therefore
enabling peers to authenticate other peers safely. However, these problems are
not
@@ -1989,40 +1985,39 @@
In this thesis, we have reviewed existing Peer-to-Peer approaches, algorithms
and
their properties. We have summarized open problems in Peer-to-Peer research
domain.
-Specifically, we divided open problems into three sub-categories: security
related problems,
+Specifically, we divided open problems into the three sub-categories: security
related problems,
performance related problems and miscellaneous problems. Each of these
sub-categories have number of open problems, in which there are no solutions
yet, or solutions are only partial. We point out that much research work is
required to
solve these problems.
Then, we focused our attention to the Fenfire system. First, we gave a brief
-overview of Fenfire and xanalogical model. We also described Storm software
module.
+overview of Fenfire and xanalogical storage model. We also described Storm
software module.
In the last chapter, we evaluated existing Peer-to-Peer approaches with regard
to Fenfire's needs. We proposed that the tightly structured approach is the
best alternative to Fenfire's needs for the following reasons. First, Storm,
xanalogical
-model and tightly structured systems use global unique identifiers
+storage model and tightly structured systems use global unique identifiers
for identifying data. Second, our Storm design uses \emph{semantic-free
references}
-(block identifiers, pointer random strings) for locating data in distributed
-networks generated by SHA-1 cryptographic content
-hash \cite{fips-sha-1}. As the authors of \cite{balakrishnan03semanticfree},
-we also agree that tightly structured overlays provide general purpose
-interface to next-generation reference resolution services. Third, by using
+(block identifiers and pointer random strings) for locating data in
distributed
+networks. As the authors of \cite{balakrishnan03semanticfree},
+we also agree that references should be semantically-free in the
next-generation
+reference resolution services. Third, by using
the DOLR abstraction of tightly structured overlay, we can minimize the lack
of locality in the tightly structured approach. Finally, we believe that
issues
-related to tightly structured overlays are solved in near future, because of
+related to tightly structured overlays are solved in the near future, because
of
wide and intensive co-operation among research groups.
-Then, we proposed system model for Fenfire in Peer-to-Peer environment and
-presented simple methods to perform data lookups in Peer-to-Peer environment.
+Then, we proposed system model for Fenfire and presented simple methods to
perform data
+lookups in a Peer-to-Peer environment.
Our future work includes support for searching transclusions and xanalogical
links in a Peer-to-Peer network. Specifically, we want to find transclusions
-and xanalogical links in a global scale. Preliminary analysis have showed
+and xanalogical links in a global scale. Preliminary analysis have shown
that these questions are rather different than locating scroll or pointer
blocks \emph{directly} from the network. Techniques used in distributed
database systems may prove to be useful. Some fundamental results
-regarding Peer-to-Peer and database systems has already been
+regarding Peer-to-Peer and database systems have already been
presented in \cite{gribble01p2pdatabase}.
In the following months, we will implement a Fenfire Peer-to-Peer prototype.
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., (continued)
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/13
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/13
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/14
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/14
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/14
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/17
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/17
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/17
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/17
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/17
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert...,
Hermanni Hyytiälä <=
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/18
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/19
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/19
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/19
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/20
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/20
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/20
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/20
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/20
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/20