ABSTRACT

Virtual Router creates a virtual topology consisting of virtual networks connected by routers. The program runs in a distributed manner creating multipoint and point to point links among machines on which it is running. The routers exchange routing information among themselves. Java Virtual Routers communicate with unicast and multicast UDP (User Datagram Protocol) packets. Our routing protocol implements a simplified Routing Information Protocol. The virtual router project is an effort to develop a platform to facilitate research and teaching of network routing. The fundamental objective is to make link layer traffic easily accessible to developers so that they may perform routing operations within user space. In virtually all modern operating systems, routing is implemented within kernel space. Providing a good kernel debugging environment and assuming a basic knowledge of kernel level development may be restrictive requirements for a project focused on routing.

ROLE AND RESPONSIBILITES

Project Title Virtual Router Group Size 3 Team Leader Juli Kumari Responsibility Coder and Designer Designer and Analyzer Tester and Documenter

Member Name 1. Juli Kumari 2. Mukesh Kumar 3. Jitendra Kumar Karwa

There are different roles and responsibilities which are divided among the team members. We have tried our best to do justice to the roles and responsibilities given to us. The various roles and responsibilities are the following: MUKESH KUMAR DESIGN and INFORMATION COLLECTION I have collected all the information from different books like Software Engineering, Tata McGraw-Hill, By Richard Deal. I have various web sides for collecting information about the design module of the project. The preferred web sides are 1.www.roseindia.net 2.www.boson.com JULI KUMARI DESGINER and CODING I have done the coding part of the project. I had taken the help of many books to understand the concept of network coding and socket programming. Some of the books are Java,The COMPLETE REFERENCE BY HERBERT SCHILDT.In coding the java concepts of socket programming have been used which generally made two sockets-one between the client and proxy. Another between the proxy and server. JITENDRA KUMAR KARWA DOCUMENTATION and TESTING

I have used the format of the report to frame the layout of the report. This report fulfills all he parameters of the format given to us. I have done all the documenting in Ms Word.

Chapter-1

SOFTWARE REQUIREMENT SPECIFICATION

1.1 Introduction The purpose of this section is to provide a general, background Information about the software Virtual Router. 1.1.1 Purpose This document is the software Requirements Specifications for Virtual Router. This describes the functions and performance requirements of the software. The virtual router project is an effort to develop a platform to facilitate research and teaching of network routing. It allows to set up a virtual topology of routers and network links and to run user-space programs on the simulated hardware. 1.1.2 Document Conventions and Terminology Throughout this document, the following conventions have been used: The Virtual Router system can be broken down into two components: Virtual router server Virtual router client. TCP socket, Protocols in used: FTP protocol, ARP protocol 1.1.3 Scope of the Project

The virtual router has successfully been used to teach students basic functionality of routers. Students had to implement virtual router clients that make routing decisions, use the ARP protocol to communicate with other routers and route actual web traffic from their desktop computers. Using Virtual Router, users can wirelessly share any internet connection (Wi-Fi, LAN, Cable Modem, Dial-up, Cellular, etc.) with any Wi-Fi device (Laptop, Smart Phone, iPod Touch, phone, Net book, wireless printer, etc.)

 These devices connect to Virtual Router just like any other access point, and the connection is completely secured using WPA2.

1.1.4 References This virtual router application has been prepared on the basis of discussion with Team members, faculty members and also taken information from following books & website:

COMPLETE REFERENCE : JAVA JAVA : Dietel and Dietel CORE JAVA2 Volume 1 and 2 : Sun Microsystems Press Fundamental of Software Engineering By Rajiv Mall Software Engineering: A practitioners approach Ed. By Pressman, Roger

www.google.com www.sourceforge.net www.in.redhat.com www.wikipedia.com

1.2 Overall Descriptions 1.2.1 Product Perspective A virtual router is a logical router that is associated with a particular geographic area. Virtual Router is a free, open source software based router for PCs running Windows.

Using Virtual Router, users can wirelessly share any internet connection such as Wi-Fi, LAN, Cable Modem, Dial-up, Cellular, etc.

1.2.2 Product Functions The Virtual Router system can be broken down into two components: Virtual router server: The virtual router server is an application or set of application running on a physical server that have access to link layer traffic. Virtual router client: The virtual router client is a program created by users of a VR system.

