[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: |
Wed, 12 Mar 2003 08:41:17 -0500 |
CVSROOT: /cvsroot/gzz
Module name: gzz
Changes by: Hermanni Hyytiälä <address@hidden> 03/03/12 08:41:17
Modified files:
Documentation/misc/hemppah-progradu: masterthesis.tex
Log message:
More fixes
CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/Documentation/misc/hemppah-progradu/masterthesis.tex.diff?tr1=1.131&tr2=1.132&r1=text&r2=text
Patches:
Index: gzz/Documentation/misc/hemppah-progradu/masterthesis.tex
diff -u gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.131
gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.132
--- gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.131 Wed Mar
12 07:57:42 2003
+++ gzz/Documentation/misc/hemppah-progradu/masterthesis.tex Wed Mar 12
08:41:17 2003
@@ -1363,7 +1363,7 @@
\parbox{90pt}{Sybil attack \cite{douceur02sybil},
\cite{castro02securerouting}} &
-\parbox{110pt}{Single hostile entity present multiple entities} &
+\parbox{110pt}{Single hostile entity presents multiple entities} &
\parbox{110pt}{Identify all nodes simultaneously across the system, collect
pool of nodes which are validated, distributed node ID creation} &
\parbox{110pt}{Not practically realizable, research focused on persistence,
not on identity distinction}
\\ \hline
@@ -1397,7 +1397,7 @@
\\ \hline
-\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}} &
\parbox{110pt}{Anonymity cannot be provided in all cases} &
\parbox{110pt}{Remailers, pre-routing} &
\parbox{110pt}{Total anonymity cannot be provided yet}
@@ -1427,13 +1427,13 @@
\parbox{90pt}{Hostile groups \cite{castro02securerouting}} &
\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}{Use trusted nodes, based on history information, Cryptography,
key infrastructure} &
+\parbox{110pt}{Use trusted nodes, 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} &
-\parbox{110pt}{Viruses, Trojan, sniffers} &
+\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
@@ -1476,7 +1476,7 @@
\\ \hline
-\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}} &
\parbox{110pt}{Find resources efficiently, if resource exists (loosely
structured)} &
\parbox{110pt}{Super nodes, node clusters, caching techniques} &
\parbox{110pt}{More efficient, less network traffic, not comparable to DHT's
efficiency}
@@ -1498,7 +1498,7 @@
\parbox{90pt}{Quality of Service} &
-\parbox{110pt}{The system can only provide (at most) best effort services)} &
+\parbox{110pt}{The system can only provide (at most) best effort services} &
\parbox{110pt}{Use network proximity for better network performance
(bandwidth, latency, jitter, packet loss)} &
\parbox{110pt}{Increases system complexity, some initial experiences, need
more research}
\\ \hline
@@ -1512,8 +1512,8 @@
\parbox{90pt}{Network proximity \cite{pias03lighthouse},
\cite{ng02predicting}, \cite{ratnasamy02ght}, \cite{eriksson03peernet},
\cite{castro02networkproximity}} &
-\parbox{110pt}{Can we take account the underlying network's properties better
when forming overlay network (network-awareness for performance) ?} &
-\parbox{110pt}{Global Network Positioning, Lighthouse technique, triangulated
heuristics} &
+\parbox{110pt}{Can we take into account the underlying network's properties
better when forming overlay network (network-awareness for performance) ?} &
+\parbox{110pt}{Global network positioning, lighthouse technique, triangulated
heuristics} &
\parbox{110pt}{Increases system complexity, no real world experience in a wide
scale, proposed solutions are susceptible to single point of failure}
\\ \hline
@@ -1528,12 +1528,12 @@
\parbox{90pt}{Hot spots \cite{258660}, \cite{sloppy:iptps03},
\cite{maymounkov03ratelesscodes}} &
\parbox{110pt}{What will happen if some resource is extremely popular and only
one node is hosting it ?} &
\parbox{110pt}{Caching, multi source downloads, replication, load balancing,
sloppy hashing} &
-\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}
\\ \hline
\parbox{90pt}{Load balancing \cite{rao03loadbalancing},
\cite{ledlie02selfp2p}, \cite{byers03dhtbalancing}} &
-\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} &
\parbox{110pt}{Caching, virtual server transfers} &
\parbox{110pt}{Effective, more research required in fully dynamic environment}
\\ \hline
@@ -1546,21 +1546,21 @@
\parbox{90pt}{Sudden network partition \cite{harvey03skipnet1},
\cite{harvey03skipnet2}, \cite{rowston03controlloingreliability}} &
\parbox{110pt}{Sub network is isolated from other network because of network
disconnection} &
-\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)} &
\parbox{110pt}{Creates more overhead/space requirements per node}
\\ \hline
\parbox{90pt}{Fail Stop} &
\parbox{110pt}{A faulty node stops working} &
\parbox{110pt}{Failure detectors, informing algorithms} &
-\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}
\\ \hline
\parbox{90pt}{Byzantine faults \cite{296824}} &
\parbox{110pt}{Faulty nodes may behave arbitrarily} &
-\parbox{110pt}{Byzantine replication algorithms -> get information from
multiple entities, trust majority's opinion} &
-\parbox{110pt}{Much research has been done on this field, practical solutions,
decreases the performance of system slightly}
+\parbox{110pt}{Byzantine replication algorithms, get information from multiple
entities, trust majority's opinion} &
+\parbox{110pt}{Much research has been done on this field, practical solutions,
decreases system performance slightly}
\\ \hline
\caption{Performance and usability problems in Peer-to-Peer.}
@@ -1595,7 +1595,7 @@
\endfoot
-\parbox{90pt}{Mutual distrust, \cite{cornelli02reputableservents},
\cite{aberer01trust}} &
+\parbox{90pt}{Mutual distrust \cite{cornelli02reputableservents},
\cite{aberer01trust}} &
\parbox{110pt}{Nobody trusts anybody} &
\parbox{110pt}{Reputation methods, key infrastructures} &
\parbox{110pt}{Resource demanding, not practical to implement/not working
solutions, no real world experience in a wide scale}
@@ -1624,7 +1624,7 @@
\parbox{90pt}{Comprehensive simulations/analysis of Peer-to-Peer network} &
-\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.} &
\parbox{110pt}{Use same techniques as simulating/analyzing the Internet} &
\parbox{110pt}{Only small subsets of Peer-to-Peer networks has been analysed,
because of ad hoc properties of network, more powerful solutions needed}
\\ \hline
@@ -1633,13 +1633,14 @@
\parbox{90pt}{Overlay management and health monitoring \cite{zhang03somo}} &
\parbox{110pt}{System is self-capable to monitor it's status and health for
better performance} &
\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}{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}
\\ \hline
\parbox{90pt}{Locating Peer-to-Peer network} &
\parbox{110pt}{How old peers or new peers are able to locate Peer-to-Peer
network, if it exists} &
\parbox{110pt}{Servers maintaining online peers (e.g. gnutellahosts.com),
peer's history information} &
-\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
+networks (MANETs) can be only connected through radio resource interface,
i.e., peers which are in same geographical area)}
\\ \hline
\caption{Miscellaneous problems in Peer-to-Peer.}
@@ -1688,7 +1689,7 @@
\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 is first typed in, xanalogical storage model
+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
all similar characters typed in independently\footnote{Xanalogical storage
model
@@ -1728,13 +1729,13 @@
Storm (for \emph{STORage Module}) is a software module, which is used in
Fenfire for
data storage operations. Storm stores all data as \emph{blocks}, which
-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
hash function. Therefore, it is very unlikely that two different Storm data
blocks
would have same identifier.} cryptographic content hash \cite{fips-sha-1} is
used
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 Storm blocks are
\emph{immutable} as
-any change to the byte sequence would the change block's hash value, i.e.,
unique
+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., unique
identifier. This mechanism creates a basis for implementing xanalogical model
in
Fenfire system. Figure \ref{fig:storm_model} illustrates simplified Storm
storage model.
@@ -1805,23 +1806,23 @@
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
supporting data lookups must be able to perform \emph{global} scale lookups.
Thus,
-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
Peer-to-Peer overlay. Second, data lookups have to be efficient, since
constructing
one ''virtual file'' may need obtaining several data items, which are
distributed
randomly throughout the overlay; if not efficient, construction of ''virtual
file''
-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
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.
-use Freenet \cite{clarke00freenet} as a example Peer-to-Peer system supporting
+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.
Additionally, related to non-xanalogical hypermedia systems, Bouving
\cite{bouvin02openhypermedia} has done initial work regarding ways in which
-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
\cite{thompson01hypermedia} have studied locating documents and links in
Peer-to-Peer
environment. At the Hypertext '02 panel, moderated by Wiil
\cite{wiil02p2phypertext},
participants responded whether Peer-to-Peer systems are suitable for hypermedia
@@ -1832,7 +1833,7 @@
In chapter 2, we discussed main differences between loosely and tightly
structured
approaches. As stated, the most significant difference is that tightly
structured
approach has logarithmical properties in all internal operations, while
loosely
-structured approach doesn't have always even linear properties. Furthermore,
the
+structured approach doesn't always have even linear properties. Furthermore,
the
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 loosely structured approach
@@ -1852,7 +1853,7 @@
\emph{semantic 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 \emph{distributed}
hypermedia system.
-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
environment.
Once located, for \emph{fetching} Fenfire related data from the overlay, we
can use regular
@@ -1873,7 +1874,7 @@
Again, there are open issues 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 flux-state, non-optimal distance functions in
identifier space,
+tolerance when system 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}, \cite{edonkey2kurl}). Therefore, we can't say for
sure, how well these
@@ -1884,8 +1885,8 @@
\section{Fenfire system model in Peer-to-Peer environment}
-In this section present a proposal of Fenfire Peer-to-Peer system, which
consists
-of several technologies presented in this thesis. Then, we introduce yet
simple but
+In this section we give a proposal of Fenfire Peer-to-Peer system, which
consists
+of several technologies reviewed in this thesis. Then, we introduce yet
simple but
effective algorithms for obtaining Fenfire data from Peer-to-Peer environment.
\subsection{System proposal}
@@ -1898,8 +1899,8 @@
\cite{kato02gisp}), which means that Kademlia's algorithm is simple and easy
to implement.
On top of Kademlia, we propose the usage of Sloppy hashing
\cite{sloppy:iptps03} which
-optimized for DOLR abstraction of tightly structured overlays. With Sloppy
hashing,
-we are able reduce of generation of query hot spots. Sloppy hashing enables to
+is optimized for DOLR abstraction of tightly structured overlays. With Sloppy
hashing,
+we are able to reduce the generation of query hot spots. Sloppy hashing
enables to
locate nearby data without looking up data from distant nodes. Moreover,
authors'
proposal for self-organizing clusters using network diameters may be useful,
especially within small groups of working people. Thus, with Sloppy hashing
@@ -1913,16 +1914,16 @@
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
multi source downloads for better efficiency and reliability. Specifically,
technology based
-on rate less erasure codes \cite{maymounkov03ratelesscodes} seems very
promising.
+on rateless erasure codes \cite{maymounkov03ratelesscodes} seems very
promising.
\subsection{Algorithms}
-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
the data and overlay maintains only the \emph{pointers} to the data. We
decided to use DOLR 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 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
mapping function of the overlay. Additionally, these systems wastes both
storage and bandwidth, and
are sensitive to certain attacks (e.g., DDoS attack).
@@ -1960,7 +1961,7 @@
\begin{itemize}
\item Data lookup with a given pointer random string returning most recent
scroll block.
\begin{enumerate}
-\item Query originator locally compute a hash for given pointer random string.
+\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.,
hosting peer's IP-address) to query originator, using pointer block's own
indexing schemes.
\item Query originator requests hosting peer to return the scroll block.
@@ -1971,7 +1972,7 @@
\item Data lookup with a given pointer random string returning scroll block(s)
for a given date and time range.
\begin{enumerate}
-\item Query originator locally compute a hash for given pointer random string.
+\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., hosting
peer's IP-addresses) to query originator, using pointer block's own indexing
schemes.
\item Query originator requests hosting peer to return the scroll block.
@@ -2008,11 +2009,11 @@
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 user is able to verify the correctness
+pointer random string; how the user is able to verify the correctness
of the search results, and how do we know which one is the
correct Storm scroll block ? 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 do we are able to know if this was a spam attack, or the
+mentioned problem; data lookup is performed by user, but there is no reply
+from the system. How we are able to know if this was a spam attack, or the
data really doesn't exist in the system ? Another problem related to 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
@@ -2049,7 +2050,7 @@
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
-DOLR abstraction of tightly structured overlay, we can minimize the the lack
+DOLR abstraction of tightly structured overlay, we can minimize the lack
of locality in tightly structured overlays. Finally, we believe that issues
related to tightly structured overlays are solved in near future, because of
wide and intensive co-operation among research groups.
@@ -2061,13 +2062,11 @@
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
-presented \cite{gribble01p2pdatabase}.
+presented \cite{gribble01p2pdatabase}.
-As security technologies comes more mature, we wish to apply these
-technologies with Fenfire, if applicable.
-
-In the following months, we will implement a Fenfire Peer-to-Peer
-prototype.
+As security technologies come more mature, we wish to apply these
+technologies with Fenfire, if applicable. In the following months, we will
+implement a Fenfire Peer-to-Peer prototype.
\bibliographystyle{gradu}
\bibliography{progradu}
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., (continued)
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/06
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/06
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/06
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/06
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/07
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/07
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/07
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/12
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/12
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/12
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert...,
Hermanni Hyytiälä <=
- [Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert..., Hermanni Hyytiälä, 2003/03/12
- [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/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/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/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/13