jignasa: DART

DART

Dynamic Address Routing for Scalable

Ad Hoc and Mesh Networks

Scalability is a critical requirement in networking technologies to reach their full potential.

Ad hoc networking technology has advanced tremendously over the last ten years but it has yet to become a widely deployed technology.

The current routing protocols and architectures work well only up to a few hundred nodes.

Most current research in ad hoc networks focus more on performance and power-consumption related issues in relatively small networks, and less on scalability.

The main reason behind the lack of scalability is that these protocols rely on flat and static addressing.

With scalability as a partial goal, some efforts have been made in the direction of hierarchical routing and clustering.

These approaches do hold promise, but they do not seem to be actively pursued.

Dynamic addressing is a feasible way to achieve scalable ad hoc routing. “Scalable” means thousands up to millions of nodes in an ad hoc or mesh network.

It separates the routing address and the identity of a node.

The routing address of a node is dynamic and changes with node movement to reflect the node’s location in the network topology.

The identifier is a globally unique number that stays the same throughout the lifetime of the node.

TABLE OF CONTENTS

CHAPTER NO. TITLE PAGENO.

ABSTRACT iii

LIST OF TABLE xvi

LIST OF FIGURES xviii

LIST OF SYMBOLS xxvii

1. INTRODUCTION 1

1.1 OVERVIEW 1

1.2 OBJECTIVE 2

1.3 HARDWARE REQUIREMENTS 3

1.4 SOFTWARE REQUIREMENTS 4

2 AIM AND SCOPE OF THE PROJECT 4

2.1 AIM 4

2.2 SCOPE 4

2.2.1 Localization of overhead 4

2.2.2 Lightweight, decentralized protocols 4

2.2.3 Zero-conﬁguration 4

2.2.4 Our Work in Perspective 4

2.2.5 Minimal restrictions on hardware 4

2.3 OVERVIEW AND DEFINITIONS 5

2.3.1 The Address Tree

2.3.2 The Network Topology

2.4 EXISTING SYSTEM

2.5 PROPOSED SYSTEM

3 MODULES 9

3.1 Routing State of Node with Loop Avoidance

3.2 Node Lookup

3.3 Dynamic Address Allocation

3.3.1 ADDRESS SELECTION WITH BEST

NEIGHBOR

3.3.2 ADDRESS VALIDATION

3.4 Populating and Maintaining the Routing Table

3.4.1 REFRESH AND ROUTING UPDATE

STRUCTURE

4 MODULE EXPLANATION 11

4.1 LOOP AVOIDANCE

4.1.1 DFD DIAGRAM

4.1.1.1 MODULE1 DIAGRAM

4.2 NODE LOOKUP

4.2.1 MODULE 2 DIAGRAM

4.3 DYNAMIC ADDRESS ALOCATION

4.3.1 ADDRESS SELECTION WITH BEST

NEIGHBOR

4.3.2 ADDRESS VALIDATION

4.3.3 MODULE3 DIAGRAM

4.4 Populating and Maintaining the Routing Table

4.4.1 REFRESH AND ROUTING UPDATE

STRUCTURE

4.4.2 MODULE 4 DIAGRAM

4.5 OVERALL DFD 18

5 LITREATURE SURVEY 19

5.1 HISTORY OF JAVA 19

5.2 INTRODUCTION TO SWING 20

5.3 BENEFITS OF SWING 21

6 SOFTWARE STUDY 22

6.1 JAVA FOUNDATION CLASSES 23

6.2 ABSTRACT WINDOWING TOOLKIT 23

6.3 ACCESIBILITY 24

6.4 JAVA 2D 24

6.5 DRAG AND DROP 25

6.6 SWING 25

7 APPENDICES 31

7.1 SAMPLE CODINGS 31

7.1.1 DART SERVER 31

7.1.1 DART NODE CLIENT 37

7.2 SNAPSHOTS 40

7.2.1 NODE 40

7.2.2 GENERATING DYNAMICADDRESS41

7.2.3 LOOKUP SERVER 41

7.2.4 LOOKUP SERVER WITH NODE

DETAILS 42

7.2.5 NODE REQUEST 43

7.2.6 DATA TRANSFER 45

7.2.7 NODES WITH ATTACHMENTS 46

7.2.8 DISCONNECTED NODES 47

7.2.9 LOOKUP SERVER WITH MISSING

NODES 48

7.3 LOOKUP TABLE 51

7.4 ROUTING TABLE 51

8 SUMMARY AND CONCLUSIONS 51

9 REFERENCES 52

LIST OF TABLES

S.N0 TITLE OF TABLE

1. ROUTING TABLE

2. LOOKUP TABLE

LIST OF FIGURES

4.5 DATA FLOW DIAGRAM

MODULE 1

MODULE 2

MODULE 3

OVERALL PROJECT

4.6 SCREEN SHOTS

NODE

GENERATING DYNAMIC ADDRESS

LOOKUP SERVER

LOOKUP SERVER WITH NODE DETAILS

NODES REQUEST

ADDRESS ALLOCATION

DATA TRANSFER

NODES WITH ATTATCHMENTS

DISCONNECTED NODE

MISSING NODES IN LOOKUP SERVER

4.7 TABLES

LOOKUP TABLE

ROUTING TABLE

LIST OF ABBREVIATIONS

AODV - ADHOC ON DEMAND DISTANCE VECTOR ROUTING

DART - DYNAMIC ADDRESS PROTOCOL

ZRP -ZONE ROUTING PROTOCOL

FSR - FISHEYE STATE ROUTING

HSR -HIERARCHIAL STATE ROUTING

IP -INTERNET PROTOCOL

DSDV -DESTINATION SEQUENCE DISTANCE VECTOR

