1.1 Independence from the platform

In order to grant the community of a well done distributed backup system tool JDBS must be provided for each platform. To be smart and avoiding code replication e/o platform dependent uncoupled solutions we must think at JDBS as written in an interpreted language and demand the multi-platform requirement solution to such language. Thinking to the system in such terms, actually, doesn't offer other chances than use a Java solution.

1.2 Sharing disk's space availability between users

The simple idea that stays on the JSBS basis is: if a particular user wants to store his backups on other peers he (having the chance) must store someone else backups on his peer machine. This short explanation introduces some constraints on the system usage in fact it introduces the idea of a particular "quota" of available disk's space associated to a particular user. More the user wants to store more space the user must share to others. Another idea introduced by this formal requirement is that each backup has its life cycle, for example some data has to be retrievable for long periods (we are talking of data subject to law's constraints that must be stored for years rather than personal data that has a smaller life cycle). The system must provide a way to declare data obsolete after such a period in order to permit to the various involved peers to release the occupied space and declare as available space the one that was occupied before.

1.3 Secure data access and storage

Because we are not in a simple p2p context with simple idea of file sharing and open data access, the system, must provide a way to protect user's data. No one else, excluding the data's owner, must read, navigate or modify the stored data; peers are only seen as data repositories. To do that JDBS has to provide a way to encrypt data with a possible two-way symmetric and asymmetric key approach. The mentioned approach should obviously use an open algorithm to accomplish that security requirement; the basic idea is to encrypt each backup's content (file) with a symmetric key and than sign the backup artifact with an asymmetric algorithm approach. There are many symmetric and asymmetric algorithms that could be used. The security's problems on data managing that JDBS must solve and that are involved in this requisite are the typical: Availability, Integrity, Authenticity and Confidentiality.

1.4 Smart data upload and retrieval

JDBS should provide a light usage of network's resources and a well-done information retrieval basic architecture (this is needed to search stored data on peers). The system should also integrate a subsystem to plan data moving between the peer nodes, an example can be data moving during the nocturnal hours doing some considerations on the peer's geographic locations. Because the upload and retrieval are traffic intensive will be taken as a fact that each peer must have the availability of a medium or large bandwidth Internet connection; this problems doesn't seems to affect LAN users where assuming large bandwidths is not a so hard restriction.

1.5 An uncoupled and easy extendible component

Because of the imminent integration of JDBS in the InternetCafe project it should provide a well-defined set of interfaces and a well-done set of configurable parameters in order to make easy the component's usability by third party applications providing a flexible way to be extended by users and developers.

2.1 Functional requirements' analysis

Because of the clear explanation of such functional requirements in the previous section here will be placed a reference to the sections placed below in this document whose names are respectively "JDBS offline context" and "JDBS online context". Those sections will explain and analyze the static context associated to the offline utilization of JDBS and of the dynamic online context. Anyway the functional requirements for JDBS will be exactly the goals described in the previous requirements section excluding from those what is a not functional requirement that are be explained in the respective section that follows this one. A functional goal that must be described in this section is the one that refers to "Sharing disk's space availability between users" key. Because users will be able to upload their backup artifacts on other peers JDBS must grant and make safe the fact that each user will share a relative amount of disk's space to other users in the community. A good amount of space grant by default by each user should be quantized in order of percentage of available space on disk on the peer at the moment he will install JDBS. Anyway the user will have the obvious possibility to share space according with his machine configuration basing the amount of shared disk space also on some considerations about the user's created backup's size. Anyway JDBS will reside on the basis of a trustworthy network of participants so it is a fact that if any user will not share available space to the community this happens because he really doesn't have such space to share.

2.2 Not functional requirements' analysis

Looking at the previous section can be found and underlined some not functional requirement that JDBS must respect in order to obtain a successful coverage of each requisite. According with what has been previously explained the keys not functional requirements are independence from the platform that introduces a clean usage of Java as paradigm and programming language and another requirements will be intend JDBS as a component to integrate into a bigger system or software application. Because the context of application of JDBS is the Internet community and because each user has his own set of skills and language should be thought the possibility to introduce another requirement: the multi-language support.

2.3 Glossary

In this section we will present a short description for each term found in the previous requisites document. This is done to avoid the possibility to misunderstand a term when we are using it in the following sections.

2.4.1 Encrypt backup content with a symmetric cryptographic approach

