Srs
Content
System Requirement Specifications For
Automatic Reconfiguration for Large-Scale Reliable Storage
Systems
Purpose of the System:
Byzantine-fault-tolerant replication enhances the availability and reliability of
Internet services that store critical state and preserve it despite attacks or software errors.
However, existing Byzantine-fault-tolerant storage systems either assume a static set of
replicas, or have limitations in how they handle reconfigurations (e.g., in terms of the
scalability of the solutions or the consistency levels they provide). This can be
problematic in long-lived, large-scale systems where system membership is likely to
change during the system lifetime. In this paper, we present a complete solution for
dynamically changing system membership in a large-scale Byzantine-fault-tolerant
system. We present a service that tracks system membership and periodically notifies
other system nodes of membership changes. The membership service runs mostly
automatically, to avoid human configuration errors; is itself Byzantine fault- tolerant and
reconfigurable; and provides applications with a sequence of consistent views of the
system membership. We demonstrate the utility of this membership service by using it in
a novel distributed hash table called dBQS that provides atomic semantics even across
changes in replica sets. dBQS is interesting in its own right because its storage algorithms
extend existing Byzantine quorum protocols to handle changes in the replica set, and
because it differs from previous DHTs by providing Byzantine fault tolerance and
offering strong semantics. We implemented the membership service and dBQS. Our
results show that the approach works well, in practice: the membership service is able to
manage a large system and the cost to change the system membership is low.
EXISTING SYSTEM:
In Existing System, replication enhanced the reliability of internet services to
store the data’s. The preserved data to be secured from software errors. But, existing
Byzantine-fault tolerant systems is a static set of replicas. It has no limitations. So,
scalability is inconsistency. So, these data’s are not came for long-lived systems.
The existence of the following cryptographic techniques that an adversary cannot
subvert: a collision resistant hash function, a public key cryptography scheme, and
forward-secure signing key and the existence of a proactive threshold signature protocol.
PROPOSED SYSTEM:
In Proposed System, has two parts. The first is a membership
service (MS) that tracks and responds to membership changes. The MS
works mostly automatically,
and requires only minimal human
intervention; this way we can reduce manual configuration errors,
which
are
a
major
cause
of
disruption
in
computer
systems
periodically, the MS publishes a new system membership; in this way it
provides a globally consistent view of the set of available servers .
Reliable Automatic Reconfiguration
In this Module, it provides the abstraction of a globally consistent view of the
system membership. This abstraction simplifies the design of applications that use it,
since it allows different nodes to agree on which servers are responsible for which subset
of the service. It is designed to work at large scale, e.g., tens or hundreds of thousands of
servers. Support for large scale is essential since systems today are already large and we
can expect them to scale further.
It is secure against Byzantine (arbitrary) faults. Handling Byzantine faults is
important because it captures the kinds of complex failure modes that have been reported
for our target deployments.
Tracking membership Service
In this Module, is only part of what is needed for automatic reconfiguration. We
assume nodes are connected by an unreliable asynchronous network like the Internet,
where messages may be lost, corrupted, delayed, duplicated, or delivered out of order.
While we make no synchrony assumptions for the system to meet its safety guarantees, it
is necessary to make partial synchrony assumptions for liveness.
The MS describes membership changes by producing a configuration, which
identifies the set of servers currently in the system, and sending it to all servers. To allow
the configuration to be exchanged among nodes without possibility of forgery, the MS
authenticates it using a signature that can be verified with a well-known public key.
Byzantine Fault Tolerance
In this Module, to provide Byzantine fault tolerance for the MS, we implement it
with group replicas executing the PBFT state machine replication protocol.
These MS replicas can run on server nodes, but the size of the MS group is small
and independent of the system size. So, to implement from tracking service,
1. Add – It takes a certificate signed by the trusted authority describing the node
adds the node to the set of system members.
2. Remove – It also takes a certificate signed by the trusted authority that identifies
the node to be removed. And removes this node from the current set of members.
3. Freshness – It receives a freshness challenge, the reply contains the nonce and
current epoch number signed by the MS.
4. PROBE – The MS sends probes to servers periodically. It serves respond with a
simple ack, or, when a nonce is sent, by repeating the nonce and signing the
response.
5. New EPOCH – It informs nodes of a new epoch. Here certificate vouching for the
configuration and changes represents the delta in the membership.
Dynamic Replication
In this Module, to prevent attacker from predicting
1. Choose the random number.
2. Sign the configuration using the old shares
3. Carry out a resharing of the MS keys with the new MS members.
4. Discard the old shares
SYSTEM DESIGN
Data Flow Diagram / Use Case Diagram / Flow Diagram
The DFD is also called as bubble chart. It is a simple graphical
formalism that can be used to represent a system in terms of the input data to
the system, various processing carried out on these data, and the output data
is generated by the system
Dataflow Diagram:
Server
login
upload
files
Client
Login
request file
send to server
no
Membership
provider
files send
via router
file not
transfered
send report
yes
file request send
to server
once again
activate
membership
yes
no
check MS
Replica
Byzantine Fault
Tolerance
File transfer
.
SYSTEM STUDY
2.1 FEASIBILITY STUDY
The feasibility of the project is analyzed in this phase and business
proposal is put forth with a very general plan for the project and some
cost estimates. During system analysis the feasibility study of the
proposed system is to be carried out. This is to ensure that the proposed
system is not a burden to the company. For feasibility analysis, some
understanding of the major requirements for the system is essential.
Three key considerations involved in the feasibility analysis are
ECONOMICAL FEASIBILITY
TECHNICAL FEASIBILITY
SOCIAL FEASIBILITY
ECONOMICAL FEASIBILITY
This study is carried out to check the economic impact that the
system will have on the organization. The amount of fund that the company
can pour into the research and development of the system is limited. The
expenditures must be justified. Thus the developed system as well within the
budget and this was achieved because most of the technologies used are
freely available. Only the customized products had to be purchased.
TECHNICAL FEASIBILITY
This study is carried out to check the technical feasibility, that is,
the technical requirements of the system. Any system developed must not
have a high demand on the available technical resources. This will lead to
high demands on the available technical resources. This will lead to high
demands being placed on the client. The developed system must have a
modest requirement, as only minimal or null changes are required for
implementing this system.
SOCIAL FEASIBILITY
The aspect of study is to check the level of acceptance of the system
by the user. This includes the process of training the user to use the system
efficiently. The user must not feel threatened by the system, instead must
accept it as a necessity. The level of acceptance by the users solely depends
on the methods that are employed to educate the user about the system and
to make him familiar with it. His level of confidence must be raised so that
he is also able to make some constructive criticism, which is welcomed, as
he is the final user of the system.
SDLC METHDOLOGIES
This document play a vital role in the development of life cycle (SDLC) as it describes the
complete requirement of the system. It means for use by developers and will be the basic
during testing phase. Any changes made to the requirements in the future will have to go
through formal change approval process.
SPIRAL MODEL was defined by Barry Boehm in his 1988 article, “A spiral Model of
Software Development and Enhancement. This model was not the first model to discuss
iterative development, but it was the first model to explain why the iteration models.
As originally envisioned, the iterations were typically 6 months to 2 years long. Each
phase starts with a design goal and ends with a client reviewing the progress thus far.
Analysis and engineering efforts are applied at each phase of the project, with an eye toward
the end goal of the project.
The steps for Spiral Model can be generalized as follows:
The new system requirements are defined in as much details as possible. This
usually involves interviewing a number of users representing all the external or
internal users and other aspects of the existing system.
A preliminary design is created for the new system.
A first prototype of the new system is constructed from the preliminary design. This is
usually a scaled-down system, and represents an approximation of the characteristics
of the final product.
A second prototype is evolved by a fourfold procedure:
1. Evaluating the first prototype in terms of its strengths, weakness, and risks.
2. Defining the requirements of the second prototype.
3. Planning an designing the second prototype.
4. Constructing and testing the second prototype.
At the customer option, the entire project can be aborted if the risk is deemed too
great. Risk factors might involved development cost overruns, operating-cost
miscalculation, or any other factor that could, in the customer’s judgment, result in a
less-than-satisfactory final product.
The existing prototype is evaluated in the same manner as was the previous
prototype, and if necessary, another prototype is developed from it according to the
fourfold procedure outlined above.
The preceding steps are iterated until the customer is satisfied that the refined
prototype represents the final product desired.
The final system is constructed, based on the refined prototype.
The final system is thoroughly evaluated and tested. Routine maintenance is carried
on a continuing basis to prevent large scale failures and to minimize down time.
The following diagram shows how a spiral model acts like:
Fig 1.0-Spiral Model
ADVANTAGES:
Estimates(i.e. budget, schedule etc .) become more relistic as work progresses,
because important issues discoved earlier.
It is more able to cope with the changes that are software development generally
entails.
Software engineers can get their hands in and start woring on the core of a project
earlier.
INPUT DESIGN
Input design is a part of overall system design. The main objective during the input design is as
given below:
To produce a cost-effective method of input.
To achieve the highest possible level of accuracy.
To ensure that the input is acceptable and understood by the user.
INPUT STAGES:
The main input stages before the information gets stored in the database media:
Data recording
Data transcription
Data conversion
Data verification
Data control
Data transmission
Data validation
Data correction
OUTPUT DESIGN
Outputs from computer systems are required primarily to communicate the results of processing
to users. They are also used to provide a permanent copy of the results for later consultation. The
various types of outputs in general are:
External Outputs, whose destination is outside the organization.
Internal Outputs whose destination is with in organization and they are the
User’s main interface with the computer.
Operational outputs whose use is purely with in the computer department.
Interface outputs, which involve the user in communicating directly with
The outputs were needed to be generated as a hard copy and as well as queries to be
viewed on the screen. Keeping in view these outputs, the format for the output is taken from the
outputs, which are currently being obtained after manual processing. The standard printer is to
be used as output media for hard copies.
:
Automatic Reconfiguration for Large-Scale Reliable Storage
Systems
Purpose of the System:
Byzantine-fault-tolerant replication enhances the availability and reliability of
Internet services that store critical state and preserve it despite attacks or software errors.
However, existing Byzantine-fault-tolerant storage systems either assume a static set of
replicas, or have limitations in how they handle reconfigurations (e.g., in terms of the
scalability of the solutions or the consistency levels they provide). This can be
problematic in long-lived, large-scale systems where system membership is likely to
change during the system lifetime. In this paper, we present a complete solution for
dynamically changing system membership in a large-scale Byzantine-fault-tolerant
system. We present a service that tracks system membership and periodically notifies
other system nodes of membership changes. The membership service runs mostly
automatically, to avoid human configuration errors; is itself Byzantine fault- tolerant and
reconfigurable; and provides applications with a sequence of consistent views of the
system membership. We demonstrate the utility of this membership service by using it in
a novel distributed hash table called dBQS that provides atomic semantics even across
changes in replica sets. dBQS is interesting in its own right because its storage algorithms
extend existing Byzantine quorum protocols to handle changes in the replica set, and
because it differs from previous DHTs by providing Byzantine fault tolerance and
offering strong semantics. We implemented the membership service and dBQS. Our
results show that the approach works well, in practice: the membership service is able to
manage a large system and the cost to change the system membership is low.
EXISTING SYSTEM:
In Existing System, replication enhanced the reliability of internet services to
store the data’s. The preserved data to be secured from software errors. But, existing
Byzantine-fault tolerant systems is a static set of replicas. It has no limitations. So,
scalability is inconsistency. So, these data’s are not came for long-lived systems.
The existence of the following cryptographic techniques that an adversary cannot
subvert: a collision resistant hash function, a public key cryptography scheme, and
forward-secure signing key and the existence of a proactive threshold signature protocol.
PROPOSED SYSTEM:
In Proposed System, has two parts. The first is a membership
service (MS) that tracks and responds to membership changes. The MS
works mostly automatically,
and requires only minimal human
intervention; this way we can reduce manual configuration errors,
which
are
a
major
cause
of
disruption
in
computer
systems
periodically, the MS publishes a new system membership; in this way it
provides a globally consistent view of the set of available servers .
Reliable Automatic Reconfiguration
In this Module, it provides the abstraction of a globally consistent view of the
system membership. This abstraction simplifies the design of applications that use it,
since it allows different nodes to agree on which servers are responsible for which subset
of the service. It is designed to work at large scale, e.g., tens or hundreds of thousands of
servers. Support for large scale is essential since systems today are already large and we
can expect them to scale further.
It is secure against Byzantine (arbitrary) faults. Handling Byzantine faults is
important because it captures the kinds of complex failure modes that have been reported
for our target deployments.
Tracking membership Service
In this Module, is only part of what is needed for automatic reconfiguration. We
assume nodes are connected by an unreliable asynchronous network like the Internet,
where messages may be lost, corrupted, delayed, duplicated, or delivered out of order.
While we make no synchrony assumptions for the system to meet its safety guarantees, it
is necessary to make partial synchrony assumptions for liveness.
The MS describes membership changes by producing a configuration, which
identifies the set of servers currently in the system, and sending it to all servers. To allow
the configuration to be exchanged among nodes without possibility of forgery, the MS
authenticates it using a signature that can be verified with a well-known public key.
Byzantine Fault Tolerance
In this Module, to provide Byzantine fault tolerance for the MS, we implement it
with group replicas executing the PBFT state machine replication protocol.
These MS replicas can run on server nodes, but the size of the MS group is small
and independent of the system size. So, to implement from tracking service,
1. Add – It takes a certificate signed by the trusted authority describing the node
adds the node to the set of system members.
2. Remove – It also takes a certificate signed by the trusted authority that identifies
the node to be removed. And removes this node from the current set of members.
3. Freshness – It receives a freshness challenge, the reply contains the nonce and
current epoch number signed by the MS.
4. PROBE – The MS sends probes to servers periodically. It serves respond with a
simple ack, or, when a nonce is sent, by repeating the nonce and signing the
response.
5. New EPOCH – It informs nodes of a new epoch. Here certificate vouching for the
configuration and changes represents the delta in the membership.
Dynamic Replication
In this Module, to prevent attacker from predicting
1. Choose the random number.
2. Sign the configuration using the old shares
3. Carry out a resharing of the MS keys with the new MS members.
4. Discard the old shares
SYSTEM DESIGN
Data Flow Diagram / Use Case Diagram / Flow Diagram
The DFD is also called as bubble chart. It is a simple graphical
formalism that can be used to represent a system in terms of the input data to
the system, various processing carried out on these data, and the output data
is generated by the system
Dataflow Diagram:
Server
login
upload
files
Client
Login
request file
send to server
no
Membership
provider
files send
via router
file not
transfered
send report
yes
file request send
to server
once again
activate
membership
yes
no
check MS
Replica
Byzantine Fault
Tolerance
File transfer
.
SYSTEM STUDY
2.1 FEASIBILITY STUDY
The feasibility of the project is analyzed in this phase and business
proposal is put forth with a very general plan for the project and some
cost estimates. During system analysis the feasibility study of the
proposed system is to be carried out. This is to ensure that the proposed
system is not a burden to the company. For feasibility analysis, some
understanding of the major requirements for the system is essential.
Three key considerations involved in the feasibility analysis are
ECONOMICAL FEASIBILITY
TECHNICAL FEASIBILITY
SOCIAL FEASIBILITY
ECONOMICAL FEASIBILITY
This study is carried out to check the economic impact that the
system will have on the organization. The amount of fund that the company
can pour into the research and development of the system is limited. The
expenditures must be justified. Thus the developed system as well within the
budget and this was achieved because most of the technologies used are
freely available. Only the customized products had to be purchased.
TECHNICAL FEASIBILITY
This study is carried out to check the technical feasibility, that is,
the technical requirements of the system. Any system developed must not
have a high demand on the available technical resources. This will lead to
high demands on the available technical resources. This will lead to high
demands being placed on the client. The developed system must have a
modest requirement, as only minimal or null changes are required for
implementing this system.
SOCIAL FEASIBILITY
The aspect of study is to check the level of acceptance of the system
by the user. This includes the process of training the user to use the system
efficiently. The user must not feel threatened by the system, instead must
accept it as a necessity. The level of acceptance by the users solely depends
on the methods that are employed to educate the user about the system and
to make him familiar with it. His level of confidence must be raised so that
he is also able to make some constructive criticism, which is welcomed, as
he is the final user of the system.
SDLC METHDOLOGIES
This document play a vital role in the development of life cycle (SDLC) as it describes the
complete requirement of the system. It means for use by developers and will be the basic
during testing phase. Any changes made to the requirements in the future will have to go
through formal change approval process.
SPIRAL MODEL was defined by Barry Boehm in his 1988 article, “A spiral Model of
Software Development and Enhancement. This model was not the first model to discuss
iterative development, but it was the first model to explain why the iteration models.
As originally envisioned, the iterations were typically 6 months to 2 years long. Each
phase starts with a design goal and ends with a client reviewing the progress thus far.
Analysis and engineering efforts are applied at each phase of the project, with an eye toward
the end goal of the project.
The steps for Spiral Model can be generalized as follows:
The new system requirements are defined in as much details as possible. This
usually involves interviewing a number of users representing all the external or
internal users and other aspects of the existing system.
A preliminary design is created for the new system.
A first prototype of the new system is constructed from the preliminary design. This is
usually a scaled-down system, and represents an approximation of the characteristics
of the final product.
A second prototype is evolved by a fourfold procedure:
1. Evaluating the first prototype in terms of its strengths, weakness, and risks.
2. Defining the requirements of the second prototype.
3. Planning an designing the second prototype.
4. Constructing and testing the second prototype.
At the customer option, the entire project can be aborted if the risk is deemed too
great. Risk factors might involved development cost overruns, operating-cost
miscalculation, or any other factor that could, in the customer’s judgment, result in a
less-than-satisfactory final product.
The existing prototype is evaluated in the same manner as was the previous
prototype, and if necessary, another prototype is developed from it according to the
fourfold procedure outlined above.
The preceding steps are iterated until the customer is satisfied that the refined
prototype represents the final product desired.
The final system is constructed, based on the refined prototype.
The final system is thoroughly evaluated and tested. Routine maintenance is carried
on a continuing basis to prevent large scale failures and to minimize down time.
The following diagram shows how a spiral model acts like:
Fig 1.0-Spiral Model
ADVANTAGES:
Estimates(i.e. budget, schedule etc .) become more relistic as work progresses,
because important issues discoved earlier.
It is more able to cope with the changes that are software development generally
entails.
Software engineers can get their hands in and start woring on the core of a project
earlier.
INPUT DESIGN
Input design is a part of overall system design. The main objective during the input design is as
given below:
To produce a cost-effective method of input.
To achieve the highest possible level of accuracy.
To ensure that the input is acceptable and understood by the user.
INPUT STAGES:
The main input stages before the information gets stored in the database media:
Data recording
Data transcription
Data conversion
Data verification
Data control
Data transmission
Data validation
Data correction
OUTPUT DESIGN
Outputs from computer systems are required primarily to communicate the results of processing
to users. They are also used to provide a permanent copy of the results for later consultation. The
various types of outputs in general are:
External Outputs, whose destination is outside the organization.
Internal Outputs whose destination is with in organization and they are the
User’s main interface with the computer.
Operational outputs whose use is purely with in the computer department.
Interface outputs, which involve the user in communicating directly with
The outputs were needed to be generated as a hard copy and as well as queries to be
viewed on the screen. Keeping in view these outputs, the format for the output is taken from the
outputs, which are currently being obtained after manual processing. The standard printer is to
be used as output media for hard copies.
:
