Table of Contents

1. Introduction

1.1 Project Overview

The aim of this project is to use mobile technology to connect people with services or products requirements, with the supplier, the instant that the requirement or supply becomes available.

1.2 Background

Information on the internet is structured into sectors of information for example job seekers and head hunters, sellers and buyers of goods and services. This generic index caters for all supply and demand of services or products.

The usage of this system caters for information found in jobmail, junkmail, lovemail, personnel agencies, price list, auctions, sales clearances, calendar events, and emergency services.

The difference between this system and other static subscription directory systems is its design to notify the users thereof, immediately when information becomes available.

Even though subscription is possible, and extending the system feasible, this document concentrates on quickly connecting people when mutual requirements exist.

The user either queries for or enters keywords, including a region, name regarding the product, service or event. Therefore clients and advertisers are notified of their mutual interest immediately. The information expires after a certain time period, and can be renewed.

The system can also be adapted to cater for SMS/MMS auctions.

1.3 Vision and Scope

1.3.1 Vision Statement

To connect persons using mobile technology, the moment when mutual requirements exist for such a connection.

1.3.2 Opportunity Statement

With the rising popularity of the Cell phone, customers expect to gather information, obtain service contacts, receive notifications, and advertise or sell products and services without necessarily making contact with the company or a middleman.

1.3.3 Scope

From an end-user perspective, the SMS Index Project consists of two functional elements: a Web site and a SMS automation system.

1.3.3.1 Web Site

A Web site is to be developed for the SMS Index. To increase customer base and provide additional functionality for their existing customers, SMS Index website should include the following features:

• The customer will be able to browse current services and contact representatives, obtain detail on how to use specific services and how to pay.

• View real-time statistics of content in the system, broken down into region, category and keywords used, for the purpose of marketing.

• The user should not be able to search the database from the internet, because revenue is generated with reverse billing the system should only be accessible via SMS.

1.3.3.2 SMS Automation

A SMS Automation system will be developed for The SMS Index that will consist of an application to be used for report generation, credit accounting and SMS automation logic.

The application will include the following features:

• Cell phone notification (Account balance) to users and subscribers of the different solutions.
• Users receive/send content via Cell phones, based on criteria.

• Usage reports for Marketing and accounting.

• Connectivity with bulk SMS suppliers and content providers.

1.3.4 Out of Scope

The following functions are considered out of scope for Version 1 of the SMS Index. Versions 2.0 and 3.0 will address items not in scope, and those deemed not feasible during V1.0.

1.4 Critical Success Factors

Some factors identified is:

• Lack of content for keyword searched i.e. no content matched search criteria.
• The validity of queries against data and the validity of the data itself should be decreased over time. During the launch of the application data and queries against data should be kept on the system for longer to increase the chances of a notification. Thereafter the valid time for adverts and queries can be deceased.

1.5 Risk Assessment

Minimal risk exist to the system, given that the following is prevented

• Sql injection by cell phone.
• Attempts to upload data to the SMS gateway without using a cell phone.
• Database growth bigger than hard disk space.

3. Design Goals and Constraints

3.1 Performance

The system should be able to process 100 messages a second.

3.2 Availability

Because the Web site is accessed by customers across the world, it needs to be available 24 hours a day, 7 days a week.

3.3 Reliability

Because of the need for 24*7 availability, automatic failover will be required. In addition, existing disaster recovery and backup plans and procedures must be revised to incorporate the SMS Index Application.

3.4 Scalability

SMS Index anticipates an average load of 500 concurrent users after the system is fully operational, and expects that to grow by 5 percent each year for the next five years.

3.5 Security

The reception of SMS messages from the Gateway has to be secure, to ensure that messages can only be received from the gateway and not from any other source.

The message content should not allow content that will allow a hacker to compromise the system, its content or stability.

3.6 Interoperability

The website will periodically query the database for statistics over HTTP.

3.7 Location

There is no location specific requirements.

3.8 Internationalization

The application needs to support international currencies, character sets, and date/time formats.

3.9 Setup/Installation

System should be installable from disconnected media.

4. Features/Functionality

The following list requirements of the system

• System can receive SMS from Gateway over http, ftp, smpp
• System can send SMS to Gateway over http, ftp, smpp
• System can add information to system
• System can query information in system
• System can notify user when item matching search term is added
• Notify user when item is about expire and can be renewed
• User can top up credits with reverse billing
• Web user can view real time statistics of the content of the database by region , category or keyword, as well as usage statistics of the system.
• Warn administrator about critical factors of the system
• collect statistical data for report and analysis
• prevent unpaid content at ftp, http, smpp level
• end-user website tutorial on how to use the system
• information item expire after certain period
• information item must have a region in the message
• website must be search engine optimized
• website displays terms and condition indemnification

The following sections summarize features and functionality; use cases are available on request.

