1008 |
Discussion |
Discussion |
1009 |
========== |
========== |
1010 |
|
|
1011 |
In this section we evaluate Storm's design with regard to previously presented |
To evaluate the design, we revisit the issues raised by data mobility. |
1012 |
use cases, summarize Storm's implementation status and outline open issues |
For the two issues addressed, *dangling links* and *tracking |
|
and future work. |
|
|
|
|
|
|
|
|
Evaluation |
|
|
---------- |
|
|
|
|
|
To evaluate the design, the issues raised by data mobility are revisited in |
|
|
the following. For the two issues addressed, *dangling links* and *tracking |
|
1013 |
alternative versions*, each individual (use) case that was identified in the |
alternative versions*, each individual (use) case that was identified in the |
1014 |
introduction is dealt with here to illustrate Storm. |
introduction is dealt with here to illustrate Storm. |
1015 |
|
|
1067 |
of replication and caching combined with location-independent identifiers |
of replication and caching combined with location-independent identifiers |
1068 |
enable several improvements, including the possibility to keep on working on |
enable several improvements, including the possibility to keep on working on |
1069 |
shared documents even when there is no or an unreliable network connection. |
shared documents even when there is no or an unreliable network connection. |
|
|
|
|
Future work |
|
|
----------- |
|
|
|
|
|
Currently, we are working on completing our GISP-based peer-to-peer |
|
|
implementation of Storm. Once this is done, we intend to explore |
|
|
alternative DHT implementations as well. We will also evaluate |
|
|
using Merkle hash trees [XXXref] to identify blocks; this would |
|
|
allow us to download parts of a block from multiple sources |
|
|
simultaneously (as in e.g. [XXX ref Overnet]). |
|
|
|
|
|
No work on integrating Storm with current programs (in the spirit of Open |
|
|
Hypermedia) has been done so far. It is not clear how far this is possible |
|
|
without changing applications substantially, if advantage of our |
|
|
implementation of Xanalogical storage is to be taken. Vitali [vitali99versioning]_ |
|
|
notes that Xanalogical storage necessiates strong discipline in version tracking, |
|
|
which current systems lack. One possibility is to take an existing system |
|
|
(with features outside the focus of Gzz) |
|
|
that implements strict versioning, and to modify it to use Storm for storage. |
|
|
A candidate is the object-oriented (web) publishing environment Zope [ref zope.org/com, book, |
|
|
article?], which is Free Software and stores everything by default as diffs to |
|
|
a (flat file) database. Another way is studying the applicability of the |
|
|
open hypermedia protocol (OHP) [reich-davis99-ohp]. |
|
|
|
|
|
As mentioned in the presentation of Storm block storage (section 4), |
|
|
although the terminology used here is about characters and text, all media |
|
|
are considered. There dealing with e.g. video data, with very large file |
|
|
sizes, as (collections of) blocks, is partly unresolved. |
|
|
|
|
|
Besides these issues with the backend, we are facing user interface issues |
|
|
as well -- for example the conventions for listing, moving and deleting |
|
|
blocks. |
|
|
|
|
|
.. [not worth to mention ? -Hermanni] |
|
|
[how does video work here, i.e. are they huge blocks or collections of many |
|
|
small, frames? or a sequence between two keyframes?] |
|
|
|
|
|
Benja says: Probably large, but the number of links to them |
|
|
still won't be that big, I guess. Not sure how to discuss this |
|
|
in the text; feel free to propose something :-) |
|
|
|
|
|
Toni: will try.. wondering also about who to consult :o |
|
|
|
|
|
.. [not worth to mention ? -Hermanni] |
|
|
Future directions: Implement home node model or directory model ? |
|
|
|
|
|
.. [not worth to mention ? -Hermanni] |
|
|
Open issue: Firewall Transparency/NATs ? |
|
|
|
|
|
.. [not worth to mention, see above ? -Hermanni] |
|
|
Open issue: other related systems (within gzz?) for e.g. more synchronous |
|
|
collabaration (irc?)? |
|
|
|
|
|
.. [not worth to mention, first p2p proto then these ;) ? -Hermanni] |
|
|
p2p -> cf half-life of peers (Mojo Nation): Is it desirable that 'weak' peers |
|
|
participate in a DHT? -- In Circle, peers must have been online |
|
|
for at least an hour... In which ways, then, can 'weak' peers contribute |
|
|
to the network in a p2p fashion? Caching is certainly one central |
|
|
way, esp. when combined with multisource downloading (this can |
|
|
potentially boost download speeds to the full available bandwidth). |
|
|
This is a performance/reliability issue rather than something |
|
|
changing the fundamental qualities of the network, but still important. |
|
|
|
|
|
.. [not worth to mention ? -Hermanni] |
|
|
[Symphony supports heterogeneity of peers -Hermanni] |
|
|
|
|
|
.. [not worth to mention ? -Hermanni] |
|
|
======= |
|
|
>>>>>>> 1.173 |
|
|
The important point about p2p publishing is that no account and setup |
|
|
is necessary to start publishing. |
|
1070 |
|
|
1071 |
|
|
1072 |
Conclusions |
Conclusions |
1085 |
does not support peer-to-peer distribution yet, but the Gzz project has used it |
does not support peer-to-peer distribution yet, but the Gzz project has used it |
1086 |
for local storage and server-based collaboration for one and a half years. |
for local storage and server-based collaboration for one and a half years. |
1087 |
|
|
1088 |
|
Currently, we are working on completing our GISP-based peer-to-peer |
1089 |
|
implementation of Storm. Once this is done, we intend to explore |
1090 |
|
alternative DHT implementations as well. We will also evaluate |
1091 |
|
using Merkle hash trees [XXXref] to identify blocks; this would |
1092 |
|
allow us to download parts of a block from multiple sources |
1093 |
|
simultaneously (as in e.g. [XXX ref Overnet]). |
1094 |
|
|
1095 |
Storm has proven to be a solid basis for Gzz, but |
Storm has proven to be a solid basis for Gzz, but |
1096 |
no work has been done to integrate it with existing systems, yet. |
no work has been done to integrate it with existing systems, yet. |
1097 |
This makes Storm a rather monolithic approach at present. |
This makes Storm a rather monolithic approach at present. |
1100 |
we believe that it is valuable as an exercise in what is possible |
we believe that it is valuable as an exercise in what is possible |
1101 |
if we can break backwards compatibility with the state of the art. |
if we can break backwards compatibility with the state of the art. |
1102 |
|
|
1103 |
|
No work on integrating Storm with current programs (in the spirit of Open |
1104 |
|
Hypermedia) has been done so far. It is not clear how far this is possible |
1105 |
|
without changing applications substantially, if advantage of our |
1106 |
|
implementation of Xanalogical storage is to be taken. Vitali [vitali99versioning]_ |
1107 |
|
notes that Xanalogical storage necessiates strong discipline in version tracking, |
1108 |
|
which current systems lack. One possibility is to take an existing system |
1109 |
|
(with features outside the focus of Gzz) |
1110 |
|
that implements strict versioning, and to modify it to use Storm for storage. |
1111 |
|
A candidate is the object-oriented (web) publishing environment Zope [ref zope.org/com, book, |
1112 |
|
article?], which is Free Software and stores everything by default as diffs to |
1113 |
|
a (flat file) database. Another way is studying the applicability of the |
1114 |
|
open hypermedia protocol (OHP) [reich-davis99-ohp]. |
1115 |
|
|
1116 |
At the end, we hope that we have provided a case study in |
At the end, we hope that we have provided a case study in |
1117 |
what's possible in a system that does not use |
what's possible in a system that does not use |
1118 |
location-dependent identifiers at all. We hope to raise awareness |
location-dependent identifiers at all. We hope to raise awareness |