ABSTRACT

The paper focus on Named Data Networking (NDN) content-based networking, data
oriented networking or information-centric networking is a Future Internet architecture inspired
by years of empirical research into network usage and a

growing awareness of unsolved

problems in contemporary internet architectures like IP. The belief is that this conceptually
simple shift will have far-reaching implications for how people design, develop, deploy, and use
networks and applications.
The usage of Smartphone increased more in the last five years. Now a days people are
using a smartphone much for chatting which help share the information between two or to the
group. Presently there are lots of applications available on the Android market for chatting and
information sharing. All these just share the message but won't provide any message status like
the message is seen or not and if seen, it is accepted or not. In this paper, we proposed a new
application called as Shary an Android based application developed using Android Kit Kat
version 4.4. The main aim of this application is to share any last minute updated information to a
specific group and receive the status of the messages
Multi-user applications are commonly implemented using acentralized server. This paper
presents a new design for multi-user chatapplications (Chronos) that works in a distributed,
serverless fashionover Named Data Networking. Named Data Networking has an intrinsic
distributed nature, which eases decentralizing formerly centralized protocols as discussed.
Nevertheless, implementing fully distributed protocols for many-to-many
remains challenging.

communications

CHAPTER 1
INTRODUCTION

1.1.computer network

A computer network consists of a collection of computers, printers and other

equipment that is connected together so that they can communicate with each other. Fig 1
gives an example of a network in a school comprising of a local area network or LAN
connecting computers with each other, the internet, and various servers.

1.1.Basic of Networking
Peer-to-peer networks are more commonly implemented where less then ten
computers are involved and where strict security is not necessary. All
computers have the same status, hence the term 'peer', and they communicate
with each other on an equal footing. Files, such as word processing or
spreadsheet documents, can be shared across the network and all the computers
on the network can share devices, such as printers or scanners, which are
connected to any one computer.

 LAN connecting computers with each other, the internet, and various

1.2.Multi user chat NDN:

Named Data Networking (NDN):

Its premise is that the Internet is primarily used as an information distribution network,
which is not a good match for IP, and that the future Internet's "thin waist" should be based on
named data rather than numerically addressed hosts. The underlying principle is that a
communication network should allow a user to focus on the data he or she needs,
named content, rather than having to reference a specific, physical location where that data is to
be retrieved from, named hosts. The motivation for this is derived from the fact that the vast
majority of current Internet usage (a "high 90% level of traffic") consists of data being
disseminated from a source to a number of users

Background:
Todays Internets hourglass architecture centers on a universal network layer, IP, which

implements the minimal functionality necessary for global inter-connectivity. The contemporary

Internet architecture revolves around a host-based conversation model, created in the 1970s to
allow geographically distributed users to use a few big, immobile computers. [5] This thin waist
enabled the Internets explosive growth by allowing both lower and upper layer technologies to
innovate independently. However, IP was designed to create a communication network, where
packets named only communication endpoints.
Sustained growth in e-commerce, digital media, social networking, and smartphone applications
has led to dominant use of the Internet as a distribution network. Distribution networks are more
general than communication networks, and solving distribution problems via a point-to-point
communication protocol is complex and error-prone.

1.1.2.The main building blocks of the NDN architecture are named content chunks, in contrast to the IP
architecture's fundamental unit of communication, which is an end-to-end channel between two end
endpoints identified by IP addresses.

1.2.1.Architecture Overview
Types of Packets:

Communication in NDN is driven by receivers i.e., data consumers, through the exchange of two
types of packets: Interest and Data. Both types of packets carry a name that identies a piece of
data that can be transmitted in one Data packet.

1.1.3. Overview of the Packet Contents for NDN Packet

Interest: A consumer puts the name of a desired piece of data into an Interest packet and sends
it to the network. Routers use this name to forward the Interest toward the data producer(s).

Data: Once the Interest reaches a node that has the requested data, the node will return a Data
packet that contains both the name and the content, together with a signature by the producers
key which binds the two. This Data packet follows in reverse the path taken by the Interest to get
back to the requesting consumer.

Router Architecture:

Pending Interest Table (PIT): stores all the Interests that a router has forwarded but not
satised yet. Each PIT entry records the data name carried in the Internet, together with its
incoming and outgoing interface(s).

Forwarding Information Base (FIB): a routing table which maps name components to
interfaces. The FIB itself is populated by a name-prex based routing protocol, and can have
multiple output interfaces for each prex.

Content Store (CS): a temporary cache of Data packets the router has received. Because an
NDN Data packet is meaningful independent of where it comes from or where it is forwarded, it
can be cached to satisfy future Interests. Replacement strategy is traditionally least recently
used, but the replacement strategy is determined by the router and may differ.

Forwarding Strategy module: a series of policies and rules about forwarding packets. Note
that the Forwarding Strategy may decide to drop an Interest in certain situations, e.g., if all
upstream links are congested or the Interest is suspected to be part of a DoS attack. For each
Interest, the Forwarding Strategy retrieves the longest-prex matched entry from the FIB, and
decides when and where to forward the Interest.

1.2.2.Key Architectural Principles

1.2.1 End -to-end principle:
Routing and forwarding plane separation: This has proven necessary for Internet
development. It allows the forwarding plane to function while the routing system continues
to evolve over time. NDN uses the same principle to allow the deployment of NDN with the
best available forwarding technology while new routing system research is ongoing.
Built-in security: In NDN, data transfer is secured at the network layer by signing and
verification of any named data

1.3. Design
NDN names are opaque to the network. This allows each application to choose the naming
scheme that fits its needs, and naming can thus evolve independently from the network.

1.3.1Structure
The NDN design assumes hierarchically structured names, e.g., a video produced by UCLA
may have the name /ucla/videos/demo.mpg, where / delineates name components in text
representations, similar to URLs. This hierarchical structure has many potential benefits:

1.4.Security
1.4.1Overview:
In contrast to TCP/IP, which leaves responsibility for security (or lack thereof) to the endpoints,
NDN secures the data itself by requiring data producers to cryptographically sign every Data packet.
The publishers signature ensures integrity and enables determination of data provenance, allowing
a consumers trust in data to be decoupled from how or where it is obtained. NDN also supports finegrained trust, allowing consumers to reason about whether a public key owner is an acceptable
publisher for a specific piece of data in a specific context. The second primary research thrust is
designing and developing usable mechanisms to manage user trust. There has been research into 2
different types of trust models:

hierarchical trust model: where a key namespace authorizes use of keys. A data packet
carrying a public key is effectively a certificate, since it is signed by a third party, and this
public key is used to sign specific data.

web of trust: to enable secure communication without requiring pre-agreed trust anchors

1.4.2.Routing Security

NDN treats network routing and control messages like all NDN data, requiring
signatures. This provides a solid foundation for securing routing protocols against attack,
e.g., spoofing and tampering. NDNs use of multipath forwarding, together with the
adaptive forwarding strategy module, mitigates prefix hijacking because routers can
detect anomalies caused by hijacks and retrieve data through alternate paths.

1.4.3.chat room:
The term chat room, or chatroom, is primarily used to describe any form
of synchronous conferencing, occasionally even asynchronous conferencing. The term can thus
mean any technology ranging from real-time online chat and online interaction with strangers
(e.g., online forums) to fully immersive graphical social environments.
The primary use of a chat room is to share information via text with a group of other
users. Generally speaking, the ability to converse with multiple people in the same conversation
differentiates chat rooms from instant messaging programs, which are more typically designed
for one-to-one communication. The users in a particular chat room are generally connected via a
shared interest or other similar connection, and chat rooms exist catering for a wide range of
subjects. New technology has enabled the use of file sharing and webcam to be included in some
programs. This can be considered a chat room.

CHRONOS DESIGN
2.1.3Overview:

Chronos design has two main components: data set state memory and data storage.The data
set state memory maintains the current knowledge of the chat simple and effective way to share
digests among all participants in a small network, because NDN suppresses identical Interests. If
the participants are distributed over large networks, such as the Internet, simple broadcast may
no longer be feasible. For clarity, we describe Chronos design using broadcast for Interests, and
in Section 5 we discuss solutions to scale Chronos sync Interest distribution.

2.1.4.Data Structures:
It is critical to maintain an up-to-date view of the chat data in order to generate digest.
Chronos uses digest tree to achieve this goal. A digest log, which records the changes of the
digests, provides a way to find and quickly resolve the difference of views. Digest Tree The
overall knowledge about the chat room can be represented by the set of statuses of all
participants (producer statuses), i.e., what data each participant has produced so far. As a result
of the naming rule, whenever a participant learns a sequence number N for another participant,
he knows for sure that data packets with sequence numbers smaller than N from that participant
must have already been sent to the chat room, regardless of whether he has already fetched them

A Data packet carries the name and the actual data, along with a signature created by the
original data producer that binds the two together. When a router sees a Data packet, it finds the
matching entry in its PIT and forwards the packet to the interfaces whe re the corresponding
Interests come from and removes the PIT entry.

1.5. System Modules

In this section working principles and the functions which are used in to implement this
application are
explained. This application basically developed for two different users, one is for the Faculty and
the other is
Student.

The Faculty can create the group by selecting the Students from different branches and can
send the messageto the created group and view the status of the message either the Student
viewed, accepted or declined. The
Student can respond the messages by selecting the option Accept or Declined. User interface of
Faculty has the following modules
Faculty login: - This module allows the faculty to login to the application using username and
password.
By means of this login page, the application will provide security and access control by allowing
only
registered faculties to access the app.
Faculty registration: -Faculty who have not registered can register with the app here by giving
a code,
username, and password. Code will be different for Faculty so that the user will have secure
access to the
application.
Create group: - After the Faculty is logged in, the application will direct to a new page to
create a group or
to use existing group. The Faculty can add Student who are registered with the application and
create their
own group. The message can be sent across to that group.
Status of the message: - This module allows the Faculty to know the status whether the
Student has
accepted, declined or kept pending to respond the messages.
User interface of Student consists of the following modules
Student login: - The Student can login if he has already registered with the app by giving a
user name and
the password.
Student registration: - Registration form for Students allows the Student to register by giving
a code,
username, branch, contact number, and password. Code will be different for Student so that the
user will

have secure access to the application.

Notification: - The Students receives a notification via pop-ups in their mobile like a message
alert when
the Faculty updates the message. Students receives the alert only if they are online or logged into
the
application otherwise the message gets stored directly into the Students inbox, and it can be
viewed when
he/she login to the application.
Students inbox: In this inbox, all the messages received by the Student is stored and the messages which
are read is highlighted in different colour. Once the message is read they can respond by, a click
on any one
of the buttons provided (got-it or decline), by this Faculty will get the response. If the Student
doesnt
respond it will be displayed as pending.
1.5.1. Functions Used
This section brief the eclipse inbuilt functions which are used to develop the application
1.5.2. Alarm manager:
The Alarm Manager is intended for cases where the application code run at a specific time,
even if the
application is not currently running. For normal timing operations (ticks, timeouts, etc.) it is
easier and much
more efficient to use Handler.
In this application, alarm manager is used to notifying the Students if they receive any message
from the
Faculty. The alarm screen appears on the Students phone with the information such as the admin
name, subject
of the message, date and time of the message posted will appear on the alarm manager.
1.5.3. Httppost
The Httppost request method is designed to request a web server to accept the data enclosed
in the request

message's body for storage.

In this application, Httppost is used to post the information from the application to the database
via the server.
For example information such as message, date, time, group details are stored in the database.
1.5.4.Httpget
The Httpget method helps to retrieve information from the server. In this application, Httpget
is used to get the
information from the database to the application via the server. For example information such as
group, Faculty
name, Student name will be retrieved from the database to the application.

1.5.5.Participant Join/Leave:
Participants come and go in a chat room. A newcomer needs to learn the current producer
statuses in the room before he can participate, and the events of both join and leave of a
participant need to be reflected on the roster.
1.5.5.Working Principles
The home screen has two login buttons for two different users, Faculty and Student. New
Faculty user should
register their detail with the application by giving their details such as code, username and
password. Similarly,
new Student user should register with the application by giving their details such as code,
username, branch and
password.
If the Faculty login button is clicked. The Faculty can login to the application and the page
will direct to a new
page where there are two buttons send message and message status. If the Faculty clicks on send
message then
the Faculty can send message to an existing group or newly created group, Faculty can create a
group using the

Student who ever has registered with the application. Once grouping is done the page will direct
to a new page
where the Faculty can send a message to the group. In this page there is an option where the
Faculty can type the
Messagetitle or can use Suggestedtitles.
After the Faculty sent the message to the group, all the Students under the specified group
receives an alert on
their phone, then Students can open the message or can view it later. The Students can view the
message along
with the Facultys name, date, time and message title. Now the Student can reply back to the
Faculty by
selecting one of the two buttons Accept or Decline. Once the Student clicks on any of the button
immediately
the status of the Student is updated. If the Student click on accept the status appear as accepted, if
the Student
click on decline the status appears as declined, if the Student doesnt reply back to the message
the status is
assumed as pending. The status of the message is viewed in the Facultys profile. Once the
Faculty is logged in
he/she can click on the message status button to view the status of the message.

CHAPTER 2

LITERATURE REVIEW

2.1 TITLE:.

Serverless Multi-User Chat Over NDN

AUTHOR : Zhenkai Zhu_, Chaoyi Biany, Alexander Afanasyev_, Van Jacobsonz, and
Lixia Zhang

2.1.1.NDN BACKGROUND:

In this section we briefly go over a few basic concepts of NDN that are essential to describe
the design of Chronos. Communications in NDN are driven by data consumers. Each piece of
content is cryptographically associated to a data name. To retrieve data, a consumer sends out an
Interest packet, which carries a name that identifies the desired data. A router remembers the
interface from which the Interest comes in, and then forwards the Interest packet by looking up
the name in its Forwarding Information Base, which is populated by routing protocols that
propagate name prefixes instead of IP prefixes. Each received Interest is kept in a Pending
Interest Table (PIT).

