SRS BKGROUND

1

Software Requirement

Specification

Publish/Subscribe System

BKGROUND

Group-03

Atul Jangra 2010CS50277

Dushyant Behl 2010CS50282

Shantanu 2010CS50295

Utkarsh 2010CS50299

SRS BKGROUND

2

Table of Content

1. Introduction

1.1 Purpose............................................................................................... 4

1.2 Motivation............................................................................................ 4

1.3 Scope.................................................................................................. 4

1.4 Glossary............................................................................................... 4

1.5 Overview.............................................................................................. 4

2. Overall Description

2.1 Product Perspective

2.1.1 System Interface........................................................................ 6

2.1.2 User interface............................................................................ 7

2.1.3 Hardware Interface..................................................................... 7

2.1.4 Software Interface...................................................................... 7

2.1.5 Communication Interfaces.......................................................... 8

2.1.6 Memory Constraints................................................................... 8

2.1.7 Operations…............................................................................. 8

2.2 Product Functions

2.2.1 Context Diagram....................................................................... 9

2.2.2 Use Case Diagram................................................................... 10

2.2.3 Application Features…............................................................... 11

2.3 User Characteristics.......................................................................... 11

2.4 Constraints........................................................................................ 11

2.5 Assumptions and Dependencies....................................................... 11

3. Specific Requirements

3.1 External interface

3.1.1 Terminal Client Interface.............................................................. 12

3.1.2 User Management Interface......................................................... 13

3.1.3 Account Creation......................................................................... 13

3.2 Functional Requirements

3.3.1 System Management................................................................. 14

3.3.2 System Monitoring..................................................................... 14

3.3.3 Account Creation.................................................................... 15

3.3.4 Account Removal...................................................................... 16

3.3.5 Session Creation/Authorisation................................................... 17

3.3.5 Message Sending ..................................................................... 17

3.3 Performance Requirements............................................................... 19

3.4 Logical Database Requirements........................................................ 20

SRS BKGROUND

3

3.6 Design Constraints ............................................................................ 20

3.5 Software System Attributes................................................................ 20

3.6.1 Reliability............................................................................................ 20

3.6.2 Availability.......................................................................................... 20

3.6.3 Security............................................................................................. 21

3.6.4 Maintainability.................................................................................... 21

3.6.5 Portability........................................................................................... 21

3.7 Organising Specific Requirements..................................................... 21

SRS BKGROUND

4

1.0. Introduction

1.1. Purpose

The purpose of this document is to present a detailed description of a

publish/subscribe system, BKGROUND. It will explain the purpose and features of the

system, the interfaces of the system, what the system will do, the constraints under

which it must operate and how the system will react to external stimuli. This document is

intended for both the stakeholders and the developers of the system.

1.2. Motivation of Project

As the number of mobile devices is increasing, the number of users expressing

interest in pub-sub system is increasing. To deal with the ever increasing demand of the

users, a robust middleware software system is required which would be capable of

handling the large number of users and, capable of scaling horizontally to keep the

service cost effective.

1.3. Scope of Project

This software system will be a middleware system for providing the pub-sub

service. It will be designed to deliver published content to the users who have

subscribed to it. The system will use a unique identification such as username to identify

the users on terminal servers and then push content to the devices affiliated with that

username. This project will enable users to get access to content which is according to

their interest as well as it provides a platform to content publishers for reaching users.

The project aims at developing this middleware independent of the operating system

platform. The middleware is concerned with the content delivery aspect to the

subscribers.

1.4. Glossary

Java NIO: Java New I/O, usually called NIO, is a collection of Java programming

language APIs that offer features for intensive I/O operations

Pub/Sub: A publish subscribe system that delivers messages to a large group of users

subscribed to a particular topic

Middleware: Middleware is computer software that connects software components or

some people and their applications

Admin User: Administrator of the system

SRS BKGROUND

5

Terminal User: The subscribing user who will receive the messages and broadcast

messages to specific rooms with permissions

1.5. Overview

The next chapter, the Overall Description section, of this document gives an overview of

the functionality of our system BKGROUND. It describes the informal requirements and

is used to establish a context for the technical requirements specification in the next

chapter.

The third chapter, Requirements Specification, of this document is written primarily for

the developers and describes in technical terms the details of the functionality of the