4.1 Add information item

4.1.1 Description

This function will enable consumer to place information into the SMS Index.

4.1.2 Business Need

This function will enable consumers place information in the SMS Index catalog directly from their mobile phone without the intervention of an SMS Index employee.

The SMS is reverse billed and expires after 24 hours. An SMS is sent back to the consumer to state that the information has been added. A reference number is returned in the message for renewal purposes. A SMS message is sent to the consumer 1 hour before the information item expires, to enable the consumer to renew the information.

4.1.3 Priority

High

4.2 Query information

4.2.1 Description

This function will enable consumer to search information in the SMS Index.

4.2.2 Business Need

This function will enable consumers to search for keywords in information items. Items that match are returned to the consumer as reference number name, cell number and URL. If items are more than one SMS size the consumer is notified thereof in the same SMS. The count of items that match is returned to the consumer in the same SMS. The consumer can request the next set of results by sending the same query again.

When there is no results the message becomes a query hit notification, and a SMS message stating this is returned to the consumer.

4.2.3 Priority

High

4.3 Query hit notification

4.3.1 Description

This function enables the consumer to be notified when information is added to the system that matches their search criteria.

4.3.2 Business Need

This happens either when there is no existing information for the query or when there already is, but the user wants immediate notification due to the type of information that is required.

Every information item that is added to the system is evaluated against all notifications pending, after the information entry is added in the database. Evaluation is based on keyword full text search.

The notification is valid for 24 hours where after the consumer is sent a reminder of renewal.

If no renewal message is received the notification is removed from the database.

4.3.3 Priority

High

4.4 Renew information

4.4.1 Description

This function allows the consumer to renew the valid time of the information item. Items are available for searching for 24 hours, and can be renewed.

4.4.2 Business Need

The consumer sends a reverse billed SMS message with the reference number and renewal keyword to the system. This can be done repeatedly, and the validity time of the information increased with each SMS message received by the system.

4.4.3 Priority

Medium

4.5 Credit top up

4.5.1 Description

This function allows the consumer to buy SMS credits for usage by the system. It will be a reverse billed short code with keyword. And will be used for all services that the system offers to the consumer.

4.5.2 Business Need

Where it is not feasible to bill per SMS or when the system sends more than one SMS back to the consumer or other consumers, credits are used.

4.5.3 Priority

Medium

4.6 Web View Statistical System information

4.6.1 Description

This function allows the consumer and management to see the state of the system

4.6.2 Business Need

As a marketing means and attracting attention to the system, prospective consumers can view numerical information of the system. The statistics should include.

• the total number of queries received
• total number of items received
• total number of query hits found
• number of current items
• number of current hit notification
• number of active items in the database
• number of active query notifications in the database
• summary count of items by keyword
• summary count of items by region

The system should be able to show virtual simulation statistics when there is no activity in the system.

4.6.3 Priority

Medium

4.7 Critical warnings

4.7.1 Description

This function allows the management to be warned of critical factors in the system.

4.7.2 Business Need

Immediate action should be taken when critical system state is observed. States that will need notification is .

Connectivity loss with SMS Gateways

Out of disk space

System logic failure

Unpaid arrival of messages

4.7.3 Priority

High

4.8 Send Message to Gateway

4.8.1 Description

This function allows the system to send messages to the SMS Gateway that the system is connected to.

4.8.2 Business Need

The system should manage connectivity loss, and should retry sending SMS after connectivity has been restored. The system state should not be lost if connectivity is broken for maintenance or upgrade purposes.

The system should have a function to pause and resume the sending of SMS to enable offline maintenance, or database maintenance.

Messages should only be sent within South Africa.

4.8.3 Priority

High

4.9 Receive Message from Internet

4.9.1 Description

This function allows the system to receive messages from the internet that has been sent by the consumer.

4.9.2 Business Need

The system should ensure that messages originate from the correct source, to prevent the reception of unpaid messages. Messages should either be passed via HTTP or FTP.

After the message has been received, processing based on its content should automatically follow, based on the commands contained inside the message.

4.9.3 Priority

High

4.9 Credit Management

4.9.1 Description

This function allows the system to increase, decrease and query the credit state of a consumer.

4.9.2 Business Need

The system should ensure that credits are increased and decreased when top ups is received and messages sent. Sending delays and sending failure due to connectivity should manage the credit count accordingly.

The credit system should also decrease credits from certain sources as the message is received.

The system should be able to enable or disable credit functionality for certain commands received by the system, since not all services that rely on incoming messages will utilize the credit system.

4.9.3 Priority

High

4.10 Usage reports

4.10.1 Description

This function allows management to view the overall usage of the system.

4.10.2 Business Need

The system should ensure that aggregate credit reports are available for accounting and marketing purposes. Usage reports by consumer and keywords for marketing purposes should also be possible.