DSR -DYNAMIC SOURCE ROUTING

TTL -TIME TO LIVE

TCP -TRANSMISSION CONTROL PROTOCOL

UDP -USER DATAGRAM PROTOCOL

FTP -FILE TTRANSFER PROTOCOL

INTRODUCTION

An Ad-hoc network is a set of wireless mobile nodes that form a dynamic autonomous network without the intervention of centralized access points or base stations. Unlike traditional wireless networks, Ad-hoc networks require no fixed network infrastructure and can be deployed as multi-hop packet networks rapidly and with relatively low expense. Examples of applications include battlefields, emergency services, conference rooms, and home and office. Mobile nodes in an Ad-hoc network have limited radio transmission range. Nodes that are unable to communicate directly with each other require that intermediate nodes forward packets for them. Each node acts both as a router and as a host. The function of a routing protocol in Ad-hoc network is to establish routes between different nodes. Vulnerabilities, and can be attacked. The special characteristics of Ad-hoc networks put forward challenges not present in traditional wired networks. In the traditional Internet, routers within the central parts of the network are owned by a few well-known operators and are therefore assumed to be trust worthier. This assumption no longer holds in an Ad-hoc network since neither centrally administrated secure routers nor a strict security policy exists in an Ad-hoc network, and all nodes entering the network are expected to take part in routing. Also, because the links are usually wireless and any security that was gained because of the difficulty of tapping into a network is lost. Furthermore, because the topology in such a network can be highly dynamic, traditional routing protocols can no longer be used. Thus an Ad-hoc network has much higher security requirements than the traditional networks and the routing in Ad-hoc networks is hard to accomplish securely, robustly and efficiently. The general purpose of securing Ad-hoc routing protocols is to protect the routing messages, to prevent attackers from modifying these messages or even injecting harmful routing messages into the network. So integrity and authenticity of routing messages should be guaranteed. Confidentiality can be ensured easily, e.g., by encryption, but it will increase overhead.

In the next generation of wireless communication systems, there will be a need for the rapid deployment of independent mobile users. Significant examples include establishing survivable, efficient, dynamic communication for emergency/rescue operations, disaster relief efforts, and military networks. Such network scenarios cannot rely on centralized and organized connectivity, and can be conceived as applications of Mobile Ad Hoc Networks. A MANET is an autonomous collection of mobile users that communicate over relatively bandwidth constrained wireless links. Since the nodes are mobile, the network topology may change rapidly and unpredictably over time. The network is decentralized, where all network activity including discovering the topology and delivering messages must be executed by the nodes themselves, i.e., routing functionality will be incorporated into mobile nodes.

The set of applications for MANETs is diverse, ranging from small, static networks that are constrained by power sources, to large-scale, mobile, highly dynamic networks. The design of network protocols for these networks is a complex issue. Regardless of the application, MANETs need efficient distributed algorithms to determine network organization, link scheduling, and routing. However, determining viable routing paths and delivering messages in a decentralized environment where network topology fluctuates is not a well-defined problem. While the shortest path (based on a given cost function) from a source to a destination in a static network is usually the optimal route, this idea is not easily extended to MANETs. Factors such as variable wireless link quality, propagation path loss, fading, multi-user interference, power expended, and topological changes, become relevant issues. The network should be able to adaptively alter the routing paths to alleviate any of these effects. Moreover, in a military environment, preservation of security, latency, reliability, intentional jamming, and recovery from failure are significant concerns. Military networks are designed to maintain a low probability of intercept and/or a low probability of detection. Hence, nodes prefer to radiate as little power as necessary and transmit as infrequently as possible, thus decreasing the probability of detection or interception. A lapse in any of these requirements may degrade the performance and dependability of the network.

1.4 System Requirements:

1.4.1 Hardware Requirements:

Intel Pentium III Processor and above

128MB RAM and above

10GB Hard Disk

1.4.2 Software Requirements:

Windows XP, J2SDK 1.5

AIM AND SCOPE OF THE PROJECT:

Aim:

This paper proposes that the use of dynamic addressing can enable scalable routing in ad hoc networks. The main challenge is dynamic address allocation in the face of node mobility. It is well known that the current ad hoc protocol suites do not scale to work efficiently in networks of more than a few hundred nodes. Most current ad hoc routing architectures use flat static addressing and thus, need to keep track of each node individually, creating a massive overhead problem as the network grows.

SCOPE:

We identify a set of properties that a scalable and efficient solution must have.

• Localization of overhead: A local change should affect only the Immediate neighborhood, thus limiting the overall overhead incurred due to the change.

• Lightweight, decentralized protocols: We would like to avoid concentrating responsibility at any individual node, and we want to keep the necessary state to be maintained at each node as small as possible.

• Zero-conﬁguration: We want to completely remove the need for manual

conﬁguration beyond what can be done at the time of manufacture.

Our Work in Perspective:

• Minimal restrictions on hardware: Omni directional link-layers do not scale to large networks. Localization technologies, such as GPS, may limit protocol applicability.

We describe a new approach to routing in ad hoc networks, and compare it to the current routing architectures. However, the goal is to show the potential of this approach and not to provide optimized protocol. We believe that the address equals identity assumption used in current ad hoc routing protocols is most likely inherited from the wire line world, which is much more static and is explicitly managed by specialist system administrators. Although much work remains to be done, we believe that the dynamic addressing approach is a viable strategy for scalable routing in ad hoc networks

OVERVIEW AND DEFINITIONS:

The network architecture, which could utilize the new addressing scheme effectively. In fact, dynamic routing and addressing form the basis for a novel networking layer, which we describe in some detail in our earlier work

In our approach, we separate the routing address and the identity of a node. The routing address of a node is dynamic and changes with node movement to reﬂect the node’s location in the network topology. The identiﬁer is a globally unique number that stays the same throughout the lifetime of the node. For ease of presentation, we can assume for now that each node has a

single identiﬁer.

We distinguish three major functions. First, address allocation maintains one routing address per network interface, in such a way that the address indicates the node’s relative network location. Second, routing delivers packets from a node to a given routing address. Third, node lookup is a distributed lookup table mapping every node identiﬁer to its current net-

work address. We defer all details of the address allocation process to Section VI.

Let us ﬁrst describe how we want things to work from an operational point of view. When a node joins the network, it listens to the periodic routing updates of its neighboring nodes, and uses these to identify an unoccupied address. We will describe how this is done later. The joining node registers its unique identiﬁer and the newly obtained address in the distributed node lookup table. Due to mobility, the address may subsequently be changed

and then the lookup table needs to be updated. When a node wants to send packets to a node known only by its identiﬁer, it will use the lookup table to ﬁnd its current address. Once the destination address is known the routing function takes care of the communication. The routing function should make use of the topological meaning that our routing addresses possess.

We start by presenting two views of the network that we use to describe our approach: a) the address tree, and b) the network topology.

The Address Tree:

In this abstraction, we visualize the network from the address space point view. Addresses are bit binary numbers. The address space can be thought of as a binary levels. The leaves address tree of the address tree represent actual node addresses; each inner node represents an address sub tree: a range of addresses with a common preﬁx. For presentation purposes, nodes are sorted in increasing address order, from left to right. We stress that the links in the tree do not correspond to physical links in the network topology.

The Network Topology:

Note that the set of nodes from any sub tree induces a connected sub graph in the network topology .This is not a coincidence, but a crucial property of our dynamic addressing approach. Intuitively, nodes that are close to each other in the address space should be relatively close in the network topology. More formally, we can state the following constraint.1) Preﬁx Sub graph Constraint: The set of nodes that share a given address preﬁx form a connected sub graph in the network topology.

This constraint is fundamental to the scalability of our approach. Intuitively, this constraint helps us map the virtual hierarchy of the address space onto the network topology. The longer the shared address preﬁx between two nodes, the shorter the expected distance in the network topology.

Finally, let us deﬁne two new terms that will facilitate the discussion in the following sections.

A Level- sub tree of the address tree is deﬁned by an address preﬁx of bits, as shown in Fig. 1. For example, a Level-0 sub tree is a single address or one leaf node in the address tree. bit preﬁx and can contain up toA Level-1 sub tree has a two leaf nodes. In Fig. 1, [0xx] is a Level-2 sub tree containing

addresses [000] through [011]. Note that every Level- sub tree.

We deﬁne the term Level- sibling of a given address to be the sibling3 of the Level- sub tree to which a given address belongs. By drawing entire sibling sub trees as triangles, we can create abstracted views of the address tree.

Existing System:

Most current ad hoc routing architectures use flat static addressing.

It needs to keep track of each node individually and creating a massive overhead problem as the network grows.

Scalability is a critical requirement in networking technologies to reach their full potential.

The current routing protocols and architectures work well only up to a few hundred nodes.

The main reason behind the lack of scalability is that these protocols rely on flat and static addressing.

Proposed System:

Dynamic addressing is a feasible way to achieve scalable ad hoc routing. “Scalable” means thousands up to millions of nodes in an ad hoc or mesh network.

It separates node identity from node address, and uses the address to indicate the node’s current location in the network.

Address allocation scheme uses the address space efficiently on topologies of randomly and uniformly distributed nodes, empirically resulting in average routing.

In currently use IP address as identifier, which is a globally unique number that stays the same throughout the lifetime of the node. Thus, the transport and application layers do not need to change, and the routing address is only seen at the network layer.

It greedily minimizes the expected size of the resulting routing table at each node. However, it may want to reallocate addresses proactively to improve: 1) the balancing of the address tree, and 2) the length of the routed paths.

Modules:

Routing State of Node with Loop Avoidance

Node Lookup

Dynamic Address Allocation

Ø Address Selection with Best Neighbor

Ø Address Validation

Populating and Maintaining the Routing Table

Ø Refresh and Routing Update Structure

Routing State of Node with Loop Avoidance:

Each node keeps some routing state, as specified about a sibling node level which is stored at position. Intuitively, the routing state for a sibling contains the information necessary to maintain a route toward a node (any node) in that sub tree. DART makes use of the structured address space to create a new kind of loop avoidance scheme. In order to preserve scalability, this paper generalizes the loop freedom rule. For each sub tree, once a routing entry has left the sub tree, it is not allowed to re-enter. This effectively prevents loops, and can be implemented in a highly scalable manner.

Node Lookup:

Find the missing link of the current address of a node. This paper proposes to use a distributed node lookup table, which maps each identifier to an address. Node entries are defined in Anchor Node of the identifier. This paper opted for a method of periodic refresh, where every node periodically sends its information to anchor node. It sets all lookup table entries to expire automatically after a period twice as long as the periodic refresh interval.

Dynamic Address Allocation:

ADDRESS SELECTION WITH BEST NEIGHBOR:

When a node joins an existing network, it uses the periodic routing updates of its neighbors to identify and select an unoccupied and legitimate address. It starts out by selecting which neighbor to get an address from the neighbor with the highest-level insertion point is selected as the best neighbor. The insertion point is defined as the highest level for which no routing entry exists in a given neighbor’s routing table.

ADDRESS VALIDATION:

