Location Based - Documentation

Location-Based Spatial Query Processing in Wireless
Broadcast Environments
Abstract:
Location-based spatial queries (LBSQs) refer to spatial queries whose answers rely on the
location of the inquirer. Efficient processing of LBSQs is of critical importance with the
ever-increasing deployment and use of mobile technologies. We show that LBSQs have
certain unique characteristics that the traditional spatial query processing in centralized
databases does not address. For example, a significant challenge is presented by wireless
broadcasting environments, which have excellent scalability but often exhibit high-
latency database access. In this paper, we present a novel query processing technique
that, though maintaining high scalability and accuracy, manages to reduce the latency
considerably in answering LBSQs. Our approach is based on peer-to-peer sharing, which
enables us to process queries without delay at a mobile host by using query results cached
in its neighboring mobile peers. We demonstrate the feasibility of our approach through a
probabilistic analysis, and we illustrate the appeal of our technique through extensive
simulation results.
Chapter 1 - Introduction
SPATIAL query processing is becoming an integral part of many new mobile
applications. Recently, there has been a growing interest in the use of location-based
spatial queries (LBSQs), which represent a set of spatial queries that retrieve information
based on mobile users’ current locations [2], [29].
User mobility and data exchange through wireless communication give LBSQs
some unique characteristics that the traditional spatial query processing in centralized
databases does not address. Novel query processing techniques must be devised to handle
the following new challenges:
1. Mobile query semantics. In a mobile environment, a typical LBSQ is of the form

“find the top-three nearest hospitals.” The result of the query depends on the
location of its requester. Caching and sharing of query results must take into
consideration the location of the query issuer.
2. High workload. The database resides in a centralized server, which typically
serves a large mobile user community through wireless communication.
Consequently, bandwidth constraints and scalability become the two most
important design concerns of LBSQ algorithms.
3. Query promptness and accuracy. Due to user mobility, answers to an LBSQ will
lose their relevancy if there is a long delay in query processing or in
communication. For example, answers to the query “find the top-three nearest
hospitals” received after 5 minutes of high-speed driving will become
meaningless. Instead, a prompt, albeit approximate, answer, telling the user right
away the approximate top-three nearest hospitals, may serve the user much better.
This is an important issue, as a long latency in a high workload wireless
environment is not unusual.
The wireless environment and the communication constraints play an important role in
determining the strategy for processing LBSQs. In the simplest approach, a user
establishes a point-to-point communication with the server so that her queries can be
answered on demand. However, this approach suffers from several drawbacks. First, it
may not scale to very large user populations. Second, to communicate with the server, a
client must most likely use a fee-based cellular-type network to achieve a reasonable
operating range. Third, users must reveal their current location and send it to the server,
which may be undesirable for privacy reasons [19]. A more advanced solution is the
wireless broadcast model [1], [15], [30]. It can support an almost-unlimited number of
mobile hosts (MHs) over a large geographical area with a single transmitter. With the
broadcast model, MHs do not submit queries. Instead, they tune in to the broadcast
channel for information that they desire. Hence, the user’s location is not revealed. One
of the limitations of the broadcast model is that it restricts data access to be sequential.
Queries can only be fulfilled after all the required on-air data arrives. This is why in some
cases; a 5-minute delay to the query “find the top-three nearest hospitals” would not be
unusual.
Alleviating this limitation, we propose a scalable low-latency approach for processing

LBSQs in broadcast environments. Our approach leverages ad hoc networks to share
information among mobile clients in a peer-topeer (P2P) manner [17], [18]. The rationale
behind our approach is based on the following observations:
 As mentioned previously, when a mobile user launches a nearest neighbor (NN)

query, in many situations, she would prefer an approximate result that arrives with
a short response time rather than an accurate result with a long latency.
 The results of spatial queries often exhibit spatial locality. For example, if two
MHs are close to each other, the result sets of their spatial queries may overlap
significantly. Query results of a mobile peer are valuable for two reasons:
o they can be used to answer queries of the current MH directly and
o they can be used to dramatically reduce the latency for the current MH
relative to on-air information.
 . P2P approaches can be valuable for applications where the response time is an
important concern. Through mobile cooperative caching of the result sets, query
results can be efficiently shared among mobile clients.
In this paper, we concentrate on two common types of spatial searches, namely, kNN
queries and window queries (WQs). The contributions of our study are given as follows:
1. We identify certain characteristics of LBSQs that enable the development of

effective sharing methods in broadcast environments.
2. We introduce a set of algorithms that verify whether data received from
neighboring clients are complete, partial, or irrelevant answers to the posed query.
3. We utilize a P2P-based sharing method to improve the current approaches in
answering on-air kNN queries and WQs.
4. We evaluate our approach through a probabilistic analysis of the hit ratio in
sharing. In addition, through extensive simulation experiments, we evaluate the
benefits of our approach with different parameter sets.
Scope of the Project
The scope of the project is to reduce the latency considerably in answering

LBSQs. Our approach is based on peer-to-peer sharing, which enables us to process
queries without delay at a mobile host by using query results cached in its neighboring
mobile peers.
Chapter 2 – Literature Review
2.1 Wireless Data Broadcast
In general, there are two approaches for mobile data access. One is the on-demand access
model, and the other is the wireless broadcast model. For the on-demand access model,
point-to-point connections are established between the server and the mobile clients, and
the server processes queries that the clients submit on demand. For the wireless broadcast
model, the server repeatedly broadcasts all the information in wireless channels, and the
clients are responsible for filtering the information. An example of such a system is the
Microsoft DirectBand Network. The advantage of the broadcast model over the on-
demand model is that it is a scalable approach. However, the broadcast model has large
latency, as clients have to wait for the information that they need in a broadcasting cycle.
If a client misses the packets that it needs, it has to wait for the next broadcast cycle.
To facilitate information retrieval on wireless broadcast channels, the server

usually transmits an index structure, along with data objects. A well-known broadcast
index structure is the (1, m) indexing allocation method [15]. As we can see in Fig. 2, the
whole index is broadcast preceding every 1=m fraction of the data file. Because the index
is available m times in one cycle, it allows a mobile client easy access to the index so that
it can predict the arrival time of its desired data in a timely manner, and once it knows the
arrival time, it only needs to tune into the broadcast channel when the data bucket arrives.
This mechanism is important for battery-based devices.
Thus, the general access protocol for retrieving data on a wireless broadcast
channel involves three main steps [15]:
The initial probe: A client tunes in to the broadcast channel and determines when the
next index segment will be broadcast.
Index search: The client accesses a sequence of pointers in the index segment to figure
out when to tune in to the broadcast channel to retrieve the required data.
Data retrieval: The client tunes in to the channel when packets containing the required
data arrive and then downloads all the required information.
Two parameters, access latency and tuning time, characterize the broadcast
model. The access latency represents the time duration from the point that a client
requests its data to the point that the desired data is received. The tuning time is the
amount of time spent by a client listening to the broadcast channel, which proportionally
represents the power consumption of the client.
However, nearly all the existing spatial access methods are designed for databases with
random access disks. These existing techniques cannot be used effectively in a wireless
broadcast environment, where only sequential data access is supported. Zheng et al. [31]
proposed indexing the spatial data on the server by a space-filling curve. The Hilbert
curve [16] was chosen for this purpose because of its superior locality. The index values
of the data packets represent the order in which these data packets are broadcast. For
example, the Hilbert curve in Fig. 3 tries grouping data of close values so that they can be
accessed within a short interval when they are broadcast sequentially. The MHs use on-
air search algorithms [31] to answer LBSQs (kNN and WQs) over data that arrives in the
order prescribed by the Hilbert curve.
2.2 Spatial Queries
We focus on two common types of spatial queries, namely, kNNqueries and WQs. With
R-tree-based [10] spatial indices, depth-first search (DFS) [25] and best first search
(BFS) [13] have been the prevalent branch-and-bound techniques for processing NN
queries. The DFS method recursively expands the index nodes for searching NN
candidates. At each newly visited nonleaf node, DFS computes the ordering metrics for
all its child nodes and applies pruning strategies to remove unnecessary branches. When a
leaf node is reached, the data objects are retrieved, and theNNcandidates are updated.
Comparatively, the BFS technique utilizes a priority queue to store nodes to be explored
through the search process. The nodes in the queue are sorted according to their
minimum distance (MINDIST) to the query point. During the search process, BFS
repeatedly dequeues the top entry in the queue and enquires its child nodes with their
MINDIST into the queue. When a data entry is dequeued, it is inserted into the result set.
For WQs that find objects within a specified area, the R-tree families [3], [26] provide
efficient access to disk-based databases. Basically, an R-tree structure groups objects
close to each other into a minimum bounding rectangle (MBR), and a range query only
visits MBRs that overlap with the query area.
2.3 Cooperative Caching
Caching is a key technique to improve data retrieval performance in widely distributed

environments [14], [21], [22]. Hara and Madria proposed three data replica allocation
methods in ad hoc networks by considering the access frequency from MHs to each data
item and the status of the network connection [12]. With the increasing deployment of
new P2P wireless communication technologies (for example, IEEE 802.11b/g and
Bluetooth), P2P cooperative caching becomes an effective sharing alternative [6], [11],
[28]. With this technique, MHs communicate with neighboring peers in an ad hoc manner
for information sharing instead of relying solely on the communication between remote
information sources. Yin and Cao [28] proposed three schemes, that is, CachePath,
CacheData, and HybridCache, for cooperative caching in ad hoc networks. With
CachePath, mobile nodes cache the data path and use it to redirect prospective requests to
a neighboring node, which has the data instead of fetching data from the remote data
center. With CacheData, intermediate nodes cache the data to serve prospective queries.
The HybridCache approach further improves performance by taking advantage of both
CacheData and CachePath while avoiding their weaknesses. P2P cooperative caching can
bring about several distinctive benefits to a mobile system: improved access latency,
reduced server workload, and alleviated point-to- point channel congestion. In this
research, we leverage the P2P caching technique to alleviate the inherent access latency
limitation in wireless broadcast environments.
Chapter 3 – System Analysis
3.1 Existing System
• Existing techniques cannot be used effectively in a wireless broadcast

environment, where only sequential data access is supported.
• It may not scale to very large user populations.
• In an existing system to communicate with the server, a client must most
likely use a fee-based cellular-type network to achieve a reasonable
operating range.
• Third, users must reveal their current location and send it to the server,
which may be undesirable for privacy reasons
3.4 Proposed System
• This System is a novel approach for reducing the spatial query access latency
by leveraging results from nearby peers in wireless broadcast environments.
• Our scheme allows a mobile client to locally verify whether candidate objects
received from peers are indeed part of its own spatial query result set.
• The method exhibits great scalability: the higher the mobile peer density, the
more the queries answered by peers.
• The query access latency can be decreased with the increase in clients.
3.3 System Requirement Specification
Software Interface
• JDK 1.5
• Java Swing
• SQL Server
Hardware Interface
• PROCESSOR : PENTIUM IV 2.6 GHz

• RAM : 512 MB DD RAM
• MONITOR : 15” COLOR
• HARD DISK : 40 GB
• KEYBOARD : STANDARD 102 KEYS
• MOUSE : 3 BUTTON
3.4 Modules:
• Multiple peer simulation Module
• Server Module
• Sharing-based nearest neighbor query visualization Module
3.5 Software Description
Java Technology
Java technology is both a programming language and a platform.
The Java Programming Language
The Java programming language is a high-level language that can be
characterized by all of the following buzzwords:
 Simple
 Architecture neutral
 Object oriented
 Portable
 Distributed
 High performance
 Interpreted
 Multithreaded
 Robust
 Dynamic
 Secure
With most programming languages, you either compile or interpret a program so that you
can run it on your computer. The Java programming language is unusual in that a
program is both compiled and interpreted. With the compiler, first you translate a
program into an intermediate language called Java byte codes —the platform-
independent codes interpreted by the interpreter on the Java platform. The interpreter
parses and runs each Java byte code instruction on the computer. Compilation happens
just once; interpretation occurs each time the program is executed. The following figure
illustrates how this works.
FIGURE 2- WORKING OF JAVA

You can think of Java bytecodes as the machine code instructions for the Java
Virtual Machine (Java VM). Every Java interpreter, whether it’s a development tool or a
Web browser that can run applets, is an implementation of the Java VM. Java bytecodes
help make “write once, run anywhere” possible. You can compile your program into
bytecodes on any platform that has a Java compiler. The bytecodes can then be run on
any implementation of the Java VM. That means that as long as a computer has a Java
VM, the same program written in the Java programming language can run on Windows
2000, a Solaris workstation, or on an iMac.
The Java Platform

A platform is the hardware or software environment in which a program runs.
We’ve already mentioned some of the most popular platforms like Windows 2000,
Linux, Solaris, and MacOS. Most platforms can be described as a combination of the
operating system and hardware. The Java platform differs from most other platforms in
that it’s a software-only platform that runs on top of other hardware-based platforms.
The Java platform has two components:
• The Java Virtual Machine (Java VM)
• The Java Application Programming Interface (Java API)
You’ve already been introduced to the Java VM. It’s the base for the Java
platform and is ported onto various hardware-based platforms.
The Java API is a large collection of ready-made software components that provide many
useful capabilities, such as graphical user interface (GUI) widgets. The Java API is
grouped into libraries of related classes and interfaces; these libraries are known as
packages. The next section, What Can Java Technology Do?, highlights what
functionality some of the packages in the Java API provide.
The following figure depicts a program that’s running on the Java platform. As
the figure shows, the Java API and the virtual machine insulate the program from the
hardware.
FIGURE 3- THE JAVA PLATFORM
Native code is code that after you compile it, the compiled code runs on a specific
hardware platform. As a platform-independent environment, the Java platform can be a
bit slower than native code. However, smart compilers, well-tuned interpreters, and just-
in-time bytecode compilers can bring performance close to that of native code without
threatening portability.
What Can Java Technology Do?

The most common types of programs written in the Java programming language
are applets and applications. If you’ve surfed the Web, you’re probably already familiar
with applets. An applet is a program that adheres to certain conventions that allow it to
run within a Java-enabled browser.
However, the Java programming language is not just for writing cute, entertaining
applets for the Web. The general-purpose, high-level Java programming language is also
a powerful software platform. Using the generous API, you can write many types of
programs.
An application is a standalone program that runs directly on the Java platform. A
special kind of application known as a server serves and supports clients on a network.
Examples of servers are Web servers, proxy servers, mail servers, and print servers.
Another specialized program is a servlet. A servlet can almost be thought of as an applet
that runs on the server side. Java Servlets are a popular choice for building interactive
web applications, replacing the use of CGI scripts. Servlets are similar to applets in that
they are runtime extensions of applications. Instead of working in browsers, though,
servlets run within Java Web servers, configuring or tailoring the server.
How does the API support all these kinds of programs? It does so with packages
of software components that provide a wide range of functionality. Every full
implementation of the Java platform gives you the following features:
• The essentials: Objects, strings, threads, numbers, input and output, data
structures, system properties, date and time, and so on.
• Applets: The set of conventions used by applets.
• Networking: URLs, TCP (Transmission Control Protocol), UDP (User Data gram
Protocol) sockets, and IP (Internet Protocol) addresses.
• Internationalization: Help for writing programs that can be localized for users
worldwide. Programs can automatically adapt to specific locales and be displayed
in the appropriate language.
• Security: Both low level and high level, including electronic signatures, public
and private key management, access control, and certificates.
• Software components: Known as JavaBeansTM, can plug into existing component
architectures.
• Object serialization: Allows lightweight persistence and communication via
Remote Method Invocation (RMI).
• Java Database Connectivity (JDBCTM): Provides uniform access to a wide
range of relational databases.
The Java platform also has APIs for 2D and 3D graphics, accessibility, servers,
collaboration, telephony, speech, animation, and more. The following figure depicts what
is included in the Java 2 SDK.
FIGURE 4 – JAVA 2 SDK

ODBC
Microsoft Open Database Connectivity (ODBC) is a standard programming
interface for application developers and database systems providers. Before ODBC
became a de facto standard for Windows programs to interface with database systems,
programmers had to use proprietary languages for each database they wanted to connect
to. Now, ODBC has made the choice of the database system almost irrelevant from a
coding perspective, which is as it should be. Application developers have much more
important things to worry about than the syntax that is needed to port their program from
one database to another when business needs suddenly change.
Through the ODBC Administrator in Control Panel, you can specify the particular
database that is associated with a data source that an ODBC application program is
written to use. Think of an ODBC data source as a door with a name on it. Each door will
lead you to a particular database. For example, the data source named Sales Figures
might be a SQL Server database, whereas the Accounts Payable data source could refer
to an Access database. The physical database referred to by a data source can reside
anywhere on the LAN.
The ODBC system files are not installed on your system by Windows 95. Rather,
they are installed when you setup a separate database application, such as SQL Server
Client or Visual Basic 4.0. When the ODBC icon is installed in Control Panel, it uses a
file called ODBCINST.DLL. It is also possible to administer your ODBC data sources
through a stand-alone program called ODBCADM.EXE. There is a 16-bit and a 32-bit
version of this program, and each maintains a separate list of ODBC data sources.
From a programming perspective, the beauty of ODBC is that the application can
be written to use the same set of function calls to interface with any data source,
regardless of the database vendor. The source code of the application doesn’t change
whether it talks to Oracle or SQL Server. We only mention these two as an example.
There are ODBC drivers available for several dozen popular database systems. Even
Excel spreadsheets and plain text files can be turned into data sources. The operating
system uses the Registry information written by ODBC Administrator to determine
which low-level ODBC drivers are needed to talk to the data source (such as the interface
to Oracle or SQL Server). The loading of the ODBC drivers is transparent to the ODBC
application program. In a client/server environment, the ODBC API even handles many
of the network issues for the application programmer.
The advantages of this scheme are so numerous that you are probably thinking there must
be some catch. The only disadvantage of ODBC is that it isn’t as efficient as talking
directly to the native database interface. ODBC has had many detractors make the charge
that it is too slow. Microsoft has always claimed that the critical factor in performance is
the quality of the driver software that is used. In our humble opinion, this is true. The
availability of good ODBC drivers has improved a great deal recently. And anyway, the
criticism about performance is somewhat analogous to those who said that compilers
would never match the speed of pure assembly language. Maybe not, but the compiler (or
ODBC) gives you the opportunity to write cleaner programs, which means you finish
sooner. Meanwhile, computers get faster every year.
JDBC
In an effort to set an independent database standard API for Java, Sun
Microsystems developed Java Database Connectivity, or JDBC. JDBC offers a generic
SQL database access mechanism that provides a consistent interface to a variety of
RDBMSs. This consistent interface is achieved through the use of “plug-in” database
connectivity modules, or drivers. If a database vendor wishes to have JDBC support, he
or she must provide the driver for each platform that the database and Java run on.
To gain a wider acceptance of JDBC, Sun based JDBC’s framework on ODBC.
As you discovered earlier in this chapter, ODBC has widespread support on a variety of
platforms. Basing JDBC on ODBC will allow vendors to bring JDBC drivers to market
much faster than developing a completely new connectivity solution.
JDBC was announced in March of 1996. It was released for a 90 day public review that
ended June 8, 1996. Because of user input, the final JDBC v1.0 specification was
released soon after.
The remainder of this section will cover enough information about JDBC for you
to know what it is about and how to use it effectively. This is by no means a complete
overview of JDBC. That would fill an entire book.
JDBC Goals
Few software packages are designed without goals in mind. JDBC is one that,
because of its many goals, drove the development of the API. These goals, in conjunction
with early reviewer feedback, have finalized the JDBC class library into a solid
framework for building database applications in Java.
The goals that were set for JDBC are important. They will give you some insight
as to why certain classes and functionalities behave the way they do. The eight design
goals for JDBC are as follows:
1. SQL Level API
The designers felt that their main goal was to define a SQL interface for Java.
Although not the lowest database interface level possible, it is at a low enough level for
higher-level tools and APIs to be created. Conversely, it is at a high enough level for
application programmers to use it confidently. Attaining this goal allows for future tool
vendors to “generate” JDBC code and to hide many of JDBC’s complexities from the end
user.
2. SQL Conformance
SQL syntax varies as you move from database vendor to database vendor. In an effort to
support a wide variety of vendors, JDBC will allow any query statement to be passed
through it to the underlying database driver. This allows the connectivity module to
handle non-standard functionality in a manner that is suitable for its users.
3. JDBC must be implemental on top of common database interfaces
The JDBC SQL API must “sit” on top of other common SQL level APIs. This
goal allows JDBC to use existing ODBC level drivers by the use of a software
interface. This interface would translate JDBC calls to ODBC and vice versa.
4. Provide a Java interface that is consistent with the rest of the Java
system
Because of Java’s acceptance in the user community thus far, the designers feel that they
should not stray from the current design of the core Java system.
5. Keep it simple
This goal probably appears in all software design goal listings. JDBC is no exception.
Sun felt that the design of JDBC should be very simple, allowing for only one method of
completing a task per mechanism. Allowing duplicate functionality only serves to
confuse the users of the API.
6. Use strong, static typing wherever possible
Strong typing allows for more error checking to be done at compile time; also, less
error appear at runtime.
7. Keep the common cases simple
Because more often than not, the usual SQL calls used by the programmer are simple
SELECT’s, INSERT’s, DELETE’s and UPDATE’s, these queries should be simple to perform
with JDBC. However, more complex SQL statements should also be possible.
Networking
TCP/IP stack
The TCP/IP stack is shorter than the OSI one:

FIGURE 5 – TCP/IP STACK
TCP is a connection-oriented protocol; UDP (User Datagram Protocol) is a

connectionless protocol.
IP datagram’s
The IP layer provides a connectionless and unreliable delivery system. It

considers each datagram independently of the others. Any association between datagram
must be supplied by the higher layers. The IP layer supplies a checksum that includes its
own header. The header includes the source and destination addresses. The IP layer
handles routing through an Internet. It is also responsible for breaking up large datagram
into smaller ones for transmission and reassembling them at the other end.
TCP
TCP supplies logic to give a reliable connection-oriented protocol above IP. It

provides a virtual circuit that two processes can use to communicate.
Internet addresses
In order to use a service, you must be able to find it. The Internet uses an address
scheme for machines so that they can be located. The address is a 32 bit integer which
gives the IP address. This encodes a network ID and more addressing. The network ID
falls into various classes according to the size of the network address.
Network address
Class A uses 8 bits for the network address with 24 bits left over for other
addressing. Class B uses 16 bit network addressing. Class C uses 24 bit network
addressing and class D uses all 32.
Subnet address
Internally, the UNIX network is divided into sub networks. Building 11 is

currently on one sub network and uses 10-bit addressing, allowing 1024 different hosts.
Host address
8 bits are finally used for host addresses within our subnet. This places a limit of
256 machines that can be on the subnet.
Total address
FIGURE 6 - IP ADDRESSING
The 32 bit address is usually written as 4 integers separated by dots.
Port addresses
A service exists on a host, and is identified by its port. This is a 16 bit number. To
send a message to a server, you send it to the port for that service of the host that it is
running on. This is not location transparency! Certain of these ports are "well known".
Sockets
A socket is a data structure maintained by the system to handle network

connections. A socket is created using the call socket. It returns an integer that is like a
file descriptor. In fact, under Windows, this handle can be used with Read File and
Write File functions.
#include <sys/types.h>
#include <sys/socket.h>
int socket(int family, int type, int protocol);
Here "family" will be AF_INET for IP communications, protocol will be zero, and type
will depend on whether TCP or UDP is used. Two processes wishing to communicate
over a network create a socket each. These are similar to two ends of a pipe - but the
actual pipe does not yet exist.
Chapter 4 – System Design
Module 1
Mobile Host1
Finding nearest
Neighbor
Mobile Host 2
Module 2
Mobile Host Centralized Server

Module 3
MH2
MH1 Server
MH3
Data Flow Diagram
d
lize MH4
a
entr rver
C Se
MH
3
MH
1 MH
2
MH-Mobile Host
Chapter 5 - Module Description
5.1 Multiple peer simulation Module
The multiple peer simulation modules concurrently model a predefined number of mobile
hosts. It implements all the functionality of a single mobile host and provides the
communication facilities among peers and from peers to remote spatial database servers.
5.2 Server Module
The server module is responsible for storing points of interest indexed by an R-tree
structure. It performs NN queries from peers with pruning bounds and records the I/O
load and access frequency of the spatial database server.
5.3 Sharing-based nearest neighbor query visualization Module
The sharing-based nearest neighbor query visualization Module provides a rendering of

the verification process of a sharing-based NN query in a step-by-step manner. Users can
arbitrarily select a mobile host and launch a location-based NN query within the
simulation region.
5.4 In module given input and expected output
The Query location and preferred criteria are the input for Mobile Host. The Mobile Host
gets the results for the corresponding location and criteria, with considerably reducing
latency while getting results from neighboring peers.
Chapter 6 – System Testing
The purpose of testing is to discover errors. Testing is the process of trying to

discover every conceivable fault or weakness in a work product. It provides a way to
check the functionality of components, sub assemblies, assemblies and/or a finished
product It is the process of exercising software with the intent of ensuring that the
Software system meets its requirements and user expectations and does not fail in an
unacceptable manner. There are various types of test. Each test type addresses a specific
testing requirement.
TYPES OF TESTS
Unit testing
Unit testing involves the design of test cases that validate that the internal program
logic is functioning properly, and that program inputs produce valid outputs. All decision
branches and internal code flow should be validated. It is the testing of individual
software units of the application .it is done after the completion of an individual unit
before integration. This is a structural testing, that relies on knowledge of its construction
and is invasive. Unit tests perform basic tests at component level and test a specific
business process, application, and/or system configuration. Unit tests ensure that each
unique path of a business process performs accurately to the documented specifications
and contains clearly defined inputs and expected results.
Integration testing
Integration tests are designed to test integrated software components to determine
if they actually run as one program. Testing is event driven and is more concerned with
the basic outcome of screens or fields. Integration tests demonstrate that although the
components were individually satisfaction, as shown by successfully unit testing, the
combination of components is correct and consistent. Integration testing is specifically
aimed at exposing the problems that arise from the combination of components.
Functional test
Functional tests provide systematic demonstrations that functions tested are

available as specified by the business and technical requirements, system documentation,
and user manuals.
Functional testing is centered on the following items:
Valid Input : identified classes of valid input must be accepted.
Invalid Input : identified classes of invalid input must be rejected.
Functions : identified functions must be exercised.
Output : identified classes of application outputs must be exercised.
Systems/Procedures: interfacing systems or procedures must be invoked.
Organization and preparation of functional tests is focused on requirements, key

functions, or special test cases. In addition, systematic coverage pertaining to identify
Business process flows; data fields, predefined processes, and successive processes must
be considered for testing. Before functional testing is complete, additional tests are
identified and the effective value of current tests is determined.
System Test
System testing ensures that the entire integrated software system meets requirements.
It tests a configuration to ensure known and predictable results. An example of system
testing is the configuration oriented system integration test. System testing is based on
process descriptions and flows, emphasizing pre-driven process links and integration
points.
White Box Testing
White Box Testing is a testing in which in which the software tester has
knowledge of the inner workings, structure and language of the software, or at least its
purpose. It is purpose. It is used to test areas that cannot be reached from a black box
level.
Black Box Testing
Black Box Testing is testing the software without any knowledge of the inner
workings, structure or language of the module being tested. Black box tests, as most other
kinds of tests, must be written from a definitive source document, such as specification or
requirements document, such as specification or requirements document. It is a testing in
which the software under test is treated, as a black box .you cannot “see” into it. The test
provides inputs and responds to outputs without considering how the software works.
6.1 Unit Testing:
Unit testing is usually conducted as part of a combined code and unit test phase of
the software lifecycle, although it is not uncommon for coding and unit testing to be
conducted as two distinct phases.
Test strategy and approach

Field testing will be performed manually and functional tests will be written in
detail.
Test objectives
• All field entries must work properly.
• Pages must be activated from the identified link.
• The entry screen, messages and responses must not be delayed.
Features to be tested
• Verify that the entries are of the correct format
• No duplicate entries should be allowed
• All links should take the user to the correct page.
6.2 Integration Testing
Software integration testing is the incremental integration testing of two or more

integrated software components on a single platform to produce failures caused by
interface defects.
The task of the integration test is to check that components or software
applications, e.g. components in a software system or – one step up – software
applications at the company level – interact without error.
Test Results: All the test cases mentioned above passed successfully. No defects
encountered.
6.3 Acceptance Testing
User Acceptance Testing is a critical phase of any project and requires significant
participation by the end user. It also ensures that the system meets the functional
requirements.
Test Results: All the test cases mentioned above passed successfully. No defects
encountered.
Chapter 7 – System Implementation
Technique used or algorithm used
• Peer to Peer Communication technique

• Nearest Neighbor Verification Method
• Sharing Based Nearest Neighbor
• Sharing Based Window Query
Advantages
• Maintaining high scalability and accuracy.

• Reducing the latency while processing query to neighboring peers.
Applications
Now a day this is used in mobile search application to get the approximate result
in short time instead of getting accurate results in long time.
Sample Source Code
CentralizedServer.java
import javax.swing.*;
import java.io.*;
import java.awt.*;
import java.sql.*;
import java.net.*;
public class CentralizedServer extends javax.swing.JFrame {
//ServerSocket ss2;
ServerSocket ss3;
Socket s2,s3;
Socket s4,s6;
Socket s5;
Socket s7;
Socket s8;
Jdbc d = new Jdbc();
int Count = 1;
String[] send;
String[] send1;
String[] send2;
String portno;
String direction;
String distance;
String location;
String criteria;
String mh1;
String mh2;
String mh3;
ResultSet rs;
/** Creates new form CentralizedServer */
public CentralizedServer() {
initComponents();
setVisible(true);
setSize(1200,1000);
try {
ss3 = new ServerSocket(6666);
} catch (Exception e) {
e.printStackTrace();
}
private void initComponents() {
jLabel1 = new javax.swing.JLabel();

//jButton1 = new javax.swing.JButton();
jButton2 = new javax.swing.JButton();
jScrollPane1 = new javax.swing.JScrollPane();
jTextArea1 = new javax.swing.JTextArea();
jScrollPane2 = new javax.swing.JScrollPane();
jTextArea2 = new javax.swing.JTextArea();
//jButton5 = new javax.swing.JButton();
jSeparator1 = new javax.swing.JSeparator();
jTextField1 = new javax.swing.JTextField();
setDefaultCloseOperation(javax.swing.WindowConstants.EXIT_ON_CLOSE);
getContentPane().setLayout(null);
jLabel1.setFont(new java.awt.Font("Microsoft Sans Serif", 3, 18)); // NOI18N

jLabel1.setText("Centralized Server");
getContentPane().add(jLabel1);
jLabel1.setBounds(440, 30, 190, 30);
jButton2.setFont(new java.awt.Font("Microsoft Sans Serif", 2, 14)); // NOI18N

jButton2.setText("Process Query");
getContentPane().add(jButton2);
jButton2.setBounds(130, 140, 140, 30);
jButton2.addActionListener(new java.awt.event.ActionListener() {
public void actionPerformed(java.awt.event.ActionEvent evt) {
jButton2ActionPerformed(evt);
}
});

jButton3.setText("View MH_DB");
}
});

jButton4.setText("View Query_DB");
}
});
jTextArea1.setColumns(20);
jTextArea1.setRows(5);
jScrollPane1.setViewportView(jTextArea1);
getContentPane().add(jScrollPane1);
jScrollPane1.setBounds(330, 140, 160, 210);
jTextArea2.setColumns(20);
jTextArea2.setRows(5);
jScrollPane2.setViewportView(jTextArea2);
getContentPane().add(jScrollPane2);
jScrollPane2.setBounds(550, 140, 160, 210);

jLabel2.setText("DB_Details");

jLabel3.setText("Server Info");

jButton6.setText("Search Nearest Neighbour");
}
});
getContentPane().add(jSeparator1);
jSeparator1.setBounds(0, 402, 1200, 10);

jButton7.setText("Response To MH");
}
});

jButton8.setText("Server Process");
}
});

jLabel4.setText("Server DB Storage");

jLabel5.setText("PortNumber");

jLabel6.setText("Query Loc");

jLabel7.setText("Criteria");

jLabel8.setText("Query Results");
getContentPane().add(jTextField1);
jTextField1.setBounds(530, 470, 110, 30);

jButton9.setText("Save");
}
});

jButton10.setText("Clear");
}
});

