summaryrefslogtreecommitdiffstats
path: root/report/chapters/2-lit-r.tex
diff options
context:
space:
mode:
authorSiddharth Ravikumar <sravik@bgsu.edu>2016-03-07 19:56:33 -0500
committerSiddharth Ravikumar <sravik@bgsu.edu>2016-03-07 19:56:33 -0500
commitd6f6fa899067e364e0e42d17a2d20b3cb3067b75 (patch)
tree6c143dab7100b80e8891bbc40740b20a452af027 /report/chapters/2-lit-r.tex
parent9497ded90b9e48a08e103fab25ccac8adf5bc4d5 (diff)
Edited Chapter 2.
Diffstat (limited to 'report/chapters/2-lit-r.tex')
-rw-r--r--report/chapters/2-lit-r.tex99
1 files changed, 50 insertions, 49 deletions
diff --git a/report/chapters/2-lit-r.tex b/report/chapters/2-lit-r.tex
index 168546d..ac5f01b 100644
--- a/report/chapters/2-lit-r.tex
+++ b/report/chapters/2-lit-r.tex
@@ -5,15 +5,15 @@
The idea of unifying the storage provided by multiple Internet file
storage providers and storing all the content in an encrypted form is
-not new, computer researchers/scientists, programmers have devised
-different methods to use multiple file storage providers' storage
-space. This chapter gives an overview of the work done by Yeo et
-al. in unifying the storage provided by Dropbox, Box, Google Drive and
-Skydrive on Android devices\cite{yeo}(Section \ref{2-yeo-sec});
-SkyCDS, a content delivery service, by Gonzalez et al., which uses
-publish/subscribe overly paradigm and stores the content across
-multiple ``cloud'' storage providers such that only part of the
-content (in encrypted form) is stored on each ``cloud'' storage
+not new, computer researchers and programmers have devised different
+methods to use multiple file storage providers' storage space. This
+chapter gives an overview of the work done by Yeo et al. in unifying
+the storage provided by Dropbox, Box, Google Drive and Skydrive on
+Android devices\cite{yeo}(Section \ref{2-yeo-sec}); SkyCDS, a content
+delivery service, by Gonzalez et al., which uses publish/subscribe
+overlay paradigm and stores the content across multiple ``cloud''
+storage providers such that only part of the content (in encrypted
+form) is stored on each ``cloud'' storage
provider\cite{skycds}(Section \ref{2-skycds-sec}); lastly,
\verb+git-annex+, by Joey Hess\cite{person:joeyh}, that allows one to
version control and keep track of large files with a possibility of
@@ -33,34 +33,35 @@ phone and the application uses erasure coding\cite{weatherspoon} to
split each file into \verb`n + k` fragments and spreads the encrypted
fragments across storage provided by the file storage providers. All
basic file operations -- Create, Rename, Update, Delete (CRUD) -- are
-possible. Information about the file stored in a unified location is
-stored in a SQLite database. Unlike combox, which depends the file
+possible. Information about the files stored in the unified location
+is stored in a SQLite database. Unlike combox, which depends the file
storage provider' client to sync file fragments/shards to the file
-storage provider's server, the android application developed by Yeo et
+storage provider's server, the Android application developed by Yeo et
al. takes the responsibility to sync file fragments/shards to each
-file storage provider and usesd the OAuth 2.0\cite{protocol:oauth2}
+file storage provider and uses the OAuth 2.0\cite{protocol:oauth2}
protocol for authorization.
-For encrypting file fragments, they use AES-256; they key for
-encrypting is derived from the user's password by using Password-Based
-Key Derivation Function (PBKDF2)\cite{kaliski}. For erasure coding
-they use the JigDFS librarary\cite{jigdfs}. The android application is
-able do ``progressive streaming'' of media files; this means that
-large media files can be streamed in real-time from the from the file
-storage providers' servers; this is an attractive feature in a
-``resource contrained'' device where storage is expensive.
-
-Yeo et al. propose methods for achieving data de-duplication, file
-fragment/shard compression based on the type of the file, intelligent
-pre-fetching and caching for file fragrments and ``automatic
-restoration in exploiting file-versioning''; these features were not
-implemented in the prototype Android application and there is
-possibility of Yeo et al. implementing these features in the future.
-
-It becomes that that Yeo et al. work is of immense importance when we
-take into consideration the research done by Yang et al., which found
-that 59\% of the users who use ``cloud storage service'' access the
-service through a smart phone and 42.2\% users access
+For encrypting file fragments, they use AES-256; the key for
+encrypting file fragments is derived from the user's password by using
+Password-Based Key Derivation Function (PBKDF2)\cite{kaliski}. For
+erasure coding they use the JigDFS librarary\cite{jigdfs}. The Android
+application is able do ``progressive streaming'' of media files; this
+means that large media files can be streamed in real-time from the
+from the file storage providers' servers; this is an attractive
+feature in a ``resource contrained'' device where storage is
+expensive.
+
+Yeo et al. propose methods for achieving data de-duplication; file
+compression based on the type of the file; intelligent pre-fetching
+and caching of file fragrments and ``automatic restoration in
+exploiting file-versioning''; these features were not implemented in
+the prototype Android application and there is possibility of Yeo et
+al. implementing these features in the future.
+
+It becomes apparent that Yeo et al. work is of immense importance when
+we take into consideration the research done by Yang et al., which
+found that 59\% of the users who use ``cloud storage service'' access
+the service through a smart phone and 42.2\% users access it for
audio/video\cite{yang}. The research by Yang et al. definitely
suggests a trend of users' preference for small hand-held computers
over laptops and desktops.
@@ -76,7 +77,7 @@ minimize loss when a ``cloud'' storage provider goes out of business
or if there is temporary outage in the storage service provided by the
``cloud'' storage provider.
-In SkyCDS the content delivery to subscribers of the content is
+In SkyCDS, the content delivery to subscribers of the content is
segregated into two distinct layers -- Metadata Flow Layer and the
Content Flow Layer. The publisher of the content largely interacts
with the Metadata Flow Layer that controls and keeps track of the what
@@ -84,7 +85,7 @@ content is published and the subscriber also largely interacts with
the Metadata Flow layer to subscribe to content published in the
content delivery system. The Content Flow Layer is where the content
is stored across multiple ``cloud'' storage providers. The publisher
-is responsible for publishing the content using eth ``delivery
+is responsible for publishing the content using the ``delivery
workflow'' (part of the Content Flow Layer) and the subscriber uses
the ``retrieve workflow'' to get access to the subscribed content.
@@ -98,13 +99,13 @@ workflow'' engine which is invoked when the publisher triggers the
action to publish the respective content to subscribers.
To evaluate the effectiveness of SkyCDS, Gonzalez et al. state that
-they've done a case study using the data (content) obtained from
-European Space Astronomy Center (ESAC) for the Soil Moisture Ocean
-Salinity. In this study, a group of organizations, in two different
-continents, used SkyCDS to share satillete images with each
-other. According to Gonzalez et al. this study attested SkyCDS as a
-viable option for content delivery with respective to performance,
-cost of ``cloud'' storage space and reliability.
+they've done a case study using the data obtained from European Space
+Astronomy Center (ESAC) for the Soil Moisture Ocean Salinity. In this
+study, a group of organizations, in two different continents, used
+SkyCDS to share satillete images with each other. According to
+Gonzalez et al. this study attested SkyCDS as a viable option for
+content delivery with respective to performance, cost of ``cloud''
+storage space and reliability.
\section{git-annex}\label{2-gitannex-sec}
@@ -113,13 +114,13 @@ not usually feasible to version control under
\verb+git+\cite{program:git}. \verb+git-annex+, checks in the names
and other meta-data about the files in git and stores the actual
content under \verb+.git/annex+ directory. When a file is added to
-\verb+git-annex+, a symlink of the file is created in place of th file
-and the content of the file itself is stored under the
+\verb+git-annex+, a symlink of the file is created in place of the
+file and the content of the file itself is stored under the
\verb+.git/annex+ directory.
For instance, say there is a file called
-\verb+deb-nicholson-80s.medium.webm+ was downloaded from the Internet
-to the \verb+git-annex+ directory:
+\verb+deb-nicholson-80s.medium.webm+ that was downloaded from the
+Internet to the \verb+git-annex+ directory:
\begin{verbatim}
↳ git status
@@ -173,8 +174,8 @@ copy of a given file in another git annex repository,
\verb+git-annex+ has this feature called ``special
remotes''\cite{documentation:git-annex-sremotes}, that allows one to
-push/copy data to checked into \verb+git-annex+ to storage provided by
-``cloud'' storage providers. At the time of writing this report,
+push files checked into \verb+git-annex+ to storage provided by file
+storage providers. At the time of writing this report,
\verb+git-annex+ supports pushing data to the following file storage
services:
@@ -201,7 +202,7 @@ services:
\end{itemize}
}
-All data pushed to file storage provider's servers can be optionally
+All data pushed to file storage provider's servers can optionally be
encrypted using one's GPG key. For instance, to encrypt data that is
pushed to the Amazon S3 special remote, following command is
used\cite{docs:git-annex-as3}: