1799 |
structured overlays; the tightly structured overlay supports global data lookups |
structured overlays; the tightly structured overlay supports global data lookups |
1800 |
in the overlay, whereas the data lookup model of the loosely structured approach |
in the overlay, whereas the data lookup model of the loosely structured approach |
1801 |
is limited to a certain area of the overlay\footnote{The area depends on where the query |
is limited to a certain area of the overlay\footnote{The area depends on where the query |
1802 |
originator is located in the overlay.}. |
originator is located in the overlay.}. To summarize, the tightly structured approach |
1803 |
|
is more efficient and scalable than the loosely structured approach. |
1804 |
|
|
1805 |
For Fenfire's needs for \emph{locating} data, an important advantage of the |
Since both Storm and tightly structured overlays use globally unique identifiers for each, |
1806 |
tightly structured approach over the loosely structured approach is that both tightly |
it is feasible to use tightly structured overlays for \emph{locating} Storm blocks efficiently. |
|
structured systems and Fenfire use similar methods for identifying data in the |
|
|
system, i.e., Storm provides globally unique identifiers which can be used in the |
|
|
tightly structured overlay. |
|
1807 |
Another key feature of tightly structured overlays is that they are able |
Another key feature of tightly structured overlays is that they are able |
1808 |
to provide general purpose \emph{interface} for Reference Resolution Services (RRS) |
to provide general purpose \emph{interface} for Reference Resolution Services (RRS) |
1809 |
\cite{balakrishnan03semanticfree}. Authors argue that next generation RRS must be |
\cite{balakrishnan03semanticfree}. Authors argue that next generation RRS must be |