/[gzz]/gzz/Documentation/misc/hemppah-progradu/masterthesis.tex
ViewVC logotype

Diff of /gzz/Documentation/misc/hemppah-progradu/masterthesis.tex

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.209 by hemppah, Wed Oct 8 12:59:43 2003 UTC revision 1.210 by hemppah, Wed Oct 8 13:24:48 2003 UTC
# Line 1598  a brief description of the problem, poss Line 1598  a brief description of the problem, poss
1598  \chapter{Fenfire hypermedia system}  \chapter{Fenfire hypermedia system}
1599    
1600  In this chapter we give an overview of the Fenfire system and  In this chapter we give an overview of the Fenfire system and
1601  the xanalogical storage model. Also, we describe Storm  the xanalogical storage model. Also, we describe Storm,
1602  which is an essential part of Fenfire's Peer-to-Peer functionality.  which is an essential part of Fenfire's Peer-to-Peer functionality.
1603    
1604  \section{Overview}  \section{Overview}
1605    
1606  The Fenfire project \cite{fenfireurl} is an effort to build a location transparent, hyperstructured desktop  The Fenfire project \cite{fenfireurl} is an effort to build a location--transparent, hyperstructured desktop
1607  environment. By location transparent, we mean hiding the heterogeneous and distributed nature of the system  environment. By \emph{location transparent}, we mean the heterogeneous and distributed nature of the system is hidden
1608  so that it appears to the end user like one system, and by hyperstructured system  so that it appears to the end user like one system, and a \emph{hyperstructured system}
1609  a system in which data can be associated with other data arbitrarily. Fenfire uses xanalogical storage model  is one in which data can be associated arbitrarily with other data. Fenfire uses a xanalogical storage model
1610  \cite{ted-xu-model} as a basis for hyperstructured media. Each data item in the Fenfire system has a globally unique  \cite{ted-xu-model} as the basis for hyperstructured media. Each data item in the Fenfire system has a globally unique
1611  identifier. This property allows making references between \emph{any}  identifier. This property allows making references between \emph{any}
1612  data easier and more seamlessly interoperating than in other systems. For location transparency in the Fenfire system,  data easier and more seamlessly interoperating than in other systems. For location transparency in the Fenfire system,
1613  we are currently analysing the applicability of Peer-to-Peer infrastructure.  we are currently analysing the applicability of the Peer-to-Peer infrastructure.
1614    
1615  Fenfire was formerly also a partial implementation  Fenfire was formerly a partial implementation
1616  of the ZigZag\texttrademark -- structure, which has been originally invented  of the ZigZag\texttrademark --structure, which has been originally invented
1617  by Ted Nelson. Now, however, Fenfire uses Resource Description Framework (RDF) \cite{w3rdfurl}  by Ted Nelson. Now, however, Fenfire uses Resource Description Framework (RDF) \cite{w3rdfurl}
1618  for representing internal data structures and their relationships.  for representing internal data structures and their relationships.
1619    
# Line 1633  in the Fenfire system. Line 1633  in the Fenfire system.
1633    
1634  \section{Xanalogical storage model}  \section{Xanalogical storage model}
1635    
1636  Xanalogical storage model \cite{nelson99xanalogicalneeded} is a different kind of model for  The xanalogical storage model \cite{nelson99xanalogicalneeded} is a different kind of model for
1637  presenting data and relationships between data. For example, in the World Wide Web links are  presenting data and relationships between data. For example,  World Wide Web links are
1638  between documents, while in the xanalogical storage model links are between individual  between documents, while the xanalogical storage model links are between individual
1639  characters\footnote{Xanalogical storage model  characters\footnote{Xanalogical storage model
1640  is not limited to text. It can support arbitrary data, e.g., pixels of picture or  is not limited to text. It can support arbitrary data, e.g., pixels of picture or
1641  frames of video.}. \emph{Enfilade} is a mutable ''virtual file'' (or part of one), which is a list  frames of video.}. Enfilade is a mutable ''virtual file'' (or part of one), which is a list
1642  of fluid media content. Fluid media is the smallest unit of data in the xanalogical storage  of fluid media content. Fluid media is the smallest unit of data in the xanalogical storage
1643  model (e.g., a character). \emph{Transclusion} is an inclusion in  model (e.g., a character). Transclusion refers to the inclusion  
1644  enfilade of contents already used in another enfilade. With the transclusion, a system  of enfilade content that is already used in another enfilade. With the transclusion, a system
1645  implementing the xanalogical storage model is able to show \emph{all} data content that share the same  implementing the xanalogical storage model is able to show all of its data content that share the same
1646  fluid media with current data content (e.g., all documents in a system containing document's text).  fluid media with current data content (e.g., all documents in a system containing document's text).
1647  Figure \ref{fig:xanalogical_model}  Figure \ref{fig:xanalogical_model}
1648  illustrates the xanalogical storage model with documents, text and characters.  illustrates the xanalogical storage model with documents, text and characters.
# Line 1651  In the xanalogical storage model, links Line 1651  In the xanalogical storage model, links
1651  and bidirectional. A link is shown between any two data contents  and bidirectional. A link is shown between any two data contents
1652  containing a specific fluid media unit that the link connects.  containing a specific fluid media unit that the link connects.
1653  Each fluid media unit in the xanalogical storage model has a  Each fluid media unit in the xanalogical storage model has a
1654  permanent, globally unique identifier. For instance, let's consider the following  permanent, globally unique identifier. For instance, consider the following
1655  example, presented first time in \cite{lukka02freenetguids}: ''the character 'D'  example, presented originally by Lukka et al. \cite{lukka02freenetguids}: ''the character 'D'
1656  typed by Janne Kujala on 10/8/97 8:37:18''. When character  typed by Janne Kujala on 10/8/97 8:37:18.'' When the character
1657  'D' is first typed in, the xanalogical storage model  'D' is first typed in, the xanalogical storage model
1658  creates a permanent identifier for that character  creates a permanent identifier for that character
1659  and retains it when the character is copied to different document. In practice, the xanalogical  and retains it when the character is copied to different document. In practice, the xanalogical
1660  storage model uses \emph{spans}, ranges of consecutive  storage model uses spans, ranges of consecutive
1661  fluid media units to perform storage operations.  fluid media units, to perform storage operations.
1662    
1663  \begin{figure}  \begin{figure}
1664  \centering  \centering
# Line 1670  fluid media units to perform storage ope Line 1670  fluid media units to perform storage ope
1670    
1671  \section{Storm}  \section{Storm}
1672    
1673  In this section, we will give a brief overview of Storm design. More information can be found  This section present a brief overview of the Storm design. More detailed information can be found
1674  from recent publications. For detailed Storm design, see \cite{fallenstein03storm}.  from the recent work by Fallenstein et al. \cite{fallenstein03storm}.
1675    
1676  Storm (for \emph{STORage Module}) stores all data as \emph{blocks}, which  Storm (for STORage Module) stores all data as ''blocks'', which
1677  are immutable byte sequences. Storm \emph{assigns} a globally unique identifier to each  are immutable byte sequences. Storm assigns a globally unique identifier to each
1678  block\footnote{This resembles the process how tightly structured overlay assigns a subset of keys  block\footnote{This resembles the process how a tightly structured overlay assigns a subset of keys
1679  to each participating peer: a user has no control over the assignment process.}. SHA-1 cryptographic  to each participating peer: a user has no control over the assignment process.}. SHA-1 cryptographic
1680  content hash function\footnote{SHA-1 is  content hash function\footnote{SHA-1 is
1681  considered as a collision free hash function. Therefore, it is very unlikely that two different Storm blocks  considered a collision free hash function. Therefore, it is very unlikely that two different Storm blocks
1682  would have same identifier.} \cite{fips-sha-1} is used  would have same identifier.} \cite{fips-sha-1} is used
1683  for creating unstructured and semantic-free, globally unique identifiers for blocks. Because of SHA-1  for creating unstructured and semantic-free, globally unique identifiers for blocks. Because of the SHA-1
1684  content hash, all identifiers are directly the data verifiers as well. The uniqueness of blocks creates  content hash, all identifiers are the data verifiers as well. The uniqueness of blocks creates
1685  a basis for implementing the xanalogical storage model in the Fenfire system. Storm blocks have in common with regular files as they  a basis for implementing the xanalogical storage model in the Fenfire system. Storm blocks are similar to with regular files as they
1686  both contain the data. The main difference is that Storm blocks are \emph{immutable} since any  both contain the data. The chief difference is that Storm blocks are \emph{immutable} since any
1687  change to the byte sequence would change block's hash value (i.e., globally unique identifier).    change to the byte sequence would change block's hash value (i.e., globally unique identifier).  
1688    
1689  Support for immutable data is built on the immutable abstraction. Storm uses  Support for immutable data is built on the immutable abstraction. Storm uses
1690  \emph{pointers} and \emph{diffs} for dealing with this kind of data. Using diffs  pointers and diffs for dealing with this kind of data. Using diffs
1691  we are able to store alternative versions of Storm blocks efficiently. In this  we are able to store alternative versions of Storm blocks efficiently. In this
1692  paper, however, we discuss only pointers as they are part of the thesis' research problems.  paper, however, we discuss only pointers as they are part of the thesis' research problems.
 More information about diffs can be found from \cite{fallenstein03storm}.  
