BZPEERPapers, people, evidence and research paths
Menu

Discover

SearchFind papers, people, topics, institutions and opportunities from one place.GraphSee how papers, authors, topics and evidence connect.

Research tools

HomeContinue from the papers, people and topics that matter now.CollectionsTurn saved papers into reading lists, evidence maps and shareable context.ResearchReconstruct the path that led you from search to paper to question.CollaborationMove from a paper, topic or expert request into a focused thread.PublishCreate full-text research articles with metadata, formulas and versions.

Network

ExpertsFind specialists whose work and reviews explain why they can help.CommunitiesJoin research groups organized around papers, topics and shared evidence.

Opportunities

ListingsBrowse roles, calls and collaborations connected to real research context.

Account

Log inReturn to your saved papers, graph views and active threads.Create accountStart saving papers, building a research trail and joining teams.
Log inCreate account

Source author record

Mohammad Roohitavaf

Mohammad Roohitavaf appears in the imported research catalog. Authorship, coauthor and topic links are available while profile ownership is still unclaimed.

ResearcherUnclaimed source record
Distributed, Parallel, and Cluster Computing

Catalog footprint

What is connected

4works
1topics
2close collaborators

Actions

Connect this record

Log in to claim
Open graphBrowse works

Research graph

See the researcher in context

Open full explorer

Inspect adjacent papers, topics, institutions and collaborators without losing the researcher page.

Building this map preview

BZPEER is loading the nearby papers, people, topics and institutions for this page.

Published work

4 published item(s)

preprint2016arXiv

Consistency in Distributed Data Stores

This paper focuses on the problem of consistency in distributed data stores.We define strong consistency model which provides a simple semantics for application programmers, but impossible to achieve with availability and partition-tolerance. We also define weaker consistency models including causal and eventual consistency. We review COPS and GentleRain as two causally consistent data stores as well as Dynamo as an eventually consistent data store. We provide insights about scenarios where each of these methods is suitable, and some future research directions.

0 citations0 reviewsNo code linkedOpen access
preprint2016arXiv

GentleRain+: Making GentleRain Robust on Clock Anomalies

Causal consistency is in an intermediate consistency model that can be achieved together with high availability and high performance requirements even in presence of network partitions. There are several proposals in the literature for causally consistent data stores. Thanks to the use of single scalar physical clocks, GentleRain has a throughput higher than other proposals such as COPS or Orbe. However, both of its correctness and performance relay on monotonic synchronized physical clocks. Specifically, if physical clocks go backward its correctness is violated. In addition, GentleRain is sensitive on the clock synchronization, and clock skew may slow write operations in GenlteRain. In this paper, we want to solve this issue in GenlteRain by using Hybrid Logical Clock (HLC) instead of physical clocks. Using HLC, GentleRain protocl is not sensitive on the clock skew anymore. In addition, even if clocks go backward, the correctness of the system is not violated. Furthermore, by HLC, we timestamp versions with a clock very close to the physical clocks. Thus, we can take causally consistency snapshot of the system at any give physical time. We call GentleRain protocol with HLCs GentleRain+. We have implemented GentleRain+ protocol, and have evaluated it experimentally. GentleRain+ provides faster write operations compare to GentleRain that rely solely on physical clocks to achieve causal consistency. We have also shown that using HLC instead of physical clock does not have any overhead. Thus, it makes GentleRain more robust on clock anomalies at no cost.

0 citations0 reviewsNo code linkedOpen access
preprint2015arXiv

Auditable Restoration of Distributed Programs

We focus on a protocol for auditable restoration of distributed systems. The need for such protocol arises due to conflicting requirements (e.g., access to the system should be restricted but emergency access should be provided). One can design such systems with a tamper detection approach (based on the intuition of "break the glass door"). However, in a distributed system, such tampering, which are denoted as auditable events, is visible only for a single node. This is unacceptable since the actions they take in these situations can be different than those in the normal mode. Moreover, eventually, the auditable event needs to be cleared so that system resumes the normal operation. With this motivation, in this paper, we present a protocol for auditable restoration, where any process can potentially identify an auditable event. Whenever a new auditable event occurs, the system must reach an "auditable state" where every process is aware of the auditable event. Only after the system reaches an auditable state, it can begin the operation of restoration. Although any process can observe an auditable event, we require that only "authorized" processes can begin the task of restoration. Moreover, these processes can begin the restoration only when the system is in an auditable state. Our protocol is self-stabilizing and has bounded state space. It can effectively handle the case where faults or auditable events occur during the restoration protocol. Moreover, it can be used to provide auditable restoration to other distributed protocol.

0 citations0 reviewsNo code linkedOpen access
preprint2015arXiv

Stabilization and Fault-Tolerance in Presence of Unchangeable Environment Actions

We focus on the problem of adding fault-tolerance to an existing concurrent protocol in the presence of {\em unchangeable environment actions}. Such unchangeable actions occur in practice due to several reasons. One instance includes the case where only a subset of the components/processes can be revised and other components/processes must be as is. Another instance includes cyber-physical systems where revising physical components may be undesirable or impossible. These actions differ from faults in that they are simultaneously {\em assistive} and {\em disruptive}, whereas faults are only disruptive. For example, if these actions are a part of a physical component, their execution is essential for the normal operation of the system. However, they can potentially disrupt actions taken by other components for dealing with faults. Also, one can typically assume that fault actions will stop for a long enough time for the program to make progress. Such an assumption is impossible in this context. We present algorithms for adding stabilizing fault-tolerance, failsafe fault-tolerance and masking fault-tolerance. Interestingly, we observe that the previous approaches for adding stabilizing fault-tolerance and masking fault-tolerance cannot be easily extended in this context. However, we find that the overall complexity of adding these levels of fault-tolerance remains in P (in the state space of the program). We also demonstrate that our algorithms are sound and complete.

0 citations0 reviewsNo code linkedOpen access