The main role of this symmetric encryption utility will be to realize a secure, password based, encryption of each file present in a backup artifact. To do so the utility must provide in input a user's password and one or more files in order to output an encrypted or decrypted version depending of the encrypted or plain form of such an input file. A figure that represents a block vision of such a until is presented above:

The first block presented in the figure represents the case in which a file is passed in input and it is in plain form, once the user has provided his password the file will be encrypted whit it and the block outputs it in ciphered form. The Encrypted file will be no more accessible if not to the user's owner. The second block represents the opposite case in which the input file is encrypted and the output of the block (if the user's provided password is valid) is the "plain" form of the file.

2.4.2 Signing backup artifacts with an asymmetric cryptographic approach

Because we have learned that JDBS will be implemented in JAVA to satisfy the not functional requirement described in a previous section we must search here if something is still available to perform such signing facility on such development platform. Thanks to some search on Internet we found a valid and usable already done implementation of the RSA algorithm in the JCE (Java Cryptography Extension) and we think it will be suitable for the purpose. RSA should be easy to use in our case but few problems remains not defined in our domain. Because a pair of RSA public key and private key can be generated on demand by JDBS we must define some rules or best practices to do it. The problems that in this first analysis can be found are:

• Once we have generated a key-pair where we must store the private key in order that it will remains totally secure?
• Where we must store the RSA public key in order to left it easily accessible by JDBS?
• How many bits are involved (1024, 2048) with such key-pair generation? What is sure is that such a problem also involves the backup's specific life cycle.
• According to the most suitable configuration taken, what are the timings of backup artifacts signing?

What is sure at this time is that JDBS must provide a way to sign backup artifacts after a symmetric encryption of such backup data (contained files) and there will be a component whose role is doing that. A block vision of such asymmetric cryptographic utility is presented in the above figure:

The first block shows how the Backup Artifact will be signed and the second block shows how will be checked the sign against a provided public key. The presented problems will be taken in consideration when we will start the project phase for now those problems must not be taken in consideration.

2.4.3 File compression utility

Its obvious that the chosen platform will permit a compression of user data treating it as files but it is not obvious what kind of compression algorithm must be used in JDBS, has it to remain as a user's choice? Some well-known algorithm can be the Zip, Gzip, tar etc. A decision on how JDBS will work with such algorithms will be taken in consideration as soon as the project phase will start. In the above figure is presented a block vision of such compression utility:

The block in the figure shows that the component takes in input a compression algorithm and some files or folders that must be compressed with such an algorithm.

2.4.4 Global unique identifier generator