A user will use a VR client to connect to the server via a TCP socket, and a decision is made about what packets the server will send to the client. The user may then run a network application, such as FTP, whose traffic can be seen by the server. The virtual router project provides full access to actual network traffic. 1.2.3 User Classes and Characteristics The major user classes that are expected to use this product are as follows: Large Organizations: Once completely developed the Virtual Router, users can wirelessly share any internet connection with any Wi-Fi device in anywhere of the world such as LAN area, company, and in any types of the large organization. Academic Organizations: University and Students are expected to contribute to a large class of users of this system to get the understanding of basic functionality of the virtual router

1.2.4 Operating Environment created The virtual router is developed in Java and client- server side programming is also on java. Connections are established through networking using TCP/IP socket and FTP

protocol, ARP protocol.

1. 2.5 Design and Implementation Constraints Virtual Router is made of three layers: Physical layer Network Interface Routing

The Physical layer brings up the machines on a real network and passes packets to the Network Interface layer. The Network Interface layer maintains various virtual interfaces in the JVR. It passes the packets between the Physical layer and the Routing layer. The Routing layer reads in the packets from its input queue and extracts routing information embedded in the packet. It updates its own routing table using that information. The Routing layer periodically sends update packets over all the virtual network interfaces.

1.2.6 User Documentation To assist the user in using program a lot of instructions have been given for each menu, which would be sufficient for general use. There is an attached report for knowing various methods and algorithms used in program.

1.2.7 Assumptions and Dependencies Full working of VR is dependent on the availability of full access to actual network traffic.

Assumptions In client side, it has been assumed that the user has complete knowledge of the system that means user is not a nave user. Any data entered by him/her will be valid. To make the software as user friendly as possible but at the same time keeping in minds user requirements. OS should be Windows NT/2000/XP/7. PC should be connect with any internet connection such as Wi-Fi, LAN, Cable Modem, Dial-up, Cellular, etc

Dependencies It depends that Client should be connect with server with internet connection in proper way.

1.3 System Features

1.3.1 There are two sub modules in this phase: Client side Server side

The functionality of each module is as follows: Server side: The virtual router server is an application or set of applications running on a physical server that have access to link layer traffic. Client side: The virtual router client is a program created by users of a virtual router system. 1.3.2 Server and client features Logging

The server has extensive logging features. The basic function of the server is to log its activity in a file which can be specified by the user [by default its/var/log/vrserver].The log can also be accessed from a remote client using a browser.The log starts out by listening on the default web server port [port80]. The user can specify a port to listen on also. Searching The user /client will be able to find the network connection through VR. Server provided various connection made available to the network for users or client. Connection:

The system will show all the results available after search operation in a tabular form on client side. After this Client connect with a particular network or internet through VR.

Chapter-2

DESIGN
2.1 E-R Diagram The server components have been described above in some detail. All of the components come together to give a single cohesive path for data flow in the server. To illustrate this better, the overall server view is depicted in the following diagram. The box labelled Server represents the higher level server component which includes the select loop for servicing clients. The lower layer consists of the subsystem which interact with libnet and libcap and also use the client filters to send packets back to the client directly. The data flow is that the client connects to the server via a TCP/IP socket. The client registers to serve a particular virtual host in a specific topology. All relevant packets from an end-user to an application server and vice versa are intercepted by the lower level subsystem and sent to the client directly, the client processes and sends them back to the server via the higher level select loop which hands over the client packets to the lower layers to be injected onto the wire.

Figure 2.1- DFD of Virtual Router

Client Application

Outbound message

Inbound message

Log into Network

Outbound message
Relay message using proxy

Inbound message

Outbound message
Route Message

Inbound message and authentication data

Outbound message

HTTP Adapter send

Inbound message
HTTP Adapter receive

Processing Processing Message

Decrypted Host and validated Message

Figure 2.2- DFD of VR

10

2.2 Unified Modelling Language Diagram A use case diagram in the Unified Modelling Language (UML) is a type of behavioral diagram defined by and created from a Use-case analysis. Its purpose is to present a graphical overview of the functionality provided by a system in terms of actors, their goals (represented as use cases), and any dependencies between those use cases. The main purpose of a use case diagram is to show what system functions are performed for which actor. Roles of the actors in the system can be depicted. Use case diagrams are formally included in two modeling languages defined by the OMG: the Unified Modeling Language (UML) and the Systems Modeling Language (SysML).

