SRS BKGROUND

Software Requirement
Specification

Publish/Subscribe System

BKGROUND
Group-03

Atul Jangra 2010CS50277

Dushyant Behl 2010CS50282
Shantanu 2010CS50295
Utkarsh 2010CS50299

1
SRS BKGROUND

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

2
SRS BKGROUND

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

3
SRS BKGROUND

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

4
SRS BKGROUND

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:

5
SRS BKGROUND

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.

6
SRS BKGROUND

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.

7
SRS BKGROUND

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,

8
SRS BKGROUND

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

9
SRS BKGROUND

2.2.2. Use Case Diagram:

Figure 2.2.2.1

Figure 2.2.2.2

10
SRS BKGROUND

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.

11
SRS BKGROUND

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

12
SRS BKGROUND

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.

13
SRS BKGROUND

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.

14
SRS BKGROUND

● The data asked by the admin about any server / layer is passed on to the admin
through the web based monitoring system.

15
SRS BKGROUND

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.

16
SRS BKGROUND

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.

17
SRS BKGROUND

● 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.

18
SRS BKGROUND

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

19
SRS BKGROUND

● 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.

20
SRS BKGROUND

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.

21