system.

Both sections of the document describe the same software system in its entirety,

But are intended for different audiences and thus use different language.

2.0. Overall Description

2.1 Product Perspective

This publish-subscribe pattern based middleware system relies on Java NIO API for

implementation. This system will be used by enterprises for a variety of purposes such

as data-push services, pub/sub broadcast services or any other service which needs

multicasting messages to millions of users simultaneously. The system can

simultaneously be used for a chat type application, where users would want to send real

time text-based messages to each other.

The system will be a layered-clustered environment capable of scaling each layer

individually as depicted in the following schematic:

SRS BKGROUND

6

Figure 1: Schematic for the server design.

2.1.1. System Interface

The system being developed will consist of the software application that will be

running on the virtual/real hardware. The user of this system will need to follow the

following steps:

● Arrange the desired hardware for the server system in the three layers, virtual or

real.

● Connect the hardware together in an overlay network.

● Run the Java based programs on the terminal, data forwarding, and the data

processing layers.

● Use an admin machine to monitor the working of the server system.

SRS BKGROUND

7

2.1.2. User Interface

The primary user of this system will be the middleware administrator who will monitor

the system’s working and hence the user interface would be consist of the following.

● Options to view the live throughput across different data layers.

● Interface to view data throughput, connection counts and load monitoring for all

the servers.

● Option to monitor a particular server periodically and also to take down a server

in maintenance mode.

● Interface to replace a particular server with another server.

● Interface to add/remove new set of servers to a particular layer.

● Interface to control the connections of a server in any layer to the servers of the

other layers.

2.1.3. Hardware Interface

The Hardware involved in this system will be a set of real or virtual servers. This

system will be compatible with virtual hardware services such as Amazon EC2

instances.

2.1.4. Software Interface

○ The system has software interfaces spread across different layers of the system.

○ The servers in different layers will be running software developed in JAVA on

Linux based operating system.

○ The administrator shall have a web based monitoring system so as to monitor the

server system of BKGROUND.

2.1.5. Communication Interface

The system will need a variety of communication interfaces:

● Communication between various parts of the clustered environment. This

will be using TCP sockets to maintain the necessary communication.

● Communication of the system with the various users. More precisely,

connection of the terminal server layer (Figure 1) with the users. This

connection will be created by using java.net.ServerSocket and

java.net.Socket from the Java NIO API and will also be based on TCP

sockets.

SRS BKGROUND

8

2.1.6. Memory Constraints

● Terminal Servers: The terminal nodes requires connecting to a target of over 1

Million clients simultaneously and hence the memory consumed in establishing

connection to the clients must not be large so as to prevent overflowing the

memory limit of the system.

● Data Processing/Data Forwarding Servers: The nodes in these layers should be

memory efficient in such a way so as to handle maximum connections for the

same memory limit. The memory limit here should be kept low so as to prevent

the systems from thrashing.

● Admin End: The Administrator system will be running a simple web server for

helping in management of the system, which will not be memory intensive and

hence no specific memory requirements for this.

2.1.7. Operations

1. Terminal User Operations

● Create a new account - The user should be able to link existing third party

accounts with his existing account, or create a new account in BKGROUND,

using username and password as credentials.

● Manage Sessions - The user should be able to disconnect any existing session

remotely, if he can’t logout from the session from the Terminal Client.

● Authorize Persistent Socket - The user has to authorize himself on starting a new

connection on a terminal server, using a service name, with his secret key

(OAuth 2, in case of third party authorization). The user with this secret key must

be already registered on the system.

● Send Message - The user can send message to another user, or a pub/sub room

(if he has publishing permissions for the room).

2. Administrative User Operations

● Add a new server - Add a server instance in any layer on the already deployed

system.

● Replace a server - Replace an existing server in the deployment for upgrading

with zero-downtime.

● Get traffic information on any server

● Get number of clients connected on any terminal server

2.2. Product Functions

The BKGROUND system aims to be a pub/sub system, and an XML based chat system

at the same time. Any client that is connected on a terminal server is guaranteed to

receive both types of messages, message published in rooms that he is subscribed to,

SRS BKGROUND

9

and messages sent to him directly. The client can have multiple simultaneous sessions,

so that any message that is sent to him is received on all devices connected using his

credentials.