For each neighbor, find the highest order bit where the current node’s address differs from the neighbor’s address. If the addresses are identical, then the address is invalid if the neighbor has a lower identifier. Otherwise, check the neighbor’s announced routing table for the entry that should contain our sub tree. If an entry exists, but contains a different identifier, then we have detected an addressing conflict that needs to be resolved. The current address is invalid if the locally computed identifier is larger.

Populating and Maintaining the Routing Table:

DART nodes use periodic routing updates to notify their neighbors of the current state of their routing table. If, within a constant number of update periods, a node does not hear an update from a neighbor, it is removed from the list of neighbors, and its last update discarded.

REFRESH AND ROUTING UPDATE STRUCTURE:

Every period, each node executes Refresh. It checks the validity of its current address, populates a routing table using the information received from its neighbors, and broadcasts a routing update.

MODULE EXPLANATION:

LOOP AVOIDANCE:

DART uses a novel scheme for detecting and avoiding routing loops, which leverages the hierarchical nature of the address space to improve scalability.

First, let us review the general concept of loop avoidance,to lay the foundation for the discussion of our loop avoidance scheme. In an abstract sense, routing loop avoidance is about remembering what nodes a route update has traversed, and making sure that these nodes do not accept route updates that they have already seen. As long as this requirement is satisﬁed, routing loops cannot occur.

A simple way of implementing this is to concatenate a list of all visited nodes in the routing update, and to have nodes check this list before accepting an update. However, this approach has a scalability problem, in that routing updates will quickly grow to unwieldy sizes.

Instead, DART makes use of the structured address space to create a new kind of loop avoidance scheme. In order to preserve scalability, we generalize the loop freedom rule above. For each sub tree, once a routing entry has left the sub tree, it is not allowed to re-enter. This effectively prevents loops, and can be implemented in a highly scalable manner: A bit array of ADDR_SIZE bits is kept together with the routing update. Bit

of the route log indicates whether the current node via the level- sibling route update arrived at the current node via the level- sibling.

DFD DIAGRAM:

MODULE1:

NODE LOOKUP:

The missing link is: how do we ﬁnd the current address of a node, if we know its identiﬁer? We propose to use a distributed node lookup table, which maps each identiﬁer to an address, similar to what we proposed. Here, we assume that all nodes take part in the lookup table, each storing a few entries. However, this node lookup scheme is only one possibility among many, and more work is needed to determine the best lookup scheme to deploy. For our proposed distributed lookup table, the question now becomes: which node stores a given entry? Let us call this node the anchor node of the identiﬁer.The solution is simple yet elegant, and reminiscent of consistent hashing .

We use a globally, and a priori, known hash function that takes an identiﬁer as argument and returns an address where the entry can be found. If there exists a node that occupies this address, then that node is the anchor node. If there is no node with that address, then the node with the least edit distance between its own address and the destination address, is the anchor node.

The missing link of the nodes are found and included in the missing nodes table.

This table is used to figure out what are the node positions that are available.

This table contains only the nodes that are disconnected.

These disconnected nodes position can be obtained by another node.

“Missing nodes” table has the node name and its address field.

MODULE 2:

DYNAMIC ADDRESS ALOCATION:

To assess the feasibility of dynamic addressing, we develop a suite of protocols that implement such an approach. Our work effectively solves the main algorithmic problems, and forms a stable framework for further dynamic addressing research. Although the design has not yet been optimized for maximum throughput, its scalability properties and predictable performance show promise.

ADDRESS SELECTION WITH BEST NEIGHBOR:

To assess the feasibility of dynamic addressing, we develop a suite of protocols that implement such an approach. When a node joins an existing network, it uses the periodic routing updates of its neighbors to identify and select an unoccupied and legitimate address. It starts out by selecting which neighbor to get an address from the neighbor with the highest-level insertion point is selected as the best neighbor. The insertion point is defined as the highest level for which no routing entry exists in a given neighbor’s routing table.

ADDRESS VALIDATION:

The validity of an address is verified by checking it against the routing tables of all neighbors. For each neighbor, find the highest order bit where the current node’s address differs from the neighbor’s address. If the addresses are identical, then the address is invalid if the neighbor has a lower identifier. Otherwise, check the neighbor’s announced routing table for the entry that should contain our sub tree. If an entry exists, but contains a different identifier, then we have detected an addressing conflict that needs to be resolved. The current address is invalid if the locally computed identifier is larger.

MODULE 3:

ADDRESS

ALLOCATION

STORE IN ROUTING TABLE

VALDATION

SELECTS HIGHEST ORDER BIT

Populating and Maintaining the Routing Table:

This module discusses how the routing table is populated, and how routing loops are avoided. DART nodes use periodic routing updates to notify their neighbors of the current state of their routing table. If, within a constant number of update periods, a node does not hear an update from a neighbor, it is removed from the list of neighbors, and its last update discarded.

REFRESH AND ROUTING UPDATE STRUCTURE:

Every period, each node executes Refresh. It checks the validity of its current address, populates a routing table using the information received from its neighbors, and broadcasts a routing update.

MODULE 4:

ROUTE PACKETS

EXISTING NODE

VALID

REMOVE FROM TABLE

REFRESH PERIODICALLY

INVALID

OVERALL DFD:

1.2 LITERATURE SURVEY

1.2.1 HISTORY OF JAVA:

Java has been around since 1991, developed by a small team of Sun Microsystems developers in a project originally called the Green project. The intent of the project was to develop a platform-independent software technology that would be used in the consumer electronics industry. The language that the team created was originally called Oak.

The first implementation of Oak was in a PDA-type device called Star Seven (*7) that consisted of the Oak language, an operating system called GreenOS, a user interface, and hardware. The name *7 was derived from the telephone sequence that was used in the team's office and that was dialed in order to answer any ringing telephone from any other phone in the office.

