Proj-2013-2014-Open DynDNS/SRS: Difference between revisions

From air
Jump to navigation Jump to search
No edit summary
 
(27 intermediate revisions by the same user not shown)
Line 41: Line 41:
| [[User:Thomas CALMANT|Thomas Calmant]]
| [[User:Thomas CALMANT|Thomas Calmant]]
| 18/2/2014
| 18/2/2014
|}
|
|-
!scope="row" |
| 1.0.0
| 20/3/2014
| [[User:Lionel BOEY|Lionel Boey]]
| Completed version
| [[User:Thomas CALMANT|Thomas Calmant]]
| 21/3/2014
|
|-
}




Line 58: Line 69:
* BIND : Berkeley Internet Name Domain
* BIND : Berkeley Internet Name Domain
* REST : Representational state transfer
* REST : Representational state transfer
* MDNS : Multicast DNS
* JSON : JavaScript Object Notation
* JSON : JavaScript Object Notation


Line 64: Line 76:
*Kivy : open source Python library for developing multitouch application software with a natural user interface (NUI).
*Kivy : open source Python library for developing multitouch application software with a natural user interface (NUI).
*Flask : A lightweight web application framework written in Python
*Flask : A lightweight web application framework written in Python
*Zeroconf : Short for zero configuration IP networking, a method of networking devices via an Ethernet cable without requiring configuration and administration.


==1.4 References==
==1.4 References==