2.2.1 Context Diagram

Figure 2.2.1.1

SRS BKGROUND

10

2.2.2. Use Case Diagram:

Figure 2.2.2.1

Figure 2.2.2.2

SRS BKGROUND

11

2.2.3. Application Features:

Terminal User

● The user can create a new account, or connect using a third party account like

Twitter, Facebook or Google.

● The user can send messages to a specific user.

● The user can subscribe to various rooms which will be listed on the client-side

application.

● The user can sign in using one of multiple third party accounts registered with his

username.

Admin Interface User

● The user can view the live throughput across different data layers.

● The user can view data throughput, and connection counts for all the servers.

● The user can monitor a particular server periodically and also to take down a

server in maintenance mode.

● The user can replace a particular server with another server.

● The user can add/remove new set of servers to a particular layer.4

● The user can control the connections of a server in any layer to the servers of the

other layers.

2.3. User Characteristics

The user in our system will be the System administrator of the enterprise using

this system. This the user is required to know some basic shell scripting, networking

and should be able to monitor the load of different servers used in the clustered

environment.

2.4 Constraints

The major constraints in this project would be the availability of hardware. Decent

amount of hardware is needed for the testing of BKGROUND.

2.5 Assumptions and Dependencies

We are assuming that the user will be able to tweak his Linux kernel to allow maximum

number of sockets that can be created from the Machine.

The software also depends on Java NIO APIs. If the API is modified then the developer

will have to edit the software to make it compatible with the latest API.

SRS BKGROUND

12

3.0. Specific Requirements

3.1. External Interface

The system has three primary interfaces -

● Terminal Clients - The users of the pub/sub system who will maintain a

persistent socket connection to the deployed system. Any message that needs to

be sent to the group of subscribed users, and / or a single user will have to be

sent on this persistent socket connection.

● User Management Interface - This is a set of web APIs in BKGROUND system,

through which new users may be registered, a particular user may manage

sessions, a user may be unregistered, etc.

● Administrative Interface - The BKGROUND system will provide an

administrative web interface, through which the administrator of the deployed

system, will be able to manually change specific layer configurations, and also

adjust parameters for individual servers, like maximum users to be connected to

a particular server, etc.

3.1.1. Terminal Client Interface

● Authorization - Whenever a new user connects with the Terminal Client through

a TCP socket, it is required to authorize itself for being able to send and receive

any messages. The server will provide an XML interface that the Terminal Client

will use for authorizing the socket connection. The server will authorize the

Terminal Client on the credentials sent by the Terminal Client. Once a Terminal

Client is authorized, the server will add that particular connection to the set of

online connections associated a user, and any messages sent for this user will

also be forwarded on this socket connection.

● Receiving Multicast Messages - The server will accept messages for

subscription rooms by room administrators, through the terminal client’s TCP

socket. Every message that is received by the server should contain the target

message room, or the usernames of target users. If the message is supposed to

be sent to a room, the server checks if the sender has permissions to publish to a

room, otherwise if the message is targeted to a set of users, the server checks if

the sender has permissions to send to the targeted recipients, and then forwards

the message.

● Sending Multicast Messages - The server will queue up the messages targeted

for a specified username. If one or more Terminal Client instances associated

with the username are connected, the message is immediately forwarded to the

user on the Terminal Client socket connection. If no instance of a Terminal Client

is connected for that particular user then the message may get stored in the

SRS BKGROUND

13

database temporarily (only if the message is directly targeted for the user, and

not targeted for a room).

3.1.2. User Management Interface

● User Registration - Any new user of the application will be prompted to create a

new profile or login using any existing Gmail / Facebook / twitter account. The

server will receive requests for registering the user and adding him to the

database of existing users.

● Manage Session - A user may wish to log in (using the Gmail / Facebook /

twitter account he registered with) and end existing user sessions. The server

system will abruptly close the Terminal Client TCP socket on receiving such a

request.

● Remove Account - The BKGROUND system will also provide APIs to allow the

user to remove an account. When the user wishes to remove the account, the

server will make him authorize again for security purposes.

3.1.3 Administrative Interface

● Connect Terminal Server System to Data Processing Server - The Administrative

Web Interface will provide an option to add a Data Processing Server to the

Terminal Server, so that the terminal server can load balance incoming traffic in

