Keyword Search in Decentralized Storage Systems

Round 1

Reviewer 1 Report

Summary

The authors present the need for generating a keyword based index to quickly search objects in a decentralised storage systems (DSS).
First a related work is introduced regarding other technologies for searching using keywords in DSSs.
Secondly, the authors present two index structures and the operations required to make them work in DSSs.
Next, the authors present a novel research proposal for generating said indexes, storing them and distributing them across the DSSs.
Finally, an evaluation of the presented research proposal is done.

Comments

- The text has grammatical and spelling errors. The prose style does not follow a logical order. E.g. at the end of the Introduction section, the authors prematurely describe information that should appear in later sections, like the related works, or a description of the proposal presented in this work. Overall, the text is hard to follow at some points of the manuscript.

- Within the scope of the problem, no details are given w.r.t. what the keywords stored in the index point to. The keywords refer only to the filename? the metadata? the contents on the file itself? In that case, what happens if the contents of the file are not text-based? All these questions are not addressed correctly in the manuscript.

- No rationalised reason is given as to why the authors chose B+Tree and HashMap over other similar index structures that may be plausible for this work. This should be clarified in the text.

- There are several terms not correctly introduced in the text or referenced, e.g. ElasticSearch. Additionally, many acronyms are not correctly expanded, e.g. IPFS, and the capitalization of such terms is not correct in some instances. E.g. mixed lower-case, upper-case along the way.

- ipfs-search as such is not correctly described or referenced in the text. The authors merely mention the name and does not cite a proper definition. This issue is repeated with other terms. This is confusing.

- The section 2 related requires a complete overhaul. The works cited are technologies or git repositories (some repos didn't get any commits since 2017, like decentralized wiki search). The related works studied to contextualise this work are simply too shallow. No recent (aka 2019+) research proposals by other researchers are mentioned in this work, only established technologies like DHT or similar.

- Section 2.3 is titled BitSwap, but no mention of such protocol is found in the manuscript.

- Section 2.3 what is segmentation of the file? please consider giving further explanation or include a simple example that illustrates why this is important to the reader.

- Section 2.3. what is TFt?? It appears as the result of equation 1, but no further description or intuition is given to the reader as to what impact does it have for the remainder of the work.

- Experimental evaluation does not serve the main purpose of validating this research proposal. An evaluation for a research proposal like this should include contrasting information from research works from other researchers. Instead, only the two variants implemented by the authors themselves (B+Tree and HashMap) are shown in the results. This does not give any information as to how this proposal would perform next to other solutions in the related works. Therefore, the experiment design is flawed.

- What is Wiki HashMap exactly?? it is not properly introduced in the text, it appears at first in section 5 and nevertheless it is the core technology for one of the experimentation sets. The manuscript does not cite, nor describe what exactly it is, where does Wiki HashMap come from?

- Previously, you mentioned in the related works w.r.t. DHT that one of the major issues of the DHT solutions is the network bandwidth overhead. However, the authors did not employ network overhead as an experimentation parameter to measure the performance of the proposal. This should be explained in the text in a way that justifies why it is pointed out as a key weakness of the related work but instead it is not considered for performance tests.

- One of the key advantages of the IPFS is reducing the delay when the source and the client are separated by a large distance by asking the same data to a closer node (less delay). In the evaluation design, the setup does not describe what is the delay introduced by transmission among nodes of the network. How would the system behave if the source node for certain blocks introduced a large delay in the network transmissions? e.g. a cluster of nodes are located in a far remote area.

Author Response

Please see the attachment.

 

Author Response File: Author Response.pdf

Reviewer 2 Report

In this pper the authors first applied decentralized B+Tree and HashMap to the DSSs to provide keyword search with both indexes are kept in block. The ensured that all operations involve as few blocks as possible to reduce network traffic and response time. The topic of the manuscript is interesting.

The authors should first of all enlarge the introduction, explain better the motiivation of writing this manuscript and present in a better way their original c ontributions.

New related referencess hould be added.

Author Response

Please see the attachment.

 

Author Response File: Author Response.pdf

Round 2

Reviewer 1 Report

the authors have answered all the questions and have improved the paper based upon the comments and the paper is in better shape for being accepted.