RELYING ON SAFE DISTANCE TO ACHIEVE GROUP MEMBERSHIP IN ADHOC NETWORKS full report
#1

[attachment=3703]
RELYING ON SAFE DISTANCE TO ACHIEVE GROUP MEMBERSHIP IN
ADHOC NETWORKS


Presented By:
K. Revathi 1

Dharmaraj T.B

A. Usha Ruby 3

Lecturer/CSE, CSICE,Nilgiris,Tamilnadu, India
II ME(CSE),PABCET, Trichy, Tamilnadu, India,
I ME(CSE),PABCET ,Trichy, Tamilnadu, India,


ABSTRACT

The design of ad hoc mobile applications often requires
the availability of a consistent view of the application
state among the participating hosts. Such views are
important because they simplify both the programming
and verification tasks. We argue that preventing the
occurrence of unannounced disconnection is essential to
constructing and maintaining a consistent view in the ad
hoc mobile environment. In this, we provide the
specification for a group membership service supporting
ad hoc mobile applications and propose a protocol for
implementing the service. A unique property of this group
membership is that messages sent between group
members are guaranteed to be delivered successfully,
given appropriate system assumptions. This property is
preserved over time despite movement and frequent
disconnections. The protocol merges groups and
maintains a logical connectivity graph based on a notion
of safe distance. The process called Merging, which will
lead to combine the groups, which are in the safe distance
by maintaining the leader for each group, provides the
guaranteed delivery of messages

1. INTRODUCTION

Group membership has been an important problem in the
area of fault-tolerant distributed omputing. Solving the
problem requires the provision of a service that
establishes and maintains some kind of agreement over
time among participating components about who is
currently in the group, despite the presence of failures in
the corresponding distributed system. Such a group
membership service simplifies the development of many
fault-tolerant distributed applications and is widely used
for supporting reliable group communications.
One important piece of group state information is
membership in the group, i.e., who is in the working

reasons) the presence of two or more specific entities to
carry out a task may impose the need for a consistent
membership view.
The goal of our group membership service is not only to
create a consistent view of group membership among
participants, but also to help users and application
programmers avoid the complexities introduced by
potential data inconsistencies caused by mobility-induced
link failures. Mobility-induced page link failures refer to the
communication failures caused by mobile units moving
out of each otherâ„¢s communication range.
unrecoverability of mobility-induced page link failure can
result in permanent data inconsistency and poses a great
challenge to mobile application programmers. Our group
membership service guaranteeing that communication
between group members will not suffer from mobility-
induced failure.
To make this strong group membership problem solvable,
we introduce a certain level of synchrony into our system
model. We assume that the communication service is
reliable in each network partition and has a bounded
message delivery time td within the partition.
Furthermore, as we mentioned earlier, a message sent at
time t <td before a network partition takes place can be in
a dubious state of delivery.
We introduce a key concept called safe distance to solve
this problem. It works by preventing a group message
from falling into a packet of network instability caused by
partitioning. We rely on location information to
decide when a host within communication range is
admitted to or eliminated from a group. The group
membership policy is conservative in nature to ensure that
the changes in group membership appear to be atomic,
i.e., are serializable transactions. The algorithm
accommodates the merging of groups. The purpose of our
paper is to maintain the group state information in the


group, i.e., who is and who is not in the working group. A
messages sent between group members are guaranteed to
be delivered successfully.It avoids mobility induced link
failure, ie., it refers to the communication failure caused

unique property of this group membership is that
Local monotonicity: Group identifiers installed
on each host are in increasing order, i.e.,pred (
g,n id) <g <succ(g,n id+1 )

by mobile units moving out of each others communication
range
Initial membership view: A host always installs

2. PROBLEM DEFINITION

Our ultimate goal is to provide application developers
with the ability to maintain a consistent global data
structure in a setting in which mobile hosts come and go
as they please and engage in reliable transient
collaborative activities.
In this context, the group membership service needs to
provide an accurate snapshot of the membership view all
the time, and a message entrusted in a view shall be
guaranteed to be delivered to members in that view,
despite motion and motion-induced disconnections. This
property makes the group membership service useful for
many mobile applications, such as those we mentioned
earlier. Next, we seek to formally define the group
membership problem.

2.1 Membership Specification

The group membership service can be specified by
defining its local state variables and the safety and
progress properties that it satisfies. Let G be the set of all
hosts that exist over time. We assume each host has a
unique identifier denoted by nid and all groups that exist
over time have identifiers drawn from a partially ordered
set G.
Each host in G maintains the following two state
variables: gid and loc.g id is the group identifier and loc is a
subset of G. lid is also called the membership view of G.
Let T= (0, 8) be the range of time. The group ( nid,t)
yields the group identifier for host nid at local time t ;
mem ( nid,t) yields nid â„¢s local view of the membership at
time t . We call a group g if its identifier is g.
We call gâ„¢ a successor of group g if there exists a member
p of g such that the next group p joins after leaving g is gâ„¢,
succ ( g,p) is used to denote the successor of group g
relative to host p ; pred ( g,p) is used to to denote the
predecessor of group g relative to p . Given these terms,
the group membership service is specified in the
following manner:
Self inclusion: A host is always a part of its

itself as the only member in its view when it
starts, i.e.,mem(n id,t)={nid }
Membership Agreement: If hosts p and q have
the same group id, then they have the same
views, i.e.,
Group (p,t p) =group(q,t p) =>mem(p,t p)=mem(q,t p)
Membership change justification: The successor
of group g with respect to p is either a proper
superset or a proper subset of the group g.
Same view message delivery: If host p sends a
message msg host q at time t , and q is in
mem(p,t) , then msg guaranteed to be delivered
to q at time tâ„¢, and mem (q,tâ„¢)=mem(p,t) .
Conditional bounded integration: Let p belong to
group g1 and q belong to group g2. Assume g1
and g2 are the only two groups satisfying the
merging criteria in time T.
There exists a time constant Tc such that, if g1 and g2
stay satisfying the merging criteria for at least time Tc, the
two groups will merge into one group.
The first two safety requirements are common to
most partitionable group membership specifications. The
third requirement in our specification, the initial
membership view requirement, differs from most of those
in the literature and is relatively unique, catering to the
reality of ad hoc mobile environments. A mobile host may
start up with no knowledge of other hosts in the world.
Without requiring bounded integration, a group
membership implementation can simply not perform any
merging of groups.

2.2 System Model

Our system model assumes that there are no host crash
failures and no omission and performance failures caused
by network congestion. The only failure in our system
model is the communication failure caused by hosts
moving out of each otherâ„¢s communication range. This
model is a reasonable starting model for ad hoc mobile
systems for two reasons; they are,
1.Mobility-induced disconnection is much more frequent
than host crash failure given current hardware and
software technology.

membership view, i.e., n id‚¬ mem(nid,t)
2.Second, a mobile network in theory can be equipped
with enough bandwidth for communications needed by

the applications on top of it, such that congestion can be
made a rare event.
in Fig. 1b).We call a group safe if any two members of

3. Solution Strategy

The key to our strategy to implementing the strong
group membership is the notion of safe distance among
hosts and groups, i.e., the idea that, if hosts are close
enough. The disconnection is not possible for some time
and that, if they are just far enough, there is plenty of
time to carry out a configuration change before
disconnection occurs.

3.1 Safe Distance