Terminal Server Layer.

● Connect Data Processing Server to Data Forwarding Server - The interface will

provide an option to connect a Data Forwarding Server with a Data Processing

Server, so that the data processing server can forward the message body, after

authorization, and finding specific Terminal Servers to which the message data is

to be forwarded.

Connect Data Forwarding Server to another Data Forwarding Server - The administrator

should be able to connect different data forwarding servers with each other so that they

may be able to send a message from any single terminal server to any other terminal

server.

SRS BKGROUND

14

3.2. Functional Requirements

3.2.1 Use Case: System Management:

Introduction: Allow the system administrator to manage the system. This includes

upgrading a particular server with another server, add/remove new set of servers to any

layer and controlling the connections of a server in any layer to servers of the next layer.

Actors: System Admin.

Pre-Conditions: Administrator must be logged in to the web-based management

system of BKGROUND.

Post-Conditions: The action specified by the admin is performed and the system state

is updated accordingly.

Basic Flow: Action starts when the administrator issues a request.

● If the admin requests to upgrade a server then BKGROUND will start the node

upgrade process which will acknowledge the admin after process completion

accordingly.

● If the admin requests to add/remove new set of nodes to any layer then

BKGROUND will ensure the process completion with proper acknowledgement.

● If the admin requests to reorder the connection of a node with other nodes in the

next layer then also BKGROUND will ensure the connection reordering with

proper acknowledgement.

3.2.2 Use Case: System Monitoring:

Introduction: Allow the system administrator to monitor the state of the system. This

includes monitoring any server / layer etc.

Actors: System Admin.

Pre-Conditions: Administrator must be logged in to the web-based management

system of BKGROUND.

Post-Conditions: The data asked by the system admin is provided to him through the

same web-based interface.

Basic Flow: Action starts when the administrator issues a request.

SRS BKGROUND

15

● The data asked by the admin about any server / layer is passed on to the admin

through the web based monitoring system.

SRS BKGROUND

16

3.2.3 Use Case: Account Creation:

Introduction: Allow the terminal user to create a new account with BKGROUND.

Actors: Terminal User.

Pre-Conditions: None.

Post-Conditions: A new user account would be registered with BKGROUND.

Basic Flow:

Action starts when a new user wants to create an account with BKGROUND.

● The Terminal user issues a request to create a new account with BKGROUND

with user credentials.

● BKGROUND adds the new user to the registered users database.

● BKGROUND acknowledges the user that a new account has been created.

Alternate Flow:

● User Already Registered

If the user is already registered with the system BKGROUND send the user

acknowledgement that the account is already registered with system state

unchanged.

● Registration failure

If the registration fails in between due to any reason then BKGROUND will tell

the user about registration failure and simply ask him to register again.

3.2.4 Use Case: Account Removal:

Introduction: Allow an already registered terminal user to delete account from

BKGROUND.

Actors: Terminal User.

Pre-Conditions: User should be already registered with BKGROUND.

Post-Conditions: The user account should be deleted from BKGROUND.

Basic Flow:

Action starts when a new user wants to delete his account from BKGROUND.

● The Terminal user issues a request to delete his account from BKGROUND.

● BKGROUND asks the user for user credentials to verify the actual user.

● The User provides the asked user credentials to verify his/her account.

● BKGROUND authenticates the user and delete his account from the system.

SRS BKGROUND

17

Alternate Flow:

● User Not Registered

If the user is not registered with the system the authentication will fail and

BKGROUND will send the acknowledgement that the account is not registered

with BKGROUND leaving system state unchanged.

● Account deletion failure

If the account deletion process fails in between due to any reason then

BKGROUND will tell the user about process failure and simply ask him to restart

the process again.

Figure 3.2.4

3.2.5 Use Case: Session Creation/Authorization

Introduction: This use case corresponds to the creation of a new session by an

already registered user.

Actors: Terminal User.

Pre-Conditions: User should be already registered with BKGROUND.

Post-Conditions: A new user session would be established with the system.

Basic Flow:

Action starts when a new user wants to connect to BKGROUND.

SRS BKGROUND

18

● The Terminal user issues a request to create a new session with BKGROUND.

● BKGROUND asks the user for user credentials to verify the actual user.

● The User provides the asked user credentials to verify his/her account.