Figure 2.2.1- UML Diagram of Virtual Router

2.2.1 Use Case Diagram

11

A use case is a methodology used in system analysis to identify, clarify, and organize system requirements. The use case is made up of a set of possible sequences of interactions between systems and users in a particular environment and related to a particular goal. It consists of a group of elements (for example, classes and interfaces) that can be used together in a way that will have an effect larger than the sum of the separate elements combined. The use case should contain all system activities that have significance to the users. A use case can be thought of as a collection of possible scenarios related to a particular goal, indeed, the use case and goal are sometimes considered to be synonymous. A use case (or set of use cases) has these characteristics Organizes functional requirements. Models the goals of system/actor (user) interactions. Describes one main flow of events (also called a basic course of action), and possibly

other ones, called exceptional flows of events (also called alternate courses of action). Is multi-level, so that one use case can use the functionality of another one. Use cases can be employed during several stages of software development, such as

planning system requirements, validating design, testing software, and creating an outline for online help and user manuals.

Figure 2.2.1.1-Use Case Diagram Of Virtual Router 2.2.2 Class Diagram

12

Figure 2.2.2.1- Class Diagram

13

Figure 2.2.2.2-Class Diagram Of Virtual Router

14

2.2.3 State Diagram

Figure 2.6-State Transitions Diagram

15

Chapter- 3

SNAPSHOT
The following figures show some of the snapshots of the application Start page of application

Figure 3.1.1- Start Page Of The Virtual Router

16

Chapter-4

TESTING AND INTEGRATION

Figure 4.1.1 - System Testing 4.1 Overview The Virtual Router server setup consists of multiple components spanning the whole of a computing system right from low-level network interactions up to user-level interfaces. This as a consequence increases the overall complexity and with that problem/failure scenarios of the project. Furthermore VR, aimed as an education and research tool, is aimed for use at large universities and research centers which implies that it should not have any problems in scaling and must be able to handle real-life traffic loads. These concerns make detailed testing the VR setup an absolute necessity. A large part of the time in the VR project has been spent in designing, developing and implementing tools for testing all the server components. The result is a battery of test tools and utilities used for this purpose described below.

17

Figure 4.1.2 -Software Testing Steps

4.2 Unit Tests Each component has a set of unit tests tailored for it. The unit tests include an XML parser test which validates complex topology files. It checks whether the XML file is valid and contains a proper topology. To do so, it checks whether the graph formed by the virtual hosts specified in the XML file appears the same for every virtual host involved. Another unit test is designed to check the broadcast mapping table for a specific virtual host for a topology. It

18

loops through the broadcast map and displays all the listeners for that particular virtual host.

Figure 4.2.1-Uniting Testing We also have a unit test to specifically test the hardware info structure of the protocol. The hardware info is returned on a successful open call and contains the information about the network interfaces of the virtual host the client intends to serve in the VR and is validated using this test. 4.3 Regression Tests These tests are aimed at testing multiple components together. For the server we have a simple test to read in a topology, test sending and receiving of point-to-point packets and broadcast packets. This exercises the topology information and simulates actual exchange data between all the virtual hosts. On the protocol side, we have a test to exercise all the protocol commands currently used within VR especially the length fields and the memory layouts of the protocol packets. 4.4 Integration Testing Integration testing is a systematic technique for constructing the program structure while at the same time conducting tests to uncover errors associated with interfacing. The objective is to take unit tested components and build a program structure that has been dictated by design.

19

4.4.1 Top-Down Integration Top-down integration testing is an incremental approach to construction of program structure. Modules are integrated by moving downward through the control hierarchy, beginning with the main control module (main program). Modules subordinate (and ultimately subordinate) to the main control module are incorporated into the structure in either a depth-first or breadth-first manner.

Figure 4.4.1.1- Top-down Integration

Then, the central and right hand control paths are built. Breadth-first integration incorporates all components directly subordinate at each level, moving across the structure horizontally. From the figure, components M2, M3, and M4 (a replacement for stub S4) would be integrated first. The next control level, M5, M6, and so on, follows.