The data for the reports should be in a separate database than the information items, to prevent performance of the production database.

Standard reports should be viewable on a secure webpage. Data should be exportable to a flat file and downloadable via FTP for future analysis. All reports should be encrypted with RSA 2048 bit encryption.

4.10.3 Priority

High

4.11 Website

4.11.1 Description

This function allows consumers to view information about the system.

4.11.2 Business Need

The website should provide static information about the capabilities and services of the system, and how to use the system. As well as usage statistics updated every minute.

Cell phone number contact details of management should be viewable on the site.

Only web colors should be used on the site.

The website should state areas where emergency services has added notifications events for consumers that adds for instance fire, rape, burglary or other schedule one crimes.

4.11.3 Priority

High

4.12 Maintenance

4.12.1 Description

This function allows administration personnel to make changes to the system.

4.12.2 Business Need

The system should not experience a loss of data ie. Database data, SMS messages or credit state when taken of line for maintenance, or when connectivity to the internet or the database is interrupted.

The system should be able to reload state and continue processing, after a power failure.

The system should function properly after a long shutdown , and not malfunction due to date time differences.

4.12.3 Priority

High

4.13 Logs

4.13.1 Description

This function allows administration personnel to debug events and resolve consumer queries.

4.13.2 Business Need

The system should log each message received and sent. And each database insert and delete and update.

4.13.3 Priority

High

4.14 Usage Scenarios

Usage scenarios that describe how users will use the solution within the context of the business are documented individually. For more information about usage scenarios, please contact Bits4Bytes:

5. Solution Architecture

5.1 Infrastructure

LAMP production Web space will be leased and bandwidth as well as additional database space bought. A separate sub web with database will be used for reporting. and accounting.

A separate web space will be used for the website with information about the system.

The Linux software package ‘kannel’ may be used if the leased web space allows for its installation and configuration.

5.2 Visual Design

For a Microsoft PowerPoint presentation outlining the website user interface, see SMS Index – Website User Interface.ppt.

Introduction
The onion router has been in existence for quite a while, and the hidden services therein mainly remained in architecture the same. Likewise centralized IRC servers are found in TOR that does not solve the problem of a single point of failure. Therefore an alternative architecture is suggested and based on a decentralized principle. This implementation may result in one big anonymous, redundant, chatting onion.

Background
Tor is a relay-network that uses layered encryption between nodes to enable secure anonymous transport of information. IRC is a centralized client server network, mainly used for chartrooms. Combining the two architectures with the gnutella node discovery methodology can result in a distributed, “peer-to-peer”, IRC enabled network, solving the dilemma of dependency on a centralized IRC server.

Architecture
In order to implement such a system the following subsystems is required, as listed and elaborated upon below:

• IRC client
  This is a normal third party IRC client that will connect locally to the TOR-IRC server.

• TOR-IRC Server
  This is a custom IRC server that discovers other similar nodes and manages connections via the TOR network, also running locally, in essence basically a router.

• TOR client proxy
  A locally run TOR client that manages the connection to the TOR network and serves as a SOCK proxy for the TOR-IRC Server to communicate through.

• Gnutella web cache
  A modified gnutella web cache website, published within the TOR network to enable node discovery of TOR-IRC Servers. The only modification required is for the onion addresses instead of IP numbers.

Since the TOR client and the IRC client application is out of the box the remaining two subsystems is discussed.

TOR-IRC Server
This application consists of the following components:

• An  IRC daemon ( or server) for local IRC client connections
  This daemon mimics the functionality of a centralized IRC server under normal usage scenarios.

• SOCK protocol capability for connecting and  communicating with the TOR proxy
  The TOR proxy talks SOCK and not TCP, therefore this connection between the local IRC daemon and TOR is required.

• TOR-IRC client instance manager.
  For each node discovered via a tor web cache a local management IRC client instance (router) is created, this instance then connects to the discovered node (since that node is a IRC server as well) and then to the local IRC daemon via a similar child instance. Server information is communicated through this node between the local IRC server and the remote IRC server.

After connection any users on the remote IRC server (this is usually one-to-one) when this subsystem recognizes it as such (eg. join), is created locally as a client instance, and connects in turn to the local IRC server.

The picture below depicts the interaction between the components

Legal
Certain countries may have legislation that prohibited users from using the TOR network, or legislation on free speech, or the publication of information may exist. Care should be taken with the information usually logged by normal third party IRC clients.

Conclusion
The ability of the TOR community to decentralize the IRC network therein would enable higher redundancy and decrease dependency on current centralized architectures.

Links
Netshare
SmartIRC4net
SmartIRC4Net+Socks 
Ircd.Net
SOCKS
TOR network
Gnutella webcache
The TOR-IRCd Concept Application
The TOR-IRCd Concept Application (Alternative Link)