The concept of safe distance is used to determine when
two groups can be merged and when a group must be split
in order to maintain the requirements for group member-
ship. To determine whether two groups are within safe
distance, one must know the location of all hosts in the
region. Since it is too expensive for everyone to keep
track of the location of others all the time, we designate a
leader for each group. All hosts in a group constantly
report their location to the leader, and the leader keeps the
map of the group, checking constantly to see if the group
members are still within safe distance of each other and
whether new hosts are present in the region.
For example, in Fig. 1a mobile hosts a and b are
within communication range ®, i.e., they are able to talk
to each other directly. They may want to be in the same
group and start coordination or resource sharing
immediately. Yet, they cannot do so at this point if they
wish to guarantee message delivery within the group. This
is because a and b can move out of each otherâ„¢s range
immediately after acknowledging membership in the
same group, with the result being that messages between
them could not be delivered successfully. The problem
arises from the mobile nature of the hosts.
Our solution is to require a and b to agree on membership
in the same group only when they are close enough (as

the group are connected via a path along which all
consecutive host are at the safe distance.
3.2 Group Discovery Method
For a group to merge with another group,it must be able
to discover which groups are present in its vicinity.Host in
each group use safe distance for finding out who is close
enough to be a merge candidate and they report any
positive discoveries to their leader.Host with the smallest
identifier in a group is chosen as the group leader. It
allows the group leader to maintain the list of groups
which are close enough to be considered for merging.

4. Merging

From the information collected in group discovery a
leader may find that there are one or more potential
candidate groups in its vicinity suitable for merging.Once
an agreement is reached regarding who is to participate
and who is responsible for coordinating the merge all
affected host receive a formal notification about the
configuration change from the coordinator. Fig.2. depicts
the merging process between two groups, G1 and G2. G1
contains hosts a and b, and b is the leader. G2 contains
hosts u, v, and w, and has u as its leader. Assume u finds
G1 to be in its vicinity through the discovery data sent in
by v, and G1 is safe for merging. Next, u initiates the
merger by sending a merge-request message to b, the
leader of G1.
If willing to participate in the merger, b sends back an
acknowledgment (ACK) along with its group membership
list and its configuration sequence number; otherwise, it
sends back a disagreement message (NACK), which
forces u to abort the merger with G1. If u gets back an
ACK, as in Fig.2, it generates a new configuration
number by adding one to the larger of the current
configuration numbers of the two groups. Members both
the merge commit and merge-order messages contain the
new group membership list, the new configuration
number, and the new leader identity. Upon receiving the
merge-commit message, b sends a merge-order to its own
members. A host enters the flushing phase after it gets a
merge-order message. It sends a flush-message to all other
members of its original group and stops sending any other
messages until it has received all the expected flush-
messages from its group members in the old
configuration.2 After receiving all the expected flush-
messages, a host enters the new configuration and all new


messages it sends will have the new configuration number
in their

a) Generate new configuration no & send
a[merge commit]packet to the leader of the
new group.
b) Send a [merge order] packet to its members.
Step 7: Temporarily suspend communication till a [flush
message] is received from all its members.
8: If a [flush message] packet is received from all
members in the old configuration. Follow the new
configuration and continue communication. Go to step1.

Step

9: Update the location information.


Step 10: Send get location reply packet to leader.
11: Broadcast a neighbour discovery packet.
Step 12: If neighbour hello packet received then inform
the leader by sending a neighbour available packet.
Step 13: If message order packet is received then send a
flush message packet to all the nodes in the old group.
14: Wait until flush message packet is received
from all the nodes in the old group then continue
communication.

headers. Clearly, hosts may enter the new configuration at
different times.
It is possible for a host that is still in the old configuration
to receive a message from a host that has already reached
the new configuration. In such cases, the recipient must
postpone the processing of this future message until the
new configuration is established, thus pretending that the
message is received in the new configuration.
Otherwise, the consistency requirement that messages
must be sent and received in the same configuration
would be violated. Implementation of this requires a host
to check each received message for the configuration in
which it was sent before it is processed. It is possible for u
and b to initiate the merging at the same time. In this case,
a tie-breaking mechanism decides who is to coordinate
the merger. We use the id as the tiebreaker. The host with
the lower id aborts its merge request when the collision
happens Additional complications may appear when more
than two groups are involved.