4.5 Clients Used For Testing We developed and used a number of clients having different levels of functionality to test VR. The clients we used were specifically developed for testing and are not general use clients which in themselves are the topic of a separate sister project. Below we present a list

20

of clients we used for testing and a brief description of each of their features along with the motivation in using: Java client [VR client] :There is a separate project to develop a very user-friendly & modular client which would be used by students and developers alike for running clients in the virtual router setup. This project separate from ours involved writing a Java client to provide such features. It involves a drag-drop GUI front end for the client. We have worked closely with the java client team and have tested VRIM extensively with it. Testing with the Java client was necessary because the VRIM server is to be bundled along with the java client so as to provide a fully usable framework server and client side for the end -user/developer.This is the fully functional client capable of performing all the activities a typical real-world virtual router client would. This involves handling ARP and IP packets, performing routing functions and understanding the VR client-server protocol.

4.6 Validation Testing At the culmination of integration testing, software is completely assembled as a package, interfacing errors have been uncovered and corrected, and a final series of software tests validation testing may begin.

21

Chapter-5

FUTURE SCOPE
5.1 Future Scope Of Application This application can be easily implemented under various situations. We can add new features as and when we require. Reusability is possible as and when require in this application. There is flexibility in all the modules. 5.2 Software Scope Extensibility:-This software is extendable in ways that its original developers may not

expect. The following principles enhance extensibility like hide data structure, avoid traversing multiple links or methods, avoid case statements on object type and distinguish public and private operations. Reusability:-Reusability is possible as and when require in this application. We can

update it next version. Understand ability:-A method is understandable if someone other than the creator of

the method can understand the code (as well as the creator after a time lapse). We use the method, which small and coherent helps to accomplish this.

22

Chapter-6

CONCLUSIONS
i. We have successfully designed and developed a project on Virtual Router. ii. Working on the project was good experience. iii. This project is designed for Virtual Routing over a network. VR is a significant improvement over the initial implementation of the virtual router server. It handles multiple arbitrary topologies, runs completely within user space and can be distributed across multiple physical servers. The results presented provide strong evidence that VRIM can gracefully handle heavy load and multiple clients. iv. This project is designed in JDK 1.6 which runs on eclipse. We learned several important things from this project. They were able to apply their new skills to a moderately complex project, use Java container classes, and experiment with threading and locking v. Developing the project has helped us some experience on routing procedure on client /server connectivity. The group also learned about IP routing. Implementing a routing protocol, even the simple one we chose, gave us insight in to how routers exchange messages.

23