Around the time the First Person project was floundering in consumer electronics, a new craze was gaining momentum in America; the craze was called "Web surfing." The World Wide Web, a name applied to the Internet's millions of linked HTML documents was suddenly becoming popular for use by the masses. The reason for this was the introduction of a graphical Web browser called Mosaic, developed by ncSA. The browser simplified Web browsing by combining text and graphics into a single interface to eliminate the need for users to learn many confusing UNIX and DOS commands. Navigating around the Web was much easier using Mosaic.

It has only been since 1994 that Oak technology has been applied to the Web. In 1994, two Sun developers created the first version of Hot Java, and then called Web Runner, which is a graphical browser for the Web that exists today. The

browser was coded entirely in the Oak language, by this time called Java. Soon after, the Java compiler was rewritten in the Java language from its original C code, thus proving that Java could be used effectively as an application language. Sun introduced Java in May 1995 at the Sun World 95 convention.

Web surfing has become an enormously popular practice among millions of computer users. Until Java, however, the content of information on the Internet has been a bland series of HTML documents. Web users are hungry for applications that are interactive, that users can execute no matter what hardware or software platform they are using, and that travel across heterogeneous networks and do not spread viruses to their computers. Java can create such applications.

1.3 INTRODUCTION TO SWING:

Swing contains all the components. It’s a big library, but it’s designed to have appropriate complexity for the task at hand – if something is simple, you don’t have to write much code but as you try to do more your code becomes increasingly complex. This means an easy entry point, but you’ve got the power if you need it.

Swing has great depth. This section does not attempt to be comprehensive, but instead introduces the power and simplicity of Swing to get you started using the library. Please be aware that what you see here is intended to be simple. If you need to do more, then Swing can probably give you what you want if you’re willing to do the research by hunting through the online documentation from Sun.

1.3.1 BENEFITS OF SWING:

Swing components are Beans, so they can be used in any development environment that supports Beans. Swing provides a full set of UI components. For speed, all the components are lightweight and Swing is written entirely in Java for portability.

Swing could be called “orthogonally of use;” that is, once you pick up the general ideas about the library you can apply them everywhere. Primarily because of the Beans naming conventions.

Keyboard navigation is automatic – you can use a Swing application without the mouse, but you don’t have to do any extra programming. Scrolling support is effortless – you simply wrap your component in a JScrollPane as you add it to your form. Other features such as tool tips typically require a single line of code to implement.

Swing also supports something called “pluggable look and feel,” which means that the appearance of the UI can be dynamically changed to suit the expectations of users working under different platforms and operating systems. It’s even possible to invent your own look and feel.

3.6 SOFTWARE STUDY:

Java was developed at Sun Microsystems. Work on Java originally began with the goal of creating a platform-independent language and operating system for consumer electronics. The original intent was to use C++, but as work progressed in this direction, the Java developers realized that they would be better served by creating their own language rather than extending C++. The effort toward consumer electronics led the Java team, then known as First Person, Inc., toward developing hardware and software for the delivery of video-on-demand with Time-Warner.

Features of the Java Language:

v Simple

v Object-Oriented

v Distributed

Java facilitates the building of distributed applications by a collection of classes for use in networked applications. By using Java's URL (Uniform Resource Locator) class, an application can easily access a remote server. Classes also are provided for establishing socket-level connections.

v Interpreted

v Robust

v Secure

v Architecture-Neutral

3.6.1 JAVA FOUNDATION CLASSES:

Probably the single most important new feature added to JDK 1.2 is version 1.1 of the Java Foundations Classes (JFC). JFC is a set of APIs for building the GUI-related components of Java applets and applications. JFC 1.1 was released separately from the JDK in February of 1998 so that they could be used with the then-current JDK 1.1. JDK 1.2 integrates JFC 1.1 as a Core API and adds the Java 2D and Drag and Drop APIs. The APIs included with JFC include the following:

v The Abstract Windowing Toolkit

v Swing

v Java 2D

v Drag and Drop

v Accessibility

These five APIs are introduced in the following subsections.

3.6.2ABSTRACT WINDOWING TOOLKIT (AWT):

If you've programmed in Java before, you know about the AWT. It provides the capability to create platform-independent, GUI-based programs and is a very important contributor to Java's popularity. Any programmer who has written programs using the arcane APIs of Microsoft Windows immediately appreciates the clarity, simplicity, and power of the AWT. Not only is the AWT a better API for developing Windows applications, it is a better API for programming window-based applications on platforms ranging from Motif to OS/2.The AWT of JDK 1.2 has been augmented with many new classes and interfaces that add drawing, Printing, and image-processing capabilities, and support the Accessibility, Drag and Drop, and Java 2D APIs.

3.6.3 ACCESIBILITY:

The Accessibility API is a JFC API that has been added to JDK 1.2. It provides support for the use of assistive technologies with other JFC components. Assistive technologies, such as screen magnifiers and speech recognition systems, are intended for use by disabled users, but are also valuable tools for the average non-disabled user. These technologies provide non-standard ways of interacting with software applications.

The Accessibility API of JDK 1.2 allows software developers to comply with the Federal Rehabilitation Act and Americans with Disabilities Act.The Accessibility API consists of classes and interfaces for incorporating accessibility features into applets and applications. These classes and interfaces are provided in the java.awt.accessibility package.

3.6.4 JAVA 2D:

If you develop any kind of graphics-related software, you'll appreciate the new Java 2D API. This API provides comprehensive support for two-dimensional drawing, image processing, graphics rendering, color management, and printing. It consists of an imaging model that supports line art, text, images, spatial and color transformations, and image compositing. The model is device-independent; allowing displayed and printed graphics to be rendered in a consistent manner. The Java 2D API is incorporated into the java.awt and java.awt.image packages.