jButton11.setText("Exit");
}
});
pack();
mh1=JOptionPane.showInputDialog(this,"Enter MH-1 IP","localhost");

}// </editor-fold>//GEN-END:initComponents
try {
s2 = ss2.accept();
private void jButton2ActionPerformed(java.awt.event.ActionEvent evt) {//GEN-
FIRST:event_jButton2ActionPerformed
// TODO add your handling code here:
try {
s3 = ss3.accept();
DataInputStream dis = new
DataInputStream(s3.getInputStream());
String dd11= dis.readUTF();
send = dd11.split("&");
jTextArea2.append("Query Details :"+"\n");
for (int i = 0; i < send.length; i++)
{
String string = send[i];
}
//System.out.println(send[0]+""+send[1]+""+send[2]);
d.insertServer("insert into Requested_Hosts
values('"+send[0]+"','"+send[1]+"','"+send[2]+"')");
jTextArea2.append(Count+"."+"Port
Number :"+send[0]+"\n");
location=send[1];
criteria=send[2];
jTextArea2.append("Location : "+send[1]+"\n");
jTextArea2.append("Criteria : "+send[2]+"\n");
Count++;
}
}

try {
String ss = d.retrive("select * from DD_Details");

String cols[] = ss.split("&");
for (int i = 0; i < cols.length; i++)
{
String string = cols[i];
String[] MH = string.split("%");
for (int j = 0; j < MH.length; j++)
{
String string1 =
MH[j];
jTextArea1.append(string1+"\t");
}
jTextArea1.append("\n");
}
}

try {
jTextArea1.append("Query With Results : "+"\n"+"Portno Location
Criteria Results "+"\n");
String ss1 = d.retriveResults("select * from Query_Results");
String cols1[] = ss1.split("&");
for (int i = 0; i < cols1.length; i++)
{
String string1 = cols1[i];
String[] QR = string1.split("%");
for (int j = 0; j < QR.length; j++)
{
String string2
= QR[j];
jTextArea1.append(string2+"\t");
}
jTextArea1.append("\n");
}
}
}
String s0 = send[0];
JOptionPane.showMessageDialog(this,s0);
double servertime = System.currentTimeMillis();

System.out.println("Server Time : "+servertime+" ms");
try {
if(s0.equals("1111"))
{
int PortNo = d.retrivePort("select Portno
from Query_Results where Location='"+send[1]+"'and Criteria='"+send[2]+"'");
System.out.println("Port Number:
"+PortNo);
s5 = new Socket(mh1,4444);
DataOutputStream doutport = new
DataOutputStream(s5.getOutputStream());
doutport.writeInt(PortNo);
}
else if(s0.equals("2222"))
{
"+PortNo);
}
else if(s0.equals("3333"))
{
"+PortNo);
}
}catch (Exception e) {
}


String ser0 = send[0];
System.out.println("ser val "+ser0+" "+ser1+" "+ser2);
try
{
if(ser0.equals("1111"))
{
String fromServer = d.gettingResults("select Results from Query_Results
where Location = '"+ser1+"' and Criteria = '"+ser2+"' ");
DataOutputStream dosser = new
dosser.writeUTF(fromServer);
}else if(ser0.equals("2222"))
{
}else if(ser0.equals("3333"))
{
}
}
catch (Exception er)
{
er.printStackTrace();
}

String pno = jTextField1.getText();
String qlc = jTextField2.getText();
String cri = jTextField3.getText();
String rst = jTextField4.getText();
if(pno.equals(""))
{
JOptionPane.showMessageDialog(this,"Enter Port Number");
}
else if(qlc.equals(""))
{
JOptionPane.showMessageDialog(this,"Enter Query Location");
}
else if(cri.equals(""))
{
JOptionPane.showMessageDialog(this,"Enter criteria");
}
else if(rst.equals(""))
{
JOptionPane.showMessageDialog(this,"Enter Results");
}
else if(jButton6!=null)
{
String bu6mess = "Do You Want Save in Database?";
int b4 = JOptionPane.showConfirmDialog(this, bu6mess);

if(b4==0)
{
try {
d.insertServer("insert into Query_Results
values('"+pno+"','"+qlc+"','"+cri+"','"+rst+"')");
}
}
}
}

jTextField1.setText("");
}

System.exit(0);
}
public static void main(String args[]) {
new CentralizedServer();
// Variables declaration - do not modify//GEN-BEGIN:variables

private javax.swing.JButton jButton1;
private javax.swing.JLabel jLabel1;
private javax.swing.JScrollPane jScrollPane1;
private javax.swing.JScrollPane jScrollPane2;
private javax.swing.JSeparator jSeparator1;
private javax.swing.JTextArea jTextArea1;
private javax.swing.JTextArea jTextArea2;
private javax.swing.JTextField jTextField1;
// End of variables declaration//GEN-END:variables
}
JDBC.java:
import javax.swing.*;
import java.io.*;
import java.awt.*;
import java.sql.*;
class Jdbc
{
// insert Client Method Calls
public String insertClient(String query)
{
try {
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
Connection con = DriverManager.getConnection("jdbc:odbc:Mobile","sa","");
Statement st = con.createStatement();
st.executeUpdate(query);
System.out.println("Connection Not Found"+e);
}
return "";
}
// insert Server Method Calls

public String insertServer(String query)
{
try {
Connection con =
DriverManager.getConnection("jdbc:odbc:MobileServer","sa","");
st.executeUpdate(query);
System.out.println("Connection Not Found"+e);
}
return "";
}
// retrive Method Calls

public String retrive(String query)
{
String values = "";
try {
Connection con =
ResultSet rs = st.executeQuery(query);
while(rs.next())
{
values += rs.getString("Portno")+"%"+;
}
}
return values;
}
// retriveResults Method Calls
public String retriveResults(String query)

{
String rsts = "";
try {
Connection con =
while(rs.next())
{
rsts += rs.getString("Portno")+"%"+ rs.getString("Location")
+"%"+rs.getString("Criteria")+"%"+rs.getString("Results")+"&";
}
}
return rsts;
}
// retrive Method Calls

public String retriveFinalrst(String query)
{
String finalrst = "";
try {
while(rs.next())
{
finalrst += rs.getString(1);
}
}
return finalrst;
}
// Search Method Calls

public int search(String query)
{
int searchResults=0;
try {
Connection con =
ResultSet rs=st.executeQuery(query);
while(rs.next())
{
searchResults=rs.getInt(1);
}
System.out.println(searchResults);
JOptionPane jp=new JOptionPane();
}
return searchResults;
}
// retrivePort Method Calls
public int retrivePort(String query)

{
int port =0;
try {
Connection con =
if(rs.next()==true)
{
port+= rs.getInt(1);
jp.showMessageDialog(jp,"Port Number : "+port);
}
return port;
}
// retriveMH2db Method Calls
public String retriveMH2db(String query)

{
String rst1 = "";
try {
while(rs.next())
{
rst1 += rs.getString("Results");
jp.showConfirmDialog(jp,"Do You Want Send Query To Nearest
MobileHost");
}
return rst1;
}
public String gettingResults(String query)

{
String onlyServer="";
try {
Connection con =
while(rs.next())
{
onlyServer=rs.getString("Results");
}
System.out.println(onlyServer);

jp.showMessageDialog(jp,"Getting From Server : "+onlyServer);
}
return onlyServer;
}
public String neighbourSearch(String query)

{
String rtnport="";
try {
Connection con =
while(rs.next())
{
rtnport=rs.getString("Portno");
}
System.out.println(rtnport);

jp.showMessageDialog(jp,"Neighbour Port : "+rtnport);
}
return rtnport;
}
public static void main(String[] args)

{
new Jdbc();
}
}
Chapter 8 – Conclusion & Future Enhancement
This paper presented a novel approach for reducing the spatial query access latency by
leveraging results from nearby peers in wireless broadcast environments. Significantly,
our scheme allows a mobile client to locally verify whether candidate objects received
from peers are indeed part of its own spatial query result set. The experiment results
indicate that our method can reduce the access to the wireless broadcast channel by a
significant amount, for example, up to 80 percent, in a dense urban area. This is achieved
with minimal caching at the peers. By virtue of its P2P architecture, the method exhibits
great scalability: the higher the mobile peer density, the more the queries answered by
peers. Therefore, the query access latency can be markedly decreased with the increase in
clients.
Screenshots
References
[1] S. Acharya, R. Alonso, M.J. Franklin, and S.B. Zdonik, “Broadcast Disks: Data
Management for Asymmetric Communications Environments,” Proc. ACM SIGMOD
’95, pp. 199-210, 1995.
[2] D. Barbara´ , “Mobile Computing and Databases: A Survey,” IEEE Trans.

Knowledge and Data Eng., vol. 11, no. 1, pp. 108-117, Jan./Feb. 1999.
[3] N. Beckmann, H.-P. Kriegel, R. Schneider, and B. Seeger, “The R*-Tree: An

Efficient and Robust Access Method for Points and Rectangles,” Proc. ACM SIGMOD
’90, pp. 322-331, 1990.
[4] J. Broch, D.A. Maltz, D.B. Johnson, Y.-C. Hu, and J.G. Jetcheva, “A Performance
Comparison of Multi-Hop Wireless Ad Hoc Network Routing Protocols,” Proc. ACM
MobiCom ’98, pp. 85-97, 1998.
[5] V. Bychkovsky, B. Hull, A.K. Miu, H. Balakrishnan, and S. Madden, “A

Measurement Study of Vehicular Internet Access Using In Situ Wi-Fi Networks,” Proc.
ACM MobiCom ’06, Sept. 2006.
[6] C.-Y. Chow, H. Va Leong, and A. Chan, “Peer-to-Peer Cooperative Caching in

Mobile Environment,” Proc. 24th IEEE Int’l Conf. Distributed Computing Systems
Workshops (ICDCSW ’04), pp. 528-533, 2004.
[7] C.-Y. Chow, H. Va Leong, and A.T.S. Chan, “Distributed Group- Based Cooperative
Caching in a Mobile Broadcast Environment,” Mobile Data Management, pp. 97-106,
2005.
[8] M. de Berg, M. van Kreveld, M. Overmars, and O. Schwarzkopf, Computational
Geometry Algorithms and Applications, second ed. Springer, 2000.
[9] G. Gaertner and V. Cahill, “Understanding Link Quality in 802.11 Mobile Ad Hoc
Networks,” IEEE Internet Computing, vol. 8, no. 1, pp. 55-60, 2004.
[10] A. Guttman, “R-Trees: A Dynamic Index Structure for Spatial Searching,” Proc.
ACM SIGMOD ’84, pp. 47-57, June 1984.
[11] T. Hara, “Cooperative Caching by Mobile Clients in Push-Based Information

Systems,” Proc. 11th ACM Int’l Conf. Information and Knowledge Management (CIKM
’02), pp. 186-193, 2002.
[12] T. Hara and S.K. Madria, “Data Replication for Improving Data Accessibility in Ad
Hoc Networks,” IEEE Trans. Mobile Computing, vol. 5, no. 11, pp. 1515-1532, Nov.
2006.
[13] G.R. Hjaltason and H. Samet, “Distance Browsing in Spatial Databases,” ACM
Trans. Database Systems, vol. 24, no. 2, pp. 265-318, 1999.

Location Based - Documentation

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Location Based - Documentation

Загружено:

Авторское право:

Доступные форматы

Location-Based Spatial Query Processing in Wireless

1. Mobile query semantics. In a mobile environment, a typical LBSQ is of the form

Alleviating this limitation, we propose a scalable low-latency approach for processing

 As mentioned previously, when a mobile user launches a nearest neighbor (NN)

1. We identify certain characteristics of LBSQs that enable the development of

Scope of the Project

The scope of the project is to reduce the latency considerably in answering

2.1 Wireless Data Broadcast

To facilitate information retrieval on wireless broadcast channels, the server

2.2 Spatial Queries

2.3 Cooperative Caching

Caching is a key technique to improve data retrieval performance in widely distributed

3.1 Existing System

• Existing techniques cannot be used effectively in a wireless broadcast

3.4 Proposed System

• PROCESSOR : PENTIUM IV 2.6 GHz

3.5 Software Description

FIGURE 2- WORKING OF JAVA

The Java Platform

What Can Java Technology Do?

FIGURE 4 – JAVA 2 SDK

The TCP/IP stack is shorter than the OSI one:

TCP is a connection-oriented protocol; UDP (User Datagram Protocol) is a

The IP layer provides a connectionless and unreliable delivery system. It

TCP supplies logic to give a reliable connection-oriented protocol above IP. It

Internally, the UNIX network is divided into sub networks. Building 11 is

A socket is a data structure maintained by the system to handle network

Mobile Host Centralized Server

Data Flow Diagram

5.1 Multiple peer simulation Module

5.2 Server Module

5.3 Sharing-based nearest neighbor query visualization Module

The sharing-based nearest neighbor query visualization Module provides a rendering of

5.4 In module given input and expected output

The purpose of testing is to discover errors. Testing is the process of trying to

Functional tests provide systematic demonstrations that functions tested are

Organization and preparation of functional tests is focused on requirements, key

White Box Testing

Black Box Testing

6.1 Unit Testing:

Test strategy and approach

6.2 Integration Testing

Software integration testing is the incremental integration testing of two or more

6.3 Acceptance Testing

Technique used or algorithm used

• Peer to Peer Communication technique

• Maintaining high scalability and accuracy.

Sample Source Code

public class CentralizedServer extends javax.swing.JFrame {

private void initComponents() {

jLabel1 = new javax.swing.JLabel();

jLabel1.setFont(new java.awt.Font("Microsoft Sans Serif", 3, 18)); // NOI18N

jButton2.setFont(new java.awt.Font("Microsoft Sans Serif", 2, 14)); // NOI18N

jButton3.setFont(new java.awt.Font("Microsoft Sans Serif", 2, 14)); // NOI18N

jButton4.setFont(new java.awt.Font("Microsoft Sans Serif", 2, 14)); // NOI18N

jLabel2.setFont(new java.awt.Font("Microsoft Sans Serif", 2, 14)); // NOI18N

jLabel3.setFont(new java.awt.Font("Microsoft Sans Serif", 2, 14)); // NOI18N

jButton6.setFont(new java.awt.Font("Microsoft Sans Serif", 2, 14)); // NOI18N

jButton7.setFont(new java.awt.Font("Microsoft Sans Serif", 2, 14)); // NOI18N

jButton8.setFont(new java.awt.Font("Microsoft Sans Serif", 2, 14)); // NOI18N

jLabel4.setFont(new java.awt.Font("Microsoft Sans Serif", 3, 18)); // NOI18N

jLabel5.setFont(new java.awt.Font("Microsoft Sans Serif", 2, 14)); // NOI18N

jLabel6.setFont(new java.awt.Font("Microsoft Sans Serif", 2, 14)); // NOI18N