Because any user will have its set of local and distributed backups JDBS must implement a sort of sub-component that realizes a so-called GUID generator. The problem subsists because can be found some easy cases of backup's name overlaps. Think at the scenario in which two users uploads on another peer two backups with the same name, this fact will be surely dangerous for both users making inconsistent one or both of those backup artifacts. The problem doesn't occur during the upload process but it is evidenced during the backup's retrieval one! A good naming strategy for user's backup artifacts could be something that makes the backup unique in the JDBS network and not only inside a peer's neighborhood. Well, a probably good identification of a GUID in JDBS can be obtained granting to users the chose of their own names for backup's artifacts and demand directly to JDBS the creation of unique identifiers. A good pattern should be use a hash function (also if it doesn't prevents overlaps) applied to the user's chosen backup's name to assign a name to the backup file. Its also possible, because we have a unique user's nickname to create a folder on every peer found in the neighborhood named equally to the user's nickname. In the above figure is placed a block vision of such utility:

2.5.1 Peers' discovery protocol

Because JDBS is a totally distributed network of peers probably will be useful to find a pre existing environment or middleware rather than define a new discovery protocol. Because in p2p context the problems to affront are ever and ever the same (discovery, peers searches, group management, etc?) will be better use a well-done and already tested system rather than project a new one from zero. The peers' discovery protocol will probably reference the JXTA one but for now we must concentrate on other more relevant things passing such a problem or chose to the JDBS project section.

2.5.2 Backup storage on peers protocol

The following subparagraphs and figures show a network context with some discovered peer machine during an online backup's upload process. The backup storage on peer machines protocol requires in order to be done of an already valid JDBS backup file. To grant this prerequisite the user has previously built trough JDBS a backup artifact whose file content is encrypted with the user's RSA private key. This process substantially consists of 3 different phases:

1. The free space request phase;
2. The free space response phase;
3. The upload phase.

For each phase will be given a detailed description in the above paragraphs.

2.5.3 Backup retrieval protocol

The following subparagraphs and figures show a network context with some discovered peer machine during an online backup's retrieval process. This process is made of 5 phases:

1. The lookup request phase.
2. The lookup response phase.
3. The ownership check request phase.
4. The ownership check response phase.
5. The download phase.

For each phase will be give a detailed description in the above paragraphs.

2.5.3.1 Lookup request phase

This is the first phase of the retrieval protocol in which the user after he has provided a search key for the backup of interest and his RSA public key asks to every peer in the neighborhood if he has a valid entry for such searched backup artifact.

This phase is the entry point for the "Backup retrieval protocol" and provides the stage in which a user starts searching for his (presumably) backup artifact. How can be done a searching string for that backup has been described previously in the section named "JDBS offline context". In this phase can occur unfortunately the major problems because if no peer has been found in the neighborhood the user can't retrieve his backup and unfortunately this is a not completely solvable problem (the user should use his local backup copy ?) because the only opportunity is to try to search again for those peers that contains the searched backup artifact. Anyway once this phase has been performed the retrieval protocol can proceed.

2.5.3.2 Lookup response phase

This is the second phase of the retrieval protocol. In this phase the user's peer is waiting for other peers responses, those responses will indicate peers where the user's backup artifact has been localized and from which it can be restored (downloaded).

As described in the previous protocol's phase if no answer from the JDBS network or from the neighborhood is received the protocol fails and no solution can be taken rather than use the local backup copy (ever if it exists).

2.5.3.3 Ownership check request phase

This protocol's phase is the one that should grant security and prevent abuse of peer's connection bandwidth. Once the previous phase has been accomplished successfully and the user has provided JDBS with his asymmetric private key (note that this is a prerequisite of that protocol) JDBS will try to send a private key's encrypted packet of data to the chosen peers. Doing so each peer can check the identity of the user checking the encrypted data against the asymmetric public key associated to the backup artifact the user want to retrieve. A figure that represents this protocol phase is placed below:

Locally to each peer machine (in the figure those machines are Peer Node 2 and 4) will be checked the encrypted data sent against the backups' associated public key so the authenticity of the user will be exactly checked granting also the backup file's integrity property. Forgetting for now the network problems that can occurs no other error can occur in this phase.

2.5.3.4 Ownership check response phase

The main role of this phase is to send a sort of "yes" or "not" response to the peer node that has started the protocol (Peer Node 1 in the figure placed below). At this point if the user has provided a correct encrypted data packet and the receiver node has correctly checked it using the user's public key associated to the artifact the phase is considerable terminated successfully and the protocol can proceed to the next phase otherwise some problems can occur. A figure of this context is placed below:

The possible configurations or states that are cause of inconsistency in this phase can be:

• The provided encrypted data packet doesn't match with the backup associated user's public key.
• Some peers return a "not" response and someone else returns a "yes" one.

In the first case is possible that the user is not the real backup's owner and so will be not grant the download possibility otherwise can occur that the backup's integrity has not been preserved and unfortunately there is no way to recover that backup (probably should be gave the opportunity to delete such inconsistent backup to the user in the case of file corruption or just wait for the attainment of the backup's life cycle end making such backup obsolete).

In the second inconsistent context probably the backup on those peers that has responded with a ?not" response are corrupted. The user can download his backup from the rest of available nodes.

2.5.3.5 Download phase

Once the previous phases are been accomplished successfully the download phase from a user's selected peer can be performed and the backup can be saved in the local user's repository as shown in the following figure.

The only problems that can occur in this phase are linked to typical and well-known network's problems.

2.6.1 Use Case - Backup artifact creation

The goal of the use case presented in the following figure is to show how a JDBS user can create a new backup artifact providing JDBS with a list of files that must be backupped (this will be the backups' data), a symmetric password (used to encrypt the backups' data) and an asymmetric private key (used to sign the backup artifact).

In the following paragraphs will be placed a complete set of scenarios that regards this particular use case.

2.6.1.1 File selection

2.6.1.2 Chose a symmetric password

2.6.1.3 Chose a private key

2.6.1.4 File encryption

2.6.1.5 File compression

2.6.1.6 GUId assignment

2.6.1.7 Sign the backup artifact

2.6.1.8 Local storage

2.6.2 Use Case - Distributed backup storage

The role of this use case is to show how a backup previously stored in the user's local repository can be uploaded to other peers reaching the goal of distributed storage. This use case, as described in the scenarios that follow, is accessible only after a valid backup creation; such creation is described in the relative use case.

In the following paragraphs will be placed a complete set of scenarios that regards this particular use case.

2.6.2.1 Backup selection

2.6.2.2 Life cycle and replication degree definition

2.6.2.3 Neighbourhood search

2.6.2.4 Peers selection

2.6.2.5 Backup upload

2.6.3 Use Case - Distributed backup retrieval

This use case shows how a user can retrieve a copy of a backup from the JDBS network. As previously described in the paragraph "Backup retrieval protocol? must be satisfied some preconditions before a backup download can be started; the main prerequisite is the backup ownership.

In the following paragraphs will be placed a complete set of scenarios that regards this particular use case.

2.6.3.1 Search key definition

2.6.3.2 Neighborhood search

2.6.3.3 Provide a private key

2.6.3.4 Backup download

3.1 Problem Analysis

From the requirements analysis we can state that JDBS is a feasible system because is similar to most of p2p applications available nowadays. Because of its intrinsic possibility to be used as a stand-alone application or as a subsystem of InternetCafe and because that application provides a graphical user interface, JDBS must provide a GUI too. According to that we can state that such GUI has to provide a way to easily manage the business logic placed on the bottom. The business logic will provide a way to manage the domains' entities such as users, backups and network offering and making easily accessible all that functions and systems' behaviors evidenced in the requirements analysis. A possible layered view of JDBS is placed in the figure placed above:

The role that the Graphical User Interface Layer will play in the system will present to the applications' user a compact systems' vision, otherwise, the Business Logic Layer will represent the systems' core offering all the systems' functionalities. The arrow placed between those layers refers to the possibility to have an layers' interaction; in fact, the GUI has to be updated when the business logic changes and the Business Logic must receive by the GUI such users' provided parameters and runtime configurations.

3.2 Structural Analysis

Stated that JDBS must be provided of a GUI that plays an architectural role as a presentation layer other layers can be found providing an uncoupling of the previously mentioned Business Logic Layer. The business layer can be divided into other layers:

• Static layer whose role will be to provide access to entities with static and immutable behaviors or characteristics (user, backup and static components or utilities).
• Execution (or Dynamic) layer that will represent the system execution offering a runtime support to the application interactions.
• Network layer whose role will be the management and the control of the network behaviors (JDBS network vision, peer node management, connections).

A figure that represents the structural vision of JDBS is placed above, note that are not specified the layer interactions that will be explained extensively in another section:

In the above paragraphs will be explained the role that each layer plays in JDBS.

3.3 Behavioral Analysis

Rather than other functional behaviors here must be described the JDBS support to the user during the download and upload actions. As mentioned in the requirements analysis (scenario 00012) the system must integrate a component that manages the scheduling of network operations placing and executing them in background. At this time must be thought the impact of a sub-component like that because it introduces a sort of automation that is a systems' behavior. The network scheduler (as it can be named) must provide at fixed interval rate a network exploration and must perform planned downloads or uploads of backup artifacts according with the user requests and configurations. To do so an automatic backups' search engine must be provided and it must be coordinated with the scheduler in order to reach the scheduled goals.

3.4 Interaction Analysis

In this section will be explained the users' interactions and the system inner-interactions between software layers. First of all for us interaction means a way to provide an input and wait for an output, such an output can be also hidden by the system. As described in the use cases presented in the requirements analysis the user will interact with JDBS trough the UI. The UI will provide the facilities described in the previous paragraphs and it should be managed according to a sort of pattern MVC (Model View Controller). The classical schema relative to MVC is presented below:

The presented diagram means that the User will interact with the View that takes data from the Model and it is updated from the Controller. The Controller itself receives solicitations from the View trough the inputs provided by the user and providing updates to the Model. According to that we must define what layers matches such abstract representation. Its obvious that the View represents the GUI layer otherwise the Controller is the Execution layer and the Model is relative to both the static and network layers. To provide this kind of interaction must be thought a data format or an interchange format with which the various layers will communicate; this aspect will be part of the project and will be extensively described there.

3.5 Risks Analysis

4.1 Detailed architectural view

A abstract but more reach architectural view of JDBS is placed in the above figure; in the following paragraphs will be better-defined trough a consecutive and incremental specification of functionalities and individuated roles a more detailed representation of each software component:

5.1 Projects choices

5.2 Patterns

5.3 System structure

5.4 System behaviours

5.5 System interactions