or not. Hence, the producer status of a participant can be effectively represented by the latest
known data name of that participant.Inspired by the idea of Merkle trees , we use digest tree to
organize the producer statuses for quick and deterministic digest generation, as illustrated in Fig.
2.1.4

Fig. 2.1.4: An Example of Digest Tree

2.2.TITLE : DESIGN AND IMPLEMENTATION OF ON-LINE CHATTING

APPLICATION USING ANDROID
JOURNAL: Kavitha. R, Rupali Wagh , Remona Yacoop , Deeksha S

IMPLEMENTATION
2.1 .System Architecture

Fig 2.1 System Architecture

This application Shary stores all the information such as messages, groups information in
the external database i.e. the online database via the server (internet). The server is connected to
the database using PHP language. The server tells the application for every new update. So that
the message get stored into the database and it is available for retrieval for any time. System
architecture of the application.

Fig 2.2 (a) Message entry by faculty Fig (b) Received Message by student Fig
Message Status

2.3TITLE : EfcientMany-To-ManyCommunicationSupportinInformation CentricNetworks

JOURNAL : Department of Computer Science, University of California, Los Angeles,
California (USA)

AUTHOR :Fabio Angius, Cedric Westphal, Jun Wei, Mario Gerla, Giovanni Pau

Named Data Networking has an intrinsic distributed nature, which eases decentralizing
formerly cen- tralized protocols as discussed in. Nevertheless, implementing fully distributed
protocols for many-to-many communications remains challenging. The NDN architecture, built
upon CCN, makes the following assumptions in order to place content as the narrow waist of the
communication

stack:

content,

not

machines,

should

be

explicitly

addressed

and

dataarenotsentunlessthereceiverexplicitlyrequested it. These assumptions require some specic

considerations when multiple parties publish content under the same name, as in some many-tomany communication applications. This paper discusses the challenges arising from the implementationofmany-to-manychannelsoverNDN.Weproposean algorithm, inspired by the frequency
hopping algorithm used in wireless systems, named Prex Hopping (PH) to implement high rate
many-to-many channels. We show evidence that with the current state of the art, content updates
can be lost when generic shared names are used, due to the fact that interest packets - i.e. data
requests - can be generated at a xed bounded rate. The results show how adopting PH is
possible to arbitrarily reduce data losses at the cost of a negligible overhead. We have
implemented PH and show that it results in a dramatic performance improvement.

CHAPTER4

CONCLUSION AND FUTURE ENCHANCEMENT

4.1 CONCLUSION
This paper gives the overview of an android mobile application Shary. This application is
developed to share an important message which needs to reach Students within few minutes. It
can be used by the different group of people like trip advisor, Academic events etc. The future
developments which can be added to the application are, notify the Students immediately when a
message is updated even when they are not logged into the application and message sharing
among the Students, between Faculties, and from Faculty to Student and vice versa. This helps
the entire group who registered with this application can be updated with the last minute
message.

4.2 FUTURE ENCHANCEMENT

CHAPTER 5

REFERENCES
5.1 JOURNAL REFERENCES
[1] A. Tridgell and P. Mackerras, The rsync algorithm, TR-CS-96-05, 1996.
[2] D. Eppstein, M. Goodrich, F. Uyeda, and G. Varghese, Whats the difference? efcient set
reconciliation without prior context, Proc. of SIGCOMM, 2011.
[3] S. Agarwal, D. Starobinski, and A. Trachtenberg, On the scal- ability of data synchronization
protocols for PDAs and mobile devices, IEEE Network, vol. 16, no. 4, 2002.
[4] S. Floyd, V. Jacobson, S. McCanne, C.-G. Liu, and L. Zhang, A reliable multicast
framework for light-weight sessions and application level framing, in Proc. of SIGCOMM,
1995.
[5] X. Zhang, J. Liu, B. Li, and T.-S. Yum, CoolStreaming/DONet: A data-driven overlay
network for peer-to-peer live media stream- ing, Proc. of INFOCOM, 2005.
[6] L. Zhang et al., Named data networking (NDN) project, PARC, Tech. Rep. NDN-0001,
2010.
[7] R. C. Merkle, A certied digital signature, in Proc. of Advances in Cryptology, 1989.
[8] National Institute of Standards and Technology, Secure hash standard (SHS), FIPS PUB
180-3, 2008
. [9] H. Gilbert and H. Handschuh, Security analysis of SHA-256 and sisters, Selected Areas in
Cryptography, 2004.
[10] C. Dewes, A. Wichmann, and A. Feldmann, An analysis of Internet chat systems,
IMC03.

5.2 WEBSITE
[1]

https://play.google.com/store/apps/details?id=com.easygsms&hl=en.

[2]

http://en.wikipedia.org/wiki/Comparison.

[3] http://www.ccnx.org.