* [http://flask.pocoo.org/ FLASK] : Tutorials on Flask API and its REST-ful methodes
* [http://flask.pocoo.org/ FLASK] : Tutorials on Flask API and its REST-ful methodes
* [https://github.com/mcfletch/pyzeroconf pyZeroconf] : Zeroconf modules and mDNS implementations
* [http://en.wikipedia.org Wikipedia] : General definitions on various notions
* [http://en.wikipedia.org Wikipedia] : General definitions on various notions
* [http://kivy.org/#home Kivy] : Quickstart guide on Kivy on Android tablettes
* [http://kivy.org/#home Kivy] : Quickstart guide on Kivy on Android tablettes
* [https://help.ubuntu.com/community/BIND9ServerHowto UbuntuForums] : Bind9 server set-up and configurations
* [https://help.ubuntu.com/community/BIND9ServerHowto UbuntuForums] : Bind9 server set-up and configurations
* [http://mqtt.org/wiki/doku.php/start MQTT] : Tutorial on MQTT
* [http://www.whatismyip.com/ WhatsMyIP] : Various network diagnostic tools
* [http://www.whatismyip.com/ WhatsMyIP] : Various network diagnostic tools


Line 87: Line 100:
The daemon/server couple shoule be capable of deploying into any traditional network. For each version of the project :
The daemon/server couple shoule be capable of deploying into any traditional network. For each version of the project :
* '''Public'''
* '''Public'''
a) Daemon : public wifi network
-Daemon -> public wifi network.

b) Server : any public ISP subscription network
-Server -> any public ISP subscription network.

The daemon on the client side makes use of various IP detecting websites to determine the correct public IP address of itself.

[[File:Context.png]]

* '''Local'''
-Daemon and client -> any traditional network of a small company

mDNS clients are installed on each participating machine in the multicast network for the distributed protocole to function. It should be reminded that mDNS is installed above a standard internal DNS system and therefore the updates should be taken into account by the DNS server.


==2.2 Product functions==
==2.2 Product functions==
This subsection of the SRS should provide a summary of the functions that each version of the software will perform :

* '''Public'''
The daemon/server couple will communicate with each other to update periodically the dynamic IP address of the client-side daemon. This update is stored into a FLASK webserver (JSON format) and also directly into the database files of the bind9 DNS server

* '''Local'''
When a newly arrived client or service server arrives on the network, it should be able to locate the DNS servers immediately and sends a REST update to the said DNS server with its new local IP address. From then onwards, the client running the daemon will be accessible by anyone in the network.

The client also automatically sends a REST update when it leaves the network.


Let it be known that the connection between server and client is protected with and SSL connection. Updates are sent securely on any network while the identity of the client will be always be verified.

If UPnP is enable on this network, any external user will be able to resolve DNS names to all the machines in the private multicast network.

==2.3 User characteristics==
==2.3 User characteristics==
There are 2 main groupe of user that interacts with the system :

'''Administrator'''
Admins should have basic knowledge of DNS configurations and basic Python understanding, as initial domain configurations are required in Bind9 and hosts should be manually declared beforehand in the REST webserver to prevent unwanted hosts adding themselves to the domain


'''Clients'''
Clients should be able to install Kivy and the daemon on their respective devices such as tablets and laptops.

==2.4 General constraints==
==2.4 General constraints==
==2.5 Assumptions and dependencies==
==2.5 Assumptions and dependencies==
*'''Assumptioms'''
- UPnP are most likely disabled on any public network and routers of a small private network of a company

- HTTP requests (GET, PUT, POST) are enabled on most public wifi network and small private network of a company

- DNS queries are enabled on any network


=3.Specific requirements, covering functional, non-functional and interface requirements=
=3.Specific requirements, covering functional, non-functional and interface requirements=
Line 127: Line 180:
- Android tablette (Nexus 10)
- Android tablette (Nexus 10)
- 2 machine running on Linux
- 2 machine running on Linux
- Routers must set-up port forwarding for HTTP and DNS


*Software
*Software
- Ubuntu desktop
- Ubuntu desktop

- MQTT sensors
- mDNS daemons

- Flask API and Flask REST-ful
- Flask API and Flask REST-ful

- Kivy
- Bind9
- Liclipse for Python




'''Post-condition''':
'''Post-condition''':
* User must be situated in a foreign network with different public IP address before launching the daemon
* PUBLIC : User must be situated in a foreign network with different public IP address before launching the daemon
* LOCAL : User must just have a machine (zeroconf)





Latest revision as of 14:45, 9 April 2014

The document provides a template of the Software Requirements Specification (SRS). It is inspired of the IEEE/ANSI 830-1998 Standard.


Read first:

}

1. Introduction

1.1 Purpose of the requirements document

The purpose of this Software Requirement Document (SRS) is to provide detailed overview of our 4th year RICM project called Open DynDNS. Being an open-source project, this document can be used as a guideline and reference to potentiel future contributors and designers to take part in software delivery lifecycle (SDLC) processes.

In short, this document defines how our client, team and our tutor see the product and its functionality by understanding the user interface, hardware and software requirements.

1.2 Scope of the product

  • This project aims to provide open-source DNS solution for end-users who often find themselves in changing network environment (Dynamic IP address, hostname etc)
  • These users would like to dynamically configure their own DNS server and make their servers accessible from the said network

1.3 Definitions, acronyms and abbreviations

  • DNS : Domain Name System
  • BIND : Berkeley Internet Name Domain
  • REST : Representational state transfer
  • MDNS : Multicast DNS
  • JSON : JavaScript Object Notation


  • Kivy : open source Python library for developing multitouch application software with a natural user interface (NUI).
  • Flask : A lightweight web application framework written in Python
  • Zeroconf : Short for zero configuration IP networking, a method of networking devices via an Ethernet cable without requiring configuration and administration.

1.4 References

  • FLASK : Tutorials on Flask API and its REST-ful methodes
  • pyZeroconf : Zeroconf modules and mDNS implementations
  • Wikipedia : General definitions on various notions
  • Kivy : Quickstart guide on Kivy on Android tablettes
  • UbuntuForums : Bind9 server set-up and configurations
  • WhatsMyIP : Various network diagnostic tools

1.5 Overview of the remainder of the document

The following parts of this document provide a general description of the project.

Section 2 describes the characteristics of the users of this application, some of the constraints encountered while working on the project and a few assumptions and dependencies made by the developers

Section 3 provides primarily technical documentations for developers such as the hardware used for this application, the functional requirements, data requirements and constraints and assumptions made while designing and implementing the Open DynDNS solution.  It also gives the user viewpoint of product.  Section 4 is for supporting information.

2. General description

This section of the SRS should describe the general factors that affect 'the product and its requirements. It should be made clear that this section does not state specific requirements; it only makes those requirements easier to understand.

2.1 Product perspective

The daemon/server couple shoule be capable of deploying into any traditional network. For each version of the project :

  • Public

-Daemon -> public wifi network.

-Server -> any public ISP subscription network.

The daemon on the client side makes use of various IP detecting websites to determine the correct public IP address of itself.

Context.png

  • Local

-Daemon and client -> any traditional network of a small company

mDNS clients are installed on each participating machine in the multicast network for the distributed protocole to function. It should be reminded that mDNS is installed above a standard internal DNS system and therefore the updates should be taken into account by the DNS server.

2.2 Product functions

This subsection of the SRS should provide a summary of the functions that each version of the software will perform :

  • Public

The daemon/server couple will communicate with each other to update periodically the dynamic IP address of the client-side daemon. This update is stored into a FLASK webserver (JSON format) and also directly into the database files of the bind9 DNS server

  • Local

When a newly arrived client or service server arrives on the network, it should be able to locate the DNS servers immediately and sends a REST update to the said DNS server with its new local IP address. From then onwards, the client running the daemon will be accessible by anyone in the network.

The client also automatically sends a REST update when it leaves the network.


Let it be known that the connection between server and client is protected with and SSL connection. Updates are sent securely on any network while the identity of the client will be always be verified.

If UPnP is enable on this network, any external user will be able to resolve DNS names to all the machines in the private multicast network.

2.3 User characteristics

There are 2 main groupe of user that interacts with the system :

Administrator Admins should have basic knowledge of DNS configurations and basic Python understanding, as initial domain configurations are required in Bind9 and hosts should be manually declared beforehand in the REST webserver to prevent unwanted hosts adding themselves to the domain


Clients Clients should be able to install Kivy and the daemon on their respective devices such as tablets and laptops.

2.4 General constraints

2.5 Assumptions and dependencies

  • Assumptioms

- UPnP are most likely disabled on any public network and routers of a small private network of a company

- HTTP requests (GET, PUT, POST) are enabled on most public wifi network and small private network of a company

- DNS queries are enabled on any network

3.Specific requirements, covering functional, non-functional and interface requirements

  • document external interfaces,
  • describe system functionality and performance
  • specify logical database requirements,
  • design constraints,
  • emergent system properties and quality characteristics.

3.1 Requirement X.Y.Z (in Structured Natural Language)

Function: To dynamically updates the public IP address of a host on a DNS server whenever the host is mobile and is located in a foreign network

Description: Implement an open source dynamic DNS server and demon to run on various device (PC, laptop, Android tablet etc)

Inputs: Dynamic IPs

Source: Users who host their websites or depositories behind a router/modem with dynamic IP

Outputs: Dynamic DNS updates

Destination: Open DynDNS server

Action:

  • Open DynDNS client must notify OpenDynDNS server whenever it detects a change in IP adress on the host
  • Open DynDNS server updates shall not be modified by non-recognizable device

Non functional requirements:

  • Open DynDNS client may be run on various device such as a laptop, PC or an Android tablet.

Pre-condition:

  • Hardware

- Raspberry PI - Android tablette (Nexus 10) - 2 machine running on Linux - Routers must set-up port forwarding for HTTP and DNS

  • Software

- Ubuntu desktop

- mDNS daemons

- Flask API and Flask REST-ful

- Bind9


Post-condition:

  • PUBLIC : User must be situated in a foreign network with different public IP address before launching the daemon
  • LOCAL  : User must just have a machine (zeroconf)


Side-effects:

4. Product evolution

5. Appendices

6. Index

Document History
Version Date Authors Description Validator Validation Date
0.1.0 27/1/2014 Lionel Boey Projet requirement Thomas Calmant 28/1/2014
0.1.1 10/2/2014 Lionel Boey Overview of project Thomas Calmant 11/1/2014
1.0.0 17/2/2014 Lionel Boey Preliminary contract Thomas Calmant 18/2/2014
1.0.0 20/3/2014 Lionel Boey Completed version Thomas Calmant 21/3/2014