3.6.5 DRAG AND DROP:

One of the nicer features of most windowing environments that has been conspicuously missing from Java is support for drag and drop. Drag and drop is typically used to organize desktops, manage files, open documents, and execute applications. The Drag and Drop API allows the JDK 1.2 to provide platform-independent support of drag and drop. It supports drag and drop within Java applications, between Java applications, and between Java and native platform applications.

The Drag and Drop API is implemented in the java.awt.dnd package and is supported by classes and interfaces in other JFC packages. Chapter 16, "Working with Drag and Drop," shows how to use the Drag and Drop API.

It provides more packages to develop all kind of applications and applets. Some of them are listed below.

v java.lang -handles all basic operations and contains the data types.

v java.io -handles all kinds of input and output operations.

v java.util -contains collection based classes and interfaces.

v java.awt -contains user interface components.

v java.awt.event-contains user interface component event listeners.

v java.awt.image-contains image handling classes and interfaces.

v javax.swing -contains enhanced user interface components.

v javax.swing.event -contains event listeners of enhanced user interface components.

3.6.6 SWING:

Of all the new capabilities provided by the JFC 1.1, one API, referred to as Swing, has far-reaching consequences for Java programmers. Swing is the code word used by the Java Soft programming team for the next generation of the AWT. Swing extends AWT by supplying many more types of GUI components, providing 100% pure Java implementations of these components, and allowing the appearance and behavior of these components to be easily tailored

The new components that are included with Swing include everything from tabbed panes and fancy borders to sliders and spinners. These new components, in and of themselves, make Swing an outstanding addition to the Java API. The Swing Component Gallery, located at http://java.sun.com/products/jfc/swingdoc-current/comp_gal.html, exhibits some of these new components. Swing also comes with a great demo program named SwingSet.

The Swing components are 100% pure Java. This means that they don't depend on the native windows implementation to support them. It also means that Swing components are available and consistent across all platforms. Although Swing components are implemented in terms of the underlying AWT, these components do not use AWT components. In fact, many of the traditional AWT components, such as buttons, lists, and dialog boxes, have been reimplementation as Swing components. Because of this, the AWT components behave more consistently across different platforms and are capable of providing additional features not supported by their native windowing platforms. The most talked about feature of Swing is its support for pluggable look and feel (PL&F). If you like to customize your desktop, dabble in new color schemes, and do what it takes to make your windows fit your tastes and needs, PL&F is for you. The Swing PL&F architecture makes it easy to customize both the appearance and the behavior of any particular Swing control or any group of those controls. Swing also comes with several predefined L&Fs, including the default Metal L&F, the Motif L&F, and the Windows L&F. L&Fs for Macintosh and other platforms are also being developed.

Swing is the code word used by the Java Soft programming team for the next generation of the AWT. Swing extends AWT by supplying many more types of GUI components.

Swing is a set of classes that provides more powerful and flexible components that are possible with the AWT. It provides many standard GUI components such as buttons, lists, menus and text areas, which is combined to create a program’s GUI. It also includes containers such as Windows and Toolbars.

Swing offers many features, many which rely on support provided by the JComponent class. Unlike AWT components, Swing components are written entirely in Java and are platform-independent.

Swing components provide a pluggable look and feel, which is easy to substitute another appearance and behavior for an element. The Swing related classes are contained in javax.swing and its sub packages, such as javax.swing.tree.

Features of Swing components:

v Swing buttons and labels can display images instead of, or in addition to text.

v User can easily add or change the borders drawn around most swing components.

v Users can easily change the behavior or appearance of a swing component by either invoking methods on it or creating a subclass of it.

v Swing components don’t have to be rectangular, buttons, for e.g., can be round.

v Assistive technologies such as screen renders can get information from swing components.

v Swing let’s to specify which look and feel a program’s GUI uses.

v Swing components are implemented with no native code and aren’t restricted to the least common denominator.

The Swing API is flexible, powerful and immense. It is available in two forms:

v As a core part of the Java2 platform

v JFC1.1

JFrame:

The JFrame class is slightly incompatible with Frame. Like all other JFC/Swing top-level containers, a JFrame contains a JRootPane as its only child. The content pane provided by the root pane should, as a rule, contain all the non-menu components displayed by the JFrame. This is different from the AWT Frame case.

JPanel:

JPanel is an extension of Jcomponent used for grouping together other components. It gets most of its implementations from its super classes.

JButton:

JButton is a push button that is a replacement for java.awt.Button. Like AWT buttons, Swing button fire action events when they activated. An action Listener can register with a button, and the listener’s action performed method will be invoked whenever the button is activated.

JTextField:

JTextField allow the user to enter a single line of text, scrolling the text if its size exceeds the physical size of the field. Horizontal alignment either LEFT, RIGHT or CENTER can be specified for a text field’s text.

JTextArea:

JTextArea class displays multiple times of text in a single font and style. Its default behavior is not to wrap lines of text, but line wrapping can be enabled on word (or) character boundaries.

JScrollPane:

The JScrollPane class is actually just a panel with a hard-working layout manager and some convenient access methods for the manager.

v Row header

v Column header

v View port

v Horizontal Scrollbar

v Vertical Scrollbar

v Four corners (Upper left, Upper right, Lower left, Lower right)

JTabbedPane:

The JTabbedPane is used for creating your own tabbed pane with tab activation components, very quickly.

JFileChooser:

JFileChooser class bundles a directory pane into a handy interface.

Null Layout:

A null layout arranges components in a user-defined position.

APPENDICES:

SAMPLE CODINGS:

DART SERVER

package com.gts.DartProcess;

import java.net.*;

import java.util.Properties;

import java.util.Vector;

import java.io.*;

import javax.swing.table.DefaultTableModel;

import com.gts.DartProcess.sendingValues;

import com.gts.DartProcess.Operations;

import DartDesign.DartDesign;

public class DartServer extends Thread{

Socket s;

ServerSocket ss;

String str,str1;

String getRow;

String as,ia;

Vector v;

ObjectInputStream ois;

ObjectOutputStream oos;

int localPort;

int serverPort;

int nodePort;

int lookupValue=1;

InetAddress nodeinet;

static int nodeCount=0;

Operations op;

sendingValues sv;

static Properties p1,prDtl;

public static String Server;

FileInputStream fisDtl;

public DartServer()

{

p1 = new Properties();

op=new Operations();

try

{

DartDesign.setDefaultLookAndFeelDecorated(true);

new DartDesign();

start();

v=new Vector();

System.out.println("Run method ll be Called");

ia=InetAddress.getLocalHost().getHostName();

s=new Socket(ia,1000);

}catch(Exception e){}

}

public void run()

{

System.out.println("Checking...");

Reciving();

}

public void Reciving()

{

try

{

ss=new ServerSocket(999);

while(true)

{

s=ss.accept();

nodeCount++;

localPort=ss.getLocalPort();

nodeinet=s.getInetAddress();

System.out.println("Node Inet:"+nodeinet);

ois=new ObjectInputStream(s.getInputStream());

str=(String)ois.readObject();

sv=(sendingValues)ois.readObject();

String getting=checkStatus(str,sv);

System.out.println(getting);

}

catch(Exception e)

{

System.out.println(e);

System.out.println("Error 2");

}

public String checkStatus(String get,sendingValues s1)

{

try

{

System.out.println("Got get:"+get);

System.out.println("Got S1:"+s1);

LoadClass obj=new LoadClass();

Approve app=null;

app=(Approve)obj.doe();

String ss=app.getSysName();

//String ss=InetAddress.getLocalHost().getHostName();

if(DartDesign.dftblunoccu.getRowCount()!=0)

{

if(get.equals(ss))

{

System.out.println("!!!!!!!!!!!!!!!!!!!!!!!");

System.out.println("Request from local System");

}

else if(get.equals("Request"))

{

getRow="";

if(DartDesign.dftblmiss.getRowCount()==0)

{

getRow=(String)DartDesign.dftblunoccu.getValueAt(0,0);

DartDesign.dftblunoccu.removeRow(0);

assignAddr(s1);

}

else

{

getRow=(String)DartDesign.dftblmiss.getValueAt(0,1);

DartDesign.dftblmiss.removeRow(0);

assignAddr(s1);

}

else if(get.equals("Disconnect"))

{

Operations.calDisconn(s1);

System.out.println(s1+"is disconnected");

}

else if(get.equals("Data"))

{

checkAndForward(s1);

}

else if(get.equals("Forward"))

{

System.out.println("-----------Got farwarded-------");

checkAndForward(s1);

}

else if(get.equals("ChangeServer"))

{

System.out.println("-----------Got farwarded-------");

changeServer(s1);

}

else

{

DartDesign.numAddr+=1;

DartDesign.derived(DartDesign.numAddr);

checkStatus(get,s1);

}

}catch(Exception e){

System.out.println(e);

}

return get;

}

public void checkAndForward(sendingValues s1)

{

int rowCount=DartDesign.table1.getRowCount();

String rowString="";

int chk=0;

System.out.println("rowCount:"+rowCount);

for(int i=0;i<rowCount;i++ )

{

rowString=(String)DartDesign.table1.getValueAt(i,0);

System.out.println("--------rowString:"+rowString);

System.out.println("--------s1.Destination:"+s1.Destination);

if((s1.Destination).equals(rowString))

{

System.out.println("--------Inside If-----");

displayText(s1);

chk++;

break;

}

if(chk==0)

{

forward(s1);

}

public void displayText(sendingValues s1)

{

try

{

prDtl=new Properties();

System.out.println("--------Inside displayText-----");

fisDtl=new FileInputStream("Ports.properties");

prDtl.load(fisDtl);

int socPort=Integer.parseInt(prDtl.getProperty(s1.Destination));

System.out.println("-------------Soket ppppppppp:"+socPort);

System.out.println("--------------s1.Destination:"+s1.Destination);

s=new Socket(ia,socPort);

oos=new ObjectOutputStream(s.getOutputStream());

oos.writeObject(s1.myData);

}catch(Exception e){System.out.println(e);}

}

public void forward(sendingValues s1)

{

try

{

FileInputStream fis = new FileInputStream("Details.properties");

p1 .load(fis);

Server=p1.getProperty("lookupserver2");

System.out.println("SSSSSSSSSSServer::::::::"+Server);

s=new Socket(Server,999);

System.out.println("SSSSSSSSSSServer::::::::"+s);

oos=new ObjectOutputStream(s.getOutputStream());

oos.writeObject("Forward");

oos.writeObject(s1);

System.out.println("-----------Obj ll be sent...-------");

fis.close();

}

catch(Exception e){}

}

public void changeServer(sendingValues s1)

{

try

{

DefaultTableModel dtm=new DefaultTableModel();

dtm=DartDesign.table1;

s1.frdTable=DartDesign.display;

FileInputStream fis = new FileInputStream("Details.properties");

p1 .load(fis);

Server=p1.getProperty("lookupserver2");

s=new Socket(Server,999);

oos=new ObjectOutputStream(s.getOutputStream());

oos.writeObject("ChangeServer");

oos.writeObject(DartDesign.display);

System.out.println("-----------Obj ll be sent...-------");

fis.close();

}catch(Exception cs)

{

System.out.println(cs);

}

public void assignAddr(sendingValues s1)

{

try

{

v.add(s1.myName);

v.add(s1.myIp);

v.add(getRow);

v.add(s1.Distance);

int i=DartDesign.table1.getRowCount();

System.out.println("RowCount:"+i);

DartDesign.table1.insertRow(i,v);

v=new Vector();

oos=new ObjectOutputStream(s.getOutputStream());

oos.writeObject("Address");

oos.writeObject(getRow);

}catch(Exception e){}

}

DART NODE

package com.gts.DartProcess;

import java.net.*;

import java.util.Properties;

import java.io.*;

import com.gts.DartProcess.sendingValues;

import DartDesign.Node1;

public class NodeClient

{

Socket s;

ServerSocket ss;

String st,ia,ServerAddr;

ObjectInputStream ois;

ObjectOutputStream oos;

sendingValues get;

Operations op;

static Properties port;

static Properties p1;

FileOutputStream fos;

FileInputStream fis;

RandamIp ri;

public NodeClient(sendingValues sv,String req)

{

try

{

ri=new RandamIp();

p1=new Properties();

op =new Operations();

get=new sendingValues();

get=sv;

send(get,req);

portInitialize();

}catch(Exception e){}

}

public void portInitialize()

{

try

{

port =new Properties();

String portName=Node1.sourceName.getText();

String myPort=ri.randomPort();

port.setProperty(portName,myPort);

fos = new FileOutputStream("Ports.properties",true);

port.store(fos,portName);

fos.close();

new receiveLocal(myPort);

}catch(Exception e)

{

System.out.println(e);

}

public void send(sendingValues get,String req)throws Exception

{

if(req.equals("Request"))

{

if((Integer.parseInt(get.Distance))>=90)

{

fis = new FileInputStream("Details.properties");

p1 .load(fis);

for(int i=1;i<=2;i++)

{

get.Distance=get.Distance+" "+"Intermediate";

ServerAddr=p1.getProperty("lookupserver"+i);

s=new Socket(ServerAddr,999);

sending(get,req);

recSer();

}

else

{

s=new Socket(Node1.Server,999);

sending(get,req);

recSer();

}

else

{

try

{

s=new Socket(Node1.Server,999);

sending(get,req);

}catch(Exception e){}

}

public void sending(sendingValues get,String req)

{

try

{

oos=new ObjectOutputStream(s.getOutputStream());

oos.writeObject(req);

oos.writeObject(get);

}catch(Exception e){

System.out.println(e);

}

public void recSer()

{

try

{

ois=new ObjectInputStream(s.getInputStream());

String sign=(String)ois.readObject();

String re=(String)ois.readObject();

if(sign.equals("Address"))

{

Node1.lblMyAddr.setText(re);

}

}catch(Exception e){}

}

APPENDICE 2:

NODE

GENERATING DYNAMIC ADDRESS

LOOKUP SERVER

LOOKUP SERVER WITH NODE DETAILS

NODE REQUEST

DATA TRANSFER

NODES WITH ATTACHMENTS:

DISCONNECTED NODES

LOOKUP SERVER WITH MISSING NODES

LOOKUP TABLE

TABLE:

SUMMARY AND CONCLUSIONS:

Thus the project explains how the nodes can be effectively used in an ad hoc network eliminating a massive overhead problem. Therefore dynamic addressing eliminated the flat and static addressing making it a feasible method to execute in large networks.

Dynamic Addressing represents a novel and promising approach to scalable ad hoc routing.

DART is on its way to become a scalable alternative to current ad hoc routing protocol.

REFERENCES:

• J. Eriksson, M. Faloutsos, and S. Krishnamurthy, "Scalable ad hoc routing: The case for dynamic addressing," in Proc. INFOCOM, 2004, pp. 1108-1119.

• N. Negroponte, “Being Wireless,” 2002 [Online]. Available:www.wired.com/wired/archive/10.10/wireless.html

• “Consume.net Project: Trip the Loop, Make Your Switch, Consume the Net!” [Online]. Available: www.consume.net

• “Wireless Anarchy,” [Online]. Available: www.wirelessanarchy.com

• "Consume.net Project: Trip the Loop, Make Your Switch, Consume the Net!" [Online]. Available: www.consume.net

• Personal Telco Project. [Online]. Available: www.personaltelco.com

• J. Eriksson, M. Faloutsos, and S. Krishnamurthy, "PeerNet: Pushing Peer-to-Peer down the stack," in Proc. 2nd Int. Workshop on Peer-to-Peer Systems (IPTPS'03), Feb. 2003, pp. 268-277

• D. B. Johnson and D. A. Maltz, "Dynamic source routing in ad hoc wireless networks," in Mobile Computing. Boston, MA: Kluwer Academic, 1996, vol. 353

• X. Hong, K. Xu, and M. Gerla, "Scalable routing protocols for mobile ad hoc networks," IEEE Network, vol. 16, no. 4, pp. 11-21, Jul.-Aug. 2002.

• Z. Haas, "A new routing protocol for the reconfigurable wireless networks," in IEEE Int. Conf. Universal Personal Communications Rec., Oct. 1997, pp. 562-566.

• B. Chen and R. Morris, "L+: Scalable landmark routing and address lookup for multi-hop wireless networks," Massachusetts Inst. Technol. (MIT), Cambridge, MA, Tech. Rep., 2002.

jignasa

Wednesday, 14 November 2012

DART

No comments:

Post a Comment

647. PRESENTATION SKILLS MBA I - II

Followers

Important web sites