● BKGROUND authenticates the user and establishes a new session with the

system by creating a new TCP connection with the user through one of the

terminal servers.

Alternate Flow:

● User Not Registered

If the user is not registered with the system the authentication will fail and

BKGROUND will send the acknowledgement that the account is not registered

with BKGROUND leaving system state unchanged.

● Session creation failure

If the session creation fails in between due to any other reason then

BKGROUND will close the sockets opened to connect to the user to free any

stale used resources.

3.2.6 Use Case: Messaging Sending:

Introduction: Allow the terminal user to send a message to another user registered on

BKGROUND, or a publishing room in BKGROUND.

Actors: Terminal Users.

Pre-Conditions: The User sending the message should be connected to a terminal

server, and authorized on the server.

Post-Conditions: The message sent by the user will be delivered to intended

recipients. If the recipient is offline the message is saved for room targeted messages,

otherwise discarded for direct user messages.

Basic Flow:

Action starts when a connected user sends a message to be broadcast on a room.

● The Terminal User sends a message, along with the intended target.

● BKGROUND checks if the sender is authorized to publish the message in the

given room, and publishes the message in the room accordingly.

Alternate Flow:

● Intended target is another user

BKGROUND checks if the sender has permissions to send the message to the

intended recipient user, and sends the direct message accordingly.

● Intended target is not present

BKGROUND will discard the message altogether.

SRS BKGROUND

19

Figure 3.2.6

3.3 Performance Requirements

● Number of Users: Each terminal node is targeted to connect to 1 Million number

of end users and maintain a persistent TCP connection to each user.

● Minimizing Latency: BKGROUND should also ensure that the latency between

sending and receiving message through this system should be minimum, no

matter how many recipients.

● Maximizing Throughput: BKGROUND should ensure maximum throughput

through each of the nodes in the system, i.e. the data flow through each node

should be maximized keeping latency as small as possible.

● Upgrading Nodes: BKGROUND should also ensure zero downtime upgrade for

every node in the system.

3.4 Logical Database Requirements

SRS BKGROUND

20

● For the process of authorisation at the terminal server, we need to store the user

ID and the corresponding secret key for all the registered users.

● When a new user is registered, we need to add to database the new user ID and

its secret key.

● For a particular user, we need to create columns for the different accounts which

user could be using with our system.

● For each account, we need to store the login credential, which may be of

following forms:

○ Username and password in case of a simple account(not using OAuth).

○ Username, appID, and secret authorisation key in case of services which

using OAuth 2.0 such as Google, Facebook, and Twitter.

● For the case, when the user is not connected to the terminal server, we may

need to store the message that is needed to be sent.

● The information about all the devices connected to a specific account is also

needed to be stored in a database.

● The internal information about the different server will be stored. This will include

the IP address of different machines, category (Terminal server, data forwarding

layer, Data processing layer), and virtual ID of the machine.

● The message history of each room will also be saved in a database.

● Message history storage will not be done on the system in case of the direct

messages. In this case, the history will be saved on the client side, so that it is

available to the user.

● A table for different rooms will also be present. This table will contain all the

necessary room-related information such as room administration, room

members, room status messages, etc.

3.5 Design Constraints

Not applicable

3.6 Software System Attributes

3.6.1 Reliability

Any message that is sent to the user has to be necessarily received by the user

(provided that the user is connected). If the user is not connected then he may only

receive the messages published to rooms instead of direct messages sent to him.

SRS BKGROUND

21

3.6.2 Availability

The terminal users are supposed to maintain a persistent TCP socket connection with

Terminal Servers, and the servers may receive messages to broadcast at any time. So,

the complete system must be up and running always. Any upgrades to the system

should have zero downtime.

3.6.3 Security

The system must make sure that the users who are broadcasting messages to the

rooms have publishing permissions for the room. If the user is sending a direct message

to another user, he must have permissions to send direct messages to that user.

3.6.4 Maintainability

The system has to provide an administrative interface so the layers can be connected

with each other. The system should also allow upgrading with minimum downtime (for

Terminal Servers), and zero downtime for other servers.

3.6.5 Portability

Portability is not a requirement of this system, as the system is to be deployed once on

any machine that can support Java.

3.7. Organizing specific requirements

Not applicable.