5. Merging Algorithm

1: If the node is a leader then go to step2
else go to step10.
Step 2: Update the location information.
Step 3: Send a [get location] packet to all member nodes
in the group member list.
Step 4: If any [get location reply] packet received update
group map list.
5: Send a [neighbour discovery] packet as a
broadcast signal.
Step 6: If neighbour hello packet is received then send
a merge request packet to the leader of the new group.

Go to step1.
6. Implementation

This section describes about implementation of the
project relying on safe distance to achieve group
membership in ad hoc networks and its description.

6.1 Group creation:

The first step is the group formation of nodes which are
all close enough for proper communication. Here, there
are two groups with the first node with three nodes and
second with two nodes. Once the group has been created,
the leader for that group should be allotted. The leader is
node in that with the least node identifier.
Initially all nodes should contain the following:
Node Id: The identifier for each node that is
available with in the group. The Least Id node should
be selected as the leader.
Group Id: The Group Id is same as the Leader
Id to identify which Group is this while undergoing
process like Merging.
Configuration Id: This configuration identifier is
to provide whether the current group has undergone
any change of process.
Location(x,y) : The Location is essential to
identify where each node is actually present to
identify whether it is in safe distance.
Group Member List: This Member List will be
provided by the Leader to indicate what all nodes
present under that group are.
Group View List: The view list is to provide the
members of that group along with their location to
update periodically their node details to find whether
they are all in safe distance for communication.

Ad-Hoc Networks

The nodes which are in the group will complete the
present process and flush out the details to carry out
merging process. And the Acknowledgment for merging
process will be sent to the second group for Merging.
Then the second group has to send the Merge Message to
the nodes in the second group to inform them about the
merging. After that the Merge Commit Message will be
passed to the first groupâ„¢s Leader and the merging will be
completed. Again the leader selection process,
Configuration Id, Group Id will be changed.

Fig 3.Group Creation

6.2 Discovering another Group with in the Safe
Distance

Initially here we have assumed the safe distance as 50.if
the second group is in the safe distance, and then it will
send the Neighbour Discovery Message to the Leader.
The leader of the current group has to send the Neighbour
Hello Message to the leader of the group which is moving
towards the safe distance of the current group.
After this process they both have to check whether both


7.Results

Snap shot of the output shows the initial status of this
project. It describes the following details:
First, groupâ„¢s leader is node that is having the Id 31,
because which is the least one. And the other nodes in the
group are 32, 33.Similarly there is another group with
leader as node 34 and the other member is 35.Then the
configuration Id for those two groups are 122 and 123.
For the upcoming process, which is going to show the
transferring of packets, we allotted the number identifier
for each packet. The following are the Identifiers:

are ready

for merging. Because merging cannot

be performed by suddenly dropping the current processes.
The leader has to inform about the merging it is going to
perform to the nodes of that group.

Gro
up 1

Gro
up 2

IDSafeDistance<=50
Safe Distance

6.3 Merge Commit

After the reception of Neighbour Hello Message the
second group has to send the Merge Request to the first
group. Once the first group received the Merge Request, it
has to inform the nodes about the merging process itâ„¢s
going to perform. This will inform the merging process to
the nodes by using the Flush Message.

Proceedings of the International Conference on Network Security and Workshop 2007 (ICONS 2007)
Erode Sengunthar Engineering College, Tamil Nadu, India, 29-31 January 2007
Snapshot 1
The group view will display the nodes along with their
location. The group id is the same as the Leader Id. The
group member list will display the list of all nodes with in
that group. The packet descriptions are,

1- Get Location Packet.
2- Location Reply Packet.
3- Neighbour Discovery Packet.
4- Neighbour Hello Packet.
5- Neighbour Available Packet.
6- Merge Request Packet.

Snapshot 2
The above snapshot shows how the distance between
them are decreased That the location of each node is
increased continuously in sequence manner and also we
are maintaining a consistent view about the groups.