REFERENCES
[1. James F Kurose and Keith W Ross. Computer Networking. first edition, 2000. [2. Bill Lewis and Daniel J. Berg. Multithreaded Programming with Java Technology Sun Microsystems, New Jersey, 1999. [3. Jon Bayous, Java technology: The early years. Sun Developer Network, no date [ca. 1998]. Retrieved April 22, 2005. [4. James Gosling, A brief history of the Green project. Java.net, no date [ca. Q1/1998]. Retrieved April 29, 2007. [5. SG24-6316-01 IBM Application Server V6.1 Security Handbook. [6. Herbert Scheldt, A complete reference. [7. http://www.w3schools.com [8. http://www.scribd.com

24

APPENDIX
This appendix is divided into two parts. In the first part, "Definitions," you will find definitions and explanations of terms and concepts. In the second part, "Sources for Terms," you will find a table listing terms and concepts and a pointer to which Administrator's Guide chapter or appendix contains a reference to or discussion of that term or concept. A Adapter An adapter is a representation of the physical point of attachment to a network segment. A LAN or WAN card is defined as one adapter. Adapters are also called network cards. Adapters are installed and configured through the Network Control Panel. Examples of adapters include Ethernet, FDDI, Token Ring, ISDN, Frame Relay, T1, and modem cards and devices. A complete list of supported adapters for Windows. Adjacency A relationship formed between selected neighboring routers for the purpose of exchanging routing information. When the link state databases of two neighboring routers are synchronized, the routers are said to be adjacent. Not every pair of neighboring routers becomes adjacent. Area Within an autonomous system, groups that comprise contiguous networks and the hosts attached to them. Area border router (ABR) A router that is attached to multiple areas. Area border routers maintain separate topological databases for each area. Autonomous System (AS) A group of routers exchanging routing information by using a common routing protocol. (ASBR) A router that exchanges routing information with routers that belong to other autonomous systems. The AS boundary router then advertises external routes throughout the autonomous

25

system. AS boundary routers can be internal or area border routers, and migh or might not be connected to the backbone. Auto-Static Updates Auto-static updates are supported in RIP for IP and RIP for IPX, but are not available for use with OSPF. When you configure an interface to use the auto-static update mode, the router sends a request to other routers and inherits routes. The routes are saved in the routing table as auto-static routes and are kept even if the router is restarted or if the interface goes down. B Backbone An OSPF backbone is responsible for distributing routing information between areas. It consists of all area border routers, networks not wholly contained in any area, and their attached routers. The backbone must be contiguous. Backbone Routers A router that is connected to the backbone. This includes routers that are connected to more than one area (area border routers). However, backbone routers do not have to be area border routers. Routers that have all networks connected to the backbone are internal routers. Bandwidth In communications, the difference between the highest and lowest frequencies in a given range. For example, a telephone line accommodates a bandwidth of 3000 Hz, the difference between the lowest (300 Hz) and highest (3300 Hz) frequencies it can carry. In computer networks, greater bandwidth indicates faster data-transfer capability and is expressed in bits per second. BOOTP/DHCP Relay Agent The component responsible for relaying DHCP and BOOTP broadcast messages between a BOOTP/DHCP server and a client across an IP router. With a relay agent, it is not necessary to have a DHCP or BOOTP server on each network segment. Border Gateway Protocol (BGP) A routing protocol designed for use between autonomous systems and especially useful to detect routing loops. (See the BGP version 4 specification in RFC 1654.) Broadcast 26

Destined for all hosts on a given network. Broadcast Network A network that supports more than two attached routers and has the ability to address a single physical message to all of the attached routers (broadcast). Ethernet is an example of a broadcast network. C Class A IP address An IP address that ranges from 1.0.0.0 to 126.0.0.0. Class A addresses are used by very large networks such as the ARPAnet. Class B IP address An IP address that ranges from 128.1.0.0 to 191.254.0.0. Class B addresses are used by large corporate networks. The first two octets indicate the network, and the last two octets are used to indicate subnets and hosts on the network. Class C IP address An IP address that ranges from 192.1.1.0 to 223.254.254.0. The first three octets indicate the network, and the last octet is used to indicate hosts on the network. JavaServer Pages Java Server Pages (JSP) technology enables you to mix regular, static HTML with dynamically generated content from servlets. You simply write the regular HTML in the normal manner, using familiar Web-page-building tools. You then enclose the code for the dynamic parts in special tags, most of which start with <% and end with %>. Thanks for ordering <I><%= request.getParameter("title") %></I> Separating the static HTML from the dynamic content provides a number of benefits over servlets alone, and the approach used in JavaServer Pages offers several advantages over competing technologies such as ASP, PHP, or ColdFusion. Section 1.4 (The Advantages of JSP) gives some details on these advantages, but they basically boil down to two facts: that JSP is widely supported and thus doesnt lock you into a particular operating system or Web server and that JSP gives you full access to servlet and Java technology for the dynamic part, rather than requiring you to use an unfamiliar and weaker special-purpose language. The process of making JavaServer Pages accessible on the Web is much simpler than that for

27

servlets. Assuming you have a Web server that supports JSP, you give your file a .jsp extension and simply install it in any place you could put a normal Web page: no compiling, no packages, and no user CLASSPATH settings. However, although your personal environment doesnt need any special settings, the server still has to be set up with access to the servlet and JSP class files and the Java compiler. For details, see your servers documentation or Section 1.5 (Installation and Setup). Although what you write often looks more like a regular HTML file than a servlet, behind the scenes, the JSP page is automatically converted to a normal servlet, with the static HTML simply being printed to the output stream associated with the servlets service method. This translation is normally done the first time the page is requested. To ensure that the first real user doesnt get a momentary delay when the JSP page is translated into a servlet and compiled, developers can simply request the page themselves after first installing it. Many Web servers also let you define aliases so that a URL that appears to reference an HTML file really points to a servlet or JSP page.

28