1693    
1694  \emph{Pointer} \cite{benja02urn5, fallenstein03storm} is a semantic-free updatable reference to  A pointer \cite{benja02urn5, fallenstein03storm} is a semantic-free updatable reference to
1695  Storm block. Pointer is a unique reference to the data and it is usually  a Storm block that is a unique reference to the data and is usually
1696  represented as a random string. Storm pointers are rather a \emph{concept} of data (e.g., ''The front page of the most recent  represented as a random string. Storm pointers are rather a \emph{concept} of data (e.g., ''The front page of the most recent
1697  version of New York Times newspaper'') whereas blocks \emph{contain} the data  version of New York Times newspaper'') whereas blocks \emph{contain} the data
1698  (''New York Times newspaper, 10.10.2002, version 1.0'').  (''New York Times newspaper, 10.10.2002, version 1.0'').
1699  Figure \ref{fig:storm_model} illustrates Storm storage model with pointers.  Figure \ref{fig:storm_model} illustrates Storm storage model with pointers.
1700    
1701  Each pointer is \emph{linked} to a collection of \emph{pointer blocks}.  Each pointer is linked to a collection of pointer blocks.
1702  Pointers can be created by a user, before the creation of a data block. Pointer blocks  Pointers can be created by a user, before creating of a data block. Pointer blocks also
1703  are created automatically by Storm when a data block is created and associated with a pointer  are created automatically by Storm when a data block is created and associated with a pointer
1704  (e.g., a user creates a data block associated with the concept ''The front page of the most recent  (e.g., a user creates a data block associated with the concept ''The front page of the most recent
1705  version of New York Times newspaper''). Pointer block has always a single target (i.e., a data block),  version of New York Times newspaper''). A pointer block has always a single target (i.e., a data block),
1706  saying that pointer $P$ targets data block $B$. In addition to this, pointer block  saying that pointer $P$ targets data block $B$. In addition to this, a pointer block
1707  may contain a list of zero or more obsoleted pointer blocks: when a new version of pointer  may contain a list of one or more obsoleted pointer blocks: when a new version of pointer
1708  block is created, it supersedes one older version which has been created in the past using the Storm indexing  block is created, it supersedes one older version that has been created in the past using the Storm indexing
1709  mechanisms. For details, see \cite{fallenstein03storm}. Next  mechanisms. When the pointer is used for referring to a specific data block, only
 time, when the pointer is used for referring to a specific data block, only  
1710  the most recent pointer's block target is loaded. However, the pointer blocks pointing  the most recent pointer's block target is loaded. However, the pointer blocks pointing
1711  to the previous versions of data blocks remains accessible, if needed. In figure \ref{fig:storm_pointercreation},  to the previous versions of data blocks remains accessible, if needed. In figure \ref{fig:storm_pointercreation},
1712  we show the overall pointer creation process.  we show the overall pointer creation process.

Legend:
Removed from v.1.209  
changed lines
  Added in v.1.210

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26