7- Merge Acknowledgement Packet.
8- Merge Order Packet.
9- Merge Commit Packet.
10- Flush Message Packet.

fault-tolerant systems on top of ad hoc networks very
challenging.
The novel feature of the algorithm is its ability to create
the illusion of announced disconnection. By using
location and mobility information about the mobile hosts
in the region, the membership service is able to guarantee
to the application layer a reliable message delivery service
to group members in the presence of mobility-induced
unannounced disconnection, given appropriate system
assumptions.
This approach represents a new direction in fault-tolerant
distributed computing, one that factors into protocols
information about mobility and space. This work also
provides a practical solution to masking mobility induced
unannounced disconnections in ad hoc mobile systems.

REFERENCES

[1] E.Aneaume, B.Charron-bost, P.Minet and
S.Toueg(1995), On the formal specification of group
membership specification.
[2] .Chockler, I.Keidar, and R.Vitenberg(2001), Group
Communication specification: Comprehensive
J.Gao,L.Guibas,J.Hershberger,L.Zhang and
A.Zhu(2001),Geometric spanner for routing in mobile
networks,PageNo.45-55.
[3] R.Prakash and R.Baldoni(1998), Architecture for
communication for mobile systems, PageNo.235-242
Snapshot 3
In each location updated packet we are decreasing the
distance by increasing the node location of group 31 and
by decreasing the node location of group 34.

8.CONCLUSION

The motivation for this work is to provide data
consistency in applications that execute over ad hoc
networks. Yet, maintaining a consistent view of the global
state in a distributed network is difficult in general and
essentially impossible in the presence of unannounced
disconnections.
In ad hoc mobile systems, mobility-induced unannounced
disconnection occurs frequently as part of the normal
operation of the network. This makes the development of
Reply

Important Note..!

If you are not satisfied with above reply ,..Please

ASK HERE

So that we will collect data for you and will made reply to the request....OR try below "QUICK REPLY" box to add a reply to this page
Popular Searches: ieee membership promotion code 2010, pttphils com loc ca, brajesh chromeitventures com loc es, bard college distance, adhoc on demand distance vector ppt, distance from vemagiri to simhadri, drive safe android source code,

[-]
Quick Reply
Message
Type your reply to this message here.

Image Verification
Please enter the text contained within the image into the text box below it. This process is used to prevent automated spam bots.
Image Verification
(case insensitive)

Possibly Related Threads...
Thread Author Replies Views Last Post
  computer networks full report seminar topics 8 42,004 06-10-2018, 12:35 PM
Last Post: jntuworldforum
  OBJECT TRACKING AND DETECTION full report project topics 9 30,646 06-10-2018, 12:20 PM
Last Post: jntuworldforum
  Vertical Handoff Decision Algorithm Providing Optimized Performance in Heterogeneous Wireless Networks computer science topics 2 30,161 07-10-2016, 09:02 AM
Last Post: ijasti
  imouse full report computer science technology 3 24,888 17-06-2016, 12:16 PM
Last Post: ashwiniashok
  Implementation of RSA Algorithm Using Client-Server full report seminar topics 6 26,602 10-05-2016, 12:21 PM
Last Post: dhanabhagya
  Optical Computer Full Seminar Report Download computer science crazy 46 66,323 29-04-2016, 09:16 AM
Last Post: dhanabhagya
  ethical hacking full report computer science technology 41 74,433 18-03-2016, 04:51 PM
Last Post: seminar report asees
  broadband mobile full report project topics 7 23,310 27-02-2016, 12:32 PM
Last Post: Prupleannuani
  steganography full report project report tiger 15 41,323 11-02-2016, 02:02 PM
Last Post: seminar report asees
  Digital Signature Full Seminar Report Download computer science crazy 20 43,673 16-09-2015, 02:51 PM
Last Post: seminar report asees

Forum Jump: