Vous êtes sur la page 1sur 72

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

CONTENTS
Chapter 01 Introduction.. Abstract .. Project Purpose.. Project Scope Product Features..... Chapter 02 System Analysis .. Problem Definition. Existing System Proposed System.. Feasibility Study.. Software Requirement .. Hardware Requirement Modules Description.. Functional Requirements. Non Functional Requirements. Literature Survey

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

Chapter 03 System Design SDLC Spiral Model Project Architecture Data Dictionary .. ER Models... ER Diagram .. OBJECT ORIENTED ANALYSIS AND DESIGN (OOAD)................ UML Diagrams . Use case. Class Sequence. Activity.. Chapter 04 Process Specification (Pseudo Code / Algorithm)...................... Screen Shots.. . Chapter 05 Development Phase Software Requirement Specification.. Coding.

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

Chapter 06 Testing Block & White Box Testing. Unit Testing System Testing.. Integration Testing Test Case Table . Chapter 07 Conclusion . Limitations & Future Enhancements Reference & Bibliography

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

Chapter 01

Introduction THE denial-of-service (DoS) attack has been a pressing problem in recent years. DoS defense research has blossomed into one of the main streams in network security. Various techniques such as the pushback message, ICMP traceback, and the packet filtering techniques are the results from this active field of research. The probabilistic packet marking (PPM) algorithm by Savage et al. has attracted the most attention in contributing the idea of IP

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

traceback. The most interesting point of this IP traceback approach is that it allows routers to encode certain information on the attack packets based on a predetermined probability. Upon receiving a sufficient number of marked packets, the victim (or a data collection node) can construct the set of paths that the attack packets traversed and, hence, the victim can obtain the location(s) of the attacker(s). The Probabilistic Packet Marking Algorithm The goal of the PPM algorithm is to obtain a constructed graph such that the constructed graph is the same as the attack graph, where an attack graph is the set of paths the attack packets traversed, and a constructed graph is a graph returned by the PPM algorithm. To fulfill this goal, Savage et al. Suggested a method for encoding the information of the edges of the attack graph into the attack packets through the cooperation of the routers in the attack graph and the victim site. Specifically, the PPM algorithm is made up of two separated procedures: the packet marking procedure, which is executed on the router side, and the graph reconstruction procedure, which is executed on the victim side. The packet marking procedure is designed to randomly encode edges information on the packets arriving at the routers. Then, by using the information, the victim executes the graph reconstruction procedure to construct the attack graph. We first briefly review the packet marking procedure so that readers can become familiar with how the router marks information on the packets

Abstract
The probabilistic packet marking (PPM) algorithm is a promising way to discover the Internet map or an attack graph that the attack packets traversed during a distributed denial-of-service attack. However, the PPM algorithm is not perfect, as its termination condition is not well defined in the literature. More importantly, without a proper termination condition, the attack

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

graph constructed by the PPM algorithm would be wrong. In this work, we provide a precise termination condition for the PPM algorithm and name the new algorithm the Rectified PPM (RPPM) algorithm. The most significant merit of the RPPM algorithm is that when the algorithm terminates, the algorithm guarantees that the constructed attack graph is correct, with a specified level of confidence. We carry out simulations on the RPPM algorithm and show that the RPPM algorithm can guarantee the correctness of the constructed attack graph under 1) different probabilities that a router marks the attack packets and 2) different structures of the network graph. The RPPM algorithm provides an autonomous way for the original PPM algorithm to determine its termination, and it is a promising means of enhancing the reliability of the PPM algorithm.

Scope This project will applicable in secured data sharing in the structured network. Purpose:
Work we provide a precise termination condition for the PPM algorithm and name the new algorithm the rectified PPM (RPPM) algorithm. The most significant merit of the RPPM algorithm is that when the algorithm terminates, the algorithm guarantees that the constructed attack graph is correct, with a specified level of confidence.

Features:

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

The packet marking procedure aims at encoding every edge of the attack graph, and the routers encode the information in three marking fields of an attack packet: the start, the end, and the distance fields (wherein Savage et al. [8] has discussed the design of the marking fields). In the following, we describe how a packet stores the information about an edge in the attack graph, and the pseudo code. When a packet arrives at a router, the router determines how the packet can be processed based on a random number x (line number 1 in the pseudocode). If x is smaller than the predefined marking probability pm, the router chooses to start encoding an edge. The router sets the start field of the incoming packet to the routers address and resets the distance field of that packet to zero. Then, the router forwards the packet to the next router. When the packet arrives at the next router, the router again chooses if it should start encoding another edge. For example, for this time, the router chooses not to start encoding a new edge. Then, the router will discover that the previous router has started marking an edge, because the distance field of the packet is zero. Eventually, the router sets the end field of the packet to the routers address. Nevertheless, the router increments the distance field of the packet by one so as to indicate the end of the encoding. Now, the start and the end fields together encode an edge of the attack graph.

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

Chapter 02
System Analysis
Requirements Analysis is done in order to understand the problem for which the software system is to solve. For example, the problem could be automating an existing manual process, or developing a completely new automated system, or a combination of the two. For large systems which have a large number of features, and that need to perform many different tasks, understanding the requirements of the system is a major task. The emphasis in requirements Analysis is on identifying what is needed from the system and not how the system will achieve it goals. This task is complicated by the fact that there are often at least two parties involved in software development - a client and a developer. The developer usually does not understand the client's problem domain, and the client often does not understand the issues involved in software systems. This causes a communication gap, which has to be adequately bridged during requirements Analysis. In most software projects, the requirement phase ends with a document describing all the requirements. In other words, the goal of the requirement specification phase is to produce the software requirement specification document. The person responsible for the requirement analysis is often called the analyst. There are two major activities in this phase - problem understanding or analysis and requirement specification in problem analysis; the analyst has to understand the problem and its context. Such analysis typically requires a thorough understanding of the existing system, the parts of which must be automated. Once the problem is analyzed and the essentials understood, the requirements must be specified in the requirement specification document. For requirement specification in the form of document, some specification language has to be selected (example: English, regular expressions, tables, or a combination of these). The requirements documents must specify all functional and performance requirements, the formats of inputs, outputs and any required standards, and all design constraints that exits due to political, economic environmental, and security reasons. The phase ends with validation of requirements specified in the document. The basic purpose of validation is to make sure that the requirements specified in the document, actually reflect the actual requirements or needs, and that all requirements are specified. Validation is often done through requirement review, in which a group of people including representatives of the client, critically review the requirements specification.

Software Requirement or Role of Software Requirement Specification (SRS) IEEE (Institute of Electrical and Electronics Engineering) defines as, A condition of capability needed by a user to solve a problem or achieve an objective; A condition or capability that must be met or possessed by a system to satisfy a contract, standard, specification, or other formally imposed document. Note that in software requirements we are dealing with the requirements of the proposed system, that is, the capabilities that system, which is yet to be developed, should have. It is because we are dealing with specifying a system that does not exist in any form that the problem of requirements becomes complicated. Regardless of how the requirements phase proceeds, the Software Requirement Specification (SRS) is a document that completely describes what the proposed software should do without describing how the system will do it?. The basic goal of the requirement phase is to produce the

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

Software Requirement Specification (SRS), which describes the complete external behavior of the proposed software.

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

EXISTING SYSTEM In the existing system PPM algorithm is not perfect, as its termination condition is not well defined. Without proper termination condition the attack graph constructed by the PPM algorithm would be wrong. The algorithm requires prior knowledge about the network topology.

Proposed System To propose termination condition of the PPM algorithm, this is missing or is not explicitly defined in the literature. Through the new termination condition, the user of the new algorithm is free to determine the correctness of the constructed graph. The constructed graph is guaranteed to reach the correctness assigned by the user, independent of the marking probability and the structure of the underlying network graph. In this system we proposed a Probabilistic Packet Marking Algorithm to encode the packet in the routers to detect the attacked packets. To reduce the a constructed graph such that the constructed graph is the same as the attack graph, where an attack graph is the set of paths the attack packets traversed, To construct a graph, is a graph returned by the PPM algorithm.

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

SYSTEM CONFIGURATION
Hardware & Software Requirements Hardware specification: Monitor : 800*600 minimum resolution of 256 colors Processor: At least 166 MHz processor Input : Two or Three button mouse and standard 104 keyboards.

Software specification: Front End: Java , Swings Back End: Oracle

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

FEASIBLITY STUDY The feasibility of the project is analyzed in this phase and business proposal is put forth with a very general plan for the project and some cost estimates. During system analysis the feasibility study of the proposed system is to be carried out. This is to ensure that the proposed system is not a burden to the company. For feasibility analysis, some understanding of the major requirements for the system is essential.

Three key considerations involved in the feasibility analysis are ECONOMICAL FEASIBILITY TECHNICAL FEASIBILITY SOCIAL FEASIBILITY ECONOMICAL FEASIBILITY: This study is carried out to check the economic impact that the system will have on the organization. The amount of fund that the company can pour into the research and development of the system is limited. The expenditures must be justified. Thus the developed system as well within the budget and this was achieved because most of the technologies used are freely available. Only the customized products had to be purchased. TECHNICAL FEASIBILITY:

This study is carried out to check the technical feasibility, that is, the technical requirements of the system. Any system developed must not have a high demand on the available technical resources. This will lead to high demands on the available technical
IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

esources. This will lead to high demands being placed on the client. The developed system must have a modest requirement, as only minimal or null changes are required for implementing this system. SOCIAL FEASIBILITY: The aspect of study is to check the level of acceptance of the system by the user. This includes the process of training the user to use the system efficiently. The user must not feel threatened by the system, instead must accept it as a necessity. The level of acceptance by the users solely depends on the methods that are employed to educate the user about the system and to make him familiar with it. His level of confidence must be raised so that he is also able to make some constructive criticism, which is welcomed, as he is the final user of the system. Module Description: Path Construction In this module the path will be constructed which the data packets should traverse. This path should be dynamically changed in case of traffic and failure in router. Packet marking procedure In this module, each packet will be marked with random values. These values are encoded and its appended in the start or in the edge of the packets. These values are checked by the packet marking procedure. Router maintenance In this module the router availability will be checked depends upon the router availability the path will be constructed. TPN Generation In this module the encoded values in the packet are retrieved and its decoded and checked with the generated code.

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

Re-Construction Path In this module the path will be re-constructed with the received packets its validated with the constructed path. In Module Given Input and Expected output Path Construction Given Input: Select the paths for data traverse. Expected Output: Path will be generated. Packet marking procedure Given Input: Select the values to be encoded. Expected Output: Packet will be encoded and then it will be appended to the packets. Router maintenance Given Input: Design the graphical user interface for router maintenance. Expected Output: Change the router availability dynamically. TPN Generation Given Input: Retrieve the encoded values. Expected Output: Get the exact values by decoding the number. Re-Construction Path Given Input: Retrieve the path from the attack graph. Expected Output: Get the reconstructed path.

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

Function Requirements
Functional requirements specify which outputs should be produced from the given inputs. They describe the relationship between the input and output of the system, for each functional requirement a detailed description of all data inputs and their source and the range of valid inputs must be specified. All the operations to be performed on the input data to obtain the output should be specified. Updating Work status. Problem resolution. Error occurrence in the system. Customer requests.

NON FUNCTIONAL REQUIREMENTS The project non functional requirements include the following. 3.3.1 USABILITY The system is used by the four persons namely Administrator, Project Manager, Developer and the customer. Each person is having their own roles and are separated by the security issues. 3.3.2 RELIABLITY The system is said to be reliable because the entire system was built using java which is most robust language. Reliability refers to the standards of the system. 3.3.3 PERFORMANCE

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

System is highly functional and good in performance. The system must use the minimal set of variables and minimal usage of the control structures will dynamically increase the performance of the system. 3.3.4 SUPPORTABILITY The system is supportable with different platforms and a wide range of machines. the java code used in this project is more flexible and having a feature of platform independence. And also added support for wide range of mobile phone which supports CLDC platform. 3.3.5 IMPLEMENTATION The system would be implemented in a networked and mobile based WAP environment. 3.3.6 INTERFACE This system uses three user interfaces. Most of the project is developed by using the java Swing user interface and some components in mobile interface and customer module in the web based interface. 3.3.7 PACKAGING The entire system was packaged into single package. 3.3.8 LEGAL The legal issues of this project are unknown as that rights are not applicable for the project done for the academics. All the legal rights are sol proprietor of the organization.

Literature Survey

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

Chapter 03
System Design:
The purpose of the design phase is to plan a solution of the problem specified by the requirement document. This phase is the first step in moving from problem domain to the solution domain. The design of a system is perhaps the most critical factor affecting the quality of the software, and has a major impact on the later phases, particularly testing and maintenance. The output of this phase is the design document. This document is similar to a blue print or plan for the solution, and is used later during implementation, testing and maintenance.

The design activity is often divided into two separate phase-system design and detailed design. System design, which is sometimes also called top-level design, aims to identify the modules that should be in the system, the specifications of these modules, and how they interact with each other to produce the desired results. At the end of system design all the major data structures, file formats, output formats, as well as the major modules in the system and their specifications are decided.

During detailed design the internal logic of each of the modules specified in system design is decided. During this phase further details of the data structures and algorithmic design of each of the modules is specified. The logic of a module is usually specified in a high-level design description language, which is independent of the target language in which the software will eventually be implemented. In system design the focus is on identifying the modules, whereas during detailed design the focus is on designing the logic for each of the

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

modules. In other words, in system design the attention is on what components are needed, while in detailed design how the components can be implemented in software is the issue.

During the design phase, often two separate documents are produced. One for the system design and one for the detailed design . Together, these documents completely specify the design of the system. That is they specify the different modules in the system and internal logic of each of the modules.

A design methodology is a systematic approach to creating a design by application of set of techniques and guidelines. Most methodologies focus on system design. The two basic principles used in any design methodology are problem partitioning and abstraction. A large system cannot be handled as a whole, and so for design it is partitioned into smaller systems. Abstraction is a concept related to problem partitioning. When partitioning is used during design, the design activity focuses on one part of the system at a time. Since the part being designed interacts with other parts of the system, a clear understanding of the interaction is essential for properly designing the part. For this, abstraction is used. An abstraction of a system or a part defines the overall behavior of the system at an abstract level without giving the internal details. While working with the part of a system, a designer needs to understand only the abstractions of the other parts with which the part being designed interacts. The use of abstraction allows the designer to practice the "divide and conquer" technique effectively by focusing one part at a time, without worrying about the details of other parts.

Like every other phase, the design phase ends with verification of the design. If the design is not specified in some executable language, the verification has to be done by evaluating the design documents. One way of doing this is thorough reviews. Typically, at least two design

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

reviews are held-one for the system design and one for the detailed and one for the detailed design.

Software Development Life Cycle


This document play a vital role in the development of life cycle (SDLC) as it describes the complete requirement of the system. It means for use by developers and will be the basic during testing phase. Any changes made to the requirements in the future will have to go through formal change approval process.

The trends of increasing technical complexity of the systems, coupled with the need for repeatable and predictable process methodologies, have driven System Developers to establish system development models or software development life cycle models. Nearly three decades ago the operations in an organization used to be limited and so it was possible to maintain them using manual procedures. But with the growing operations of organizations, the need to automate the various activities increased, since for manual procedures it was becoming very difficult, slow and complicated. Like maintaining records for a thousand plus employees company on papers is definitely a cumbersome job. So, at that time more and more companies started going for automation.

Since there were a lot of organizations, which were opting for automation, it was felt that some standard and structural procedure or methodology be introduced in the industry so that the transition from manual to automated system became easy. The concept of system life cycle came into existence then. Life cycle model emphasized on the need to follow some structured approach towards building new or improved system. There were many models suggested. A waterfall model was among the very first models that came into existence. Later
IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

on many other models like prototype, rapid application development model, etc were also introduced.

System development begins with the recognition of user needs. Then there is a preliminary investigation stage. It includes evaluation of present system, information gathering, feasibility study, and request approval. Feasibility study includes technical, economic, legal and operational feasibility. In economic feasibility cost-benefit analysis is done. After that, there are detailed design, implementation, testing and maintenance stages.

In this session, we'll be learning about various stages that make system's life cycle. In addition, different life cycles models will be discussed. These include Waterfall model, Prototype model, Object-Oriented Model, spiral model and Dynamic Systems Development Method (DSDM).

SPIRAL MODEL
SPIRAL MODEL was defined by Barry Boehm in his 1988 article, A spiral Model of Software Development and Enhancement. This model was not the first model to discuss iterative development, but it was the first model to explain why the iteration models. As originally envisioned, the iterations were typically 6 months to 2 years long. Each phase starts with a design goal and ends with a client reviewing the progress thus far. Analysis and engineering efforts are applied at each phase of the project, with an eye toward the end goal of the project. The steps for Spiral Model can be generalized as follows:

The new system requirements are defined in as much details as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system.

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

A preliminary design is created for the new system. A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product.

A second prototype is evolved by a fourfold procedure: Evaluating the first prototype in terms of its strengths, weakness, and risks. Defining the requirements of the second prototype. Planning an designing the second prototype. Constructing and testing the second prototype.

At the customer option, the entire project can be aborted if the risk is deemed too great. Risk factors might involve development cost overruns, operating-cost miscalculation, or any other factor that could, in the customers judgment, result in a less-than-satisfactory final product. The existing prototype is evaluated in the same manner as was the previous prototype, and if necessary, another prototype is developed from it according to the fourfold procedure outlined above. The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired. The final system is constructed, based on the refined prototype. The final system is thoroughly evaluated and tested. Routine maintenance is carried on a continuing basis to prevent large scale failures and to minimize down time.

The following diagram shows how a spiral model acts like:

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

Fig 1.0-Spiral Model

ADVANTAGES:

Estimates(i.e. budget, schedule etc .) become more relistic as work progresses,

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

because important issues discoved earlier.

It is more able to cope with the changes that are software development generally entails.

You are now ready to edit, run, and compile the project with DJava..

Spiral Model Description The development spiral consists of four quadrants as shown in the figure above Quadrant 1: Determine objectives, alternatives, and constraints. Quadrant 2: Evaluate alternatives, identify, resolve risks. Quadrant 3: Develop, verify, next-level product. Quadrant 4: Plan next phases. Although the spiral, as depicted, is oriented toward software development, the concept is equally applicable to systems, hardware, and training, for example. To better understand the scope of each spiral development quadrant, lets briefly address each one.

Quadrant 1: Determine Objectives, Alternatives, and Constraints


Activities performed in this quadrant include: Establish an understanding of the system or product objectivesnamely performance, functionality, and ability to accommodate change. Investigate implementation alternativesnamely design, reuse, procure, and procure/ modify. Investigate constraints imposed on the alternativesnamely technology, cost, schedule, support, and risk. Once the system or products objectives, alternatives, and constraints are understood, Quadrant 2 (Evaluate alternatives, identify, and resolve risks) is performed.

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

Quadrant 2: Evaluate Alternatives, Identify, Resolve Risks


Engineering activities performed in this quadrant select an alternative approach that best satisfies technical, technology, cost, schedule, support, and risk constraints. The focus here is on risk mitigation. Each alternative is investigated and prototyped to reduce the risk associated with the development decisions. Boehm describes these activities as follows: This may involve prototyping, simulation, benchmarking, reference checking, administering user questionnaires, analytic modeling, or combinations of these and other risk resolution techniques. The outcome of the evaluation determines the next course of action. If critical operational and/or technical issues (COIs/CTIs) such as performance and interoperability (i.e., external and internal) risks remain, more detailed prototyping may need to be added before progressing to the next quadrant. Dr. Boehm notes that if the alternative chosen is operationally useful and robust enough to serve as a low-risk base for future product evolution, the subsequent risk-driven steps would be the evolving series of evolutionary prototypes going toward the right (hand side of the graphic) the option of writing specifications would be addressed but not exercised. This brings us to Quadrant 3.

Quadrant 3: Develop, Verify, Next-Level Product


If a determination is made that the previous prototyping efforts have resolved the COIs/CTIs, activities to develop, verify, next-level product are performed. As a result, the basic waterfall approach may be employedmeaning concept of operations, design, development, integration, and test of the next system or product iteration. If appropriate, incremental development approaches may also be applicable.

Quadrant 4: Plan Next Phases


The spiral development model has one characteristic that is common to all modelsthe need for advanced technical planning and multidisciplinary reviews at critical staging or control

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

points. Each cycle of the model culminates with a technical review that assesses the status, progress, maturity, merits, risk, of development efforts to date; resolves critical operational and/or technical issues (COIs/CTIs); and reviews plans and identifies COIs/CTIs to be resolved for the next iteration of the spiral. Subsequent implementations of the spiral may involve lower level spirals that follow the same quadrant paths and decision considerations.

UML Diagrams :

Object Oriented Analysis:

An object-oriented system is composed of objects. The behavior of the system is achieved through collaboration between these objects, and the state of the system is the combined state of all the objects in it. Collaboration between objects involves them sending messages to each other. The exact semantics of message sending between objects varies depending on what kind of system is being modeled. In some systems, "sending a message" is the same as "invoking a method". Object Oriented Analysis aims to model the problem domain, the problem we want to solve by developing an object-oriented (OO)System The source of the analysis is a written requirement statements, and/or written use cases, UML diagrams can be used to illustrate the statements An analysis model will not take into account implementation constraints, such as concurrency, distribution, persistence, or inheritance, nor how the system will be built The model of a system can be divided into multiple domains each of which are separately analyzed, and represent

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

separate business, technological, or conceptual areas of interest The result of object-oriented analysis is a description of what is to be built, using concepts and relationships between concepts, often expressed as a conceptual model. Any other documentation that is needed to describe what is to be built, is also included in the result of the analysis. That can include a detailed user interface mock-up document The implementation constraints are decided during the object-oriented design (OOD) process Object Oriented Design Object-Oriented Design (OOD) is an activity where the designers are looking for logical solutions to solve a problem, using Objects Object-oriented design takes the conceptual model that is the result of object-oriented analysis, and adds implementation constraints imposed by the environment, the programming language and the chosen tools, as well as architectural assumptions chosen as basis of Design The concepts in the conceptual model are mapped to concrete classes, to abstract interfaces in APIs and to roles that the objects take in various situations. The interfaces and their implementations for stable concepts can be made available as reusable services. Concepts identified as unstable in object-oriented analysis will form basis for policy classes that make decisions, implement environment-specific or situation specific logic or algorithms The result of the object-oriented design is a detail description how the system can be built, using objects .Object-oriented software engineering (OOSE) is an object modeling language and Methodology

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

OOSE was developed by Ivar Jacobson in 1992 while at Objectory AB. It is the first objectoriented design methodology to employ use cases to drive software design. It also uses other design products similar to those used by OMT The tool Objectory was created by the team at Objectory AB to implement the OOSE methodology. After success in the marketplace, other tool vendors also supported OOSE After Rational bought Objectory AB, the OOSE notation, methodology, and tools became superseded

As one of the primary sources of the Unified Modeling Language (UML), concepts and notation from OOSE have been incorporated into UML

The methodology part of OOSE has since evolved into the Rational Unified Process (RUP)

The OOSE tools have been replaced by tools supporting UML and RUP

OOSE has been largely replaced by the UML notation and by the RUP methodology

Unified Modeling Language

The heart of object-oriented problem solving is the construction of a model. The model abstracts the essential details of the underlying problem from its usually complicated real world. Several modeling tools are wrapped under the heading of the UML, which stands for Unified Modeling Language. The purpose of this course is to present important highlights of the UML. At the center of the UML are its nine kinds of modeling diagrams, which we describe here. Use case diagrams Class diagrams Object diagrams Sequence diagrams Collaboration diagrams Statechart diagrams Activity diagrams

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

Component diagrams Deployment diagrams

Some of the sections of this course contain links to pages with more detailed information. And every section has short questions. Use them to test your understanding of the section topic. Why is UML important? Let's look at this question from the point of view of the construction trade. Architects design buildings. Builders use the designs to create buildings. The more complicated the building, the more critical the communication between architect and builder. Blueprints are the standard graphical language that both architects and builders must learn as part of their trade. Writing software is not unlike constructing a building. The more complicated the underlying system, the more critical the communication among everyone involved in creating and deploying the software. In the past decade, the UML has emerged as the software blueprint language for analysts, designers, and programmers alike. It is now part of the software trade. The UML gives everyone from business analyst to designer to programmer a common vocabulary to talk about software design. The UML is applicable to object-oriented problem solving. Anyone interested in learning UML must be familiar with the underlying tenet of object-oriented problem solving -- it all begins with the construction of a model. A model is an abstraction of the underlying problem. The domain is the actual world from which the problem comes. Models consist of objects that interact by sending each other messages. Think of an object as "alive." Objects have things they know (attributes) and things they can do (behaviors or operations). The values of an object's attributes determine its state. Classes are the "blueprints" for objects. A class wraps attributes (data) and behaviors (methods or functions) into a single distinct entity. Objects are instances of classes. . Group Business Technical Term Accounting Periods Association Definition A defined period of time whereby performance reports may be extracted. (normally 4 week periods). A relationship between two or more entities. Implies a connection of some type - for example one entity uses the services of another, or one entity is connected to another over a network link. A logical entity encapsulating data and behavior. A class is a template for an object the class is the design, the object the runtime instance. The component model provides a detailed view of the various hardware and software components that make up the proposed system. It shows both where these components reside and how they inter-relate with other components. Component

Technical

Class

Technical

Component Model

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

Business Technical

Customer Deployment Architecture

Technical Technical

Deployment Model Extends Relationship

Technical

Includes Relationship

Technical

Use Case

A person or a company that requests An entity to transport goods on their behalf. A view of the proposed hardware that will make up the new system, together with the physical components that will execute on that hardware. Includes specifications for machine, operating system, network links, backup units &etc. A model of the system as it will be physically deployed A relationship between two use cases in which one use case 'extends' the behavior of another. Typically this represents optional behavior in a use case scenario - for example a user may optionally request a list or report at some point in a performing a business use case. A relationship between two use cases in which one use case 'includes' the behavior. This is indicated where there a specific business use cases which are used from many other places - for example updating a train record may be part of many larger business processes. A Use Case represents a discrete unit of interaction between a user (human or machine) and the system. A Use Case is a single unit of meaningful work; for example creating a train, modifying a train and creating orders are all Use Cases.Each Use Case has a description which describes the functionality that will be built in the proposed system. A Use Case may 'include' another Use Case's functionality or 'extend' another Use Case with its own behavior.Use Cases are typically related to 'actors'. An actor is a human or machine entity that interacts with the system to perform meaningful work.

1.1 Actors

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

Actors are the users of the system being modeled. Each Actor will have a well-defined role, and in the context of that role have useful interactions with the system. A person may perform the role of more than one Actor, although they will only assume one role during one use case interaction.

EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version uc Actors EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version
Figure 2: Actors
SecuritySpecialist

An Actor role may be performed by a non-human system, such as another computer program.

EA 7.1 Unregistered Trial Version


Use Cases Use case represent the functionality the system from a users point of view. EADiagrams 7.1 Unregistered Trial of Version Use cases are used during requirements elicitation and analysis to represent the functionality of the system. Use focus on the behavior of Trial the system from external point of view. EAcases 7.1 Unregistered Version Actors are external entities that interact with the system. Examples of actors include users like administrator, bank Unregistered customer etc., or another system like central database. EA 7.1 Trial Version

EA Use Case Model

7.1 Unregistered Trial Version

EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version


Sequence Diagram

EA 7.1 Unregistered Trial Version


IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

EA 7.1 Unregistered Trial Version EA 7.1 Unregistered Trial Version

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

Class and object diagrams are static model views. Interaction diagrams are dynamic. They describe how objects collaborate. A sequence diagram is an interaction diagram that details how operations are carried out -- what messages are sent and when. Sequence diagrams are organized according to time. The time progresses as you go down the page. The objects involved in the operation are listed from left to right according to when they take part in the message sequence. Class Diagram A Class diagram gives an overview of a system by showing its classes and the relationships among them. Class diagrams are static -- they display what interacts but not what happens when they do interact.

Our class diagram has three kinds of relationships. association -- a relationship between instances of the two classes. There is an association between two classes if an instance of one class must know about the other in order to perform its work. In a diagram, an association is a link connecting two classes. aggregation -- an association in which one class belongs to a collection. An aggregation has a diamond end pointing to the part containing the whole. generalization -- an inheritance link indicating one class is a superclass of the other. A generalization has a triangle pointing to the superclass.

Activity Diagram

An activity diagram is essentially a fancy flowchart. Activity diagrams and statechart diagrams are related. While a statechart diagram focuses attention on an object undergoing a process (or on

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

a process as an object), an activity diagram focuses on the flow of activities involved in a single process. The activity diagram shows the how those activities depend on one another.

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

Class Diagram

PPM Source pm sendData() constructedGraph()

PPM Router append marking()

PPM Destination decode orginaldata Re-Consrtuction Path() TPN()

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

Use Case Diagram

Source File

Source

Constructed Path

Marking Probability

Router

Leaf Router

Attack Graph

TPN

Transition Router

Destination

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

Collaboration Diagram

PPM Source

1: packetMarking Router

2: Destination

Destination

Sequence Diagram

PPM Source packetMarking

Router

Destination

Destination

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

Activity Diagram

PPM Source

True

False Marking Condition

Start Field

End Field

Router Management

PPM Destination

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

Development Phase Once the design is complete, most of the major decisions about the system have been made. The goal of the coding phase is to translate the design of the system into code in a given programming language. For a given design, the aim of this phase is to implement the design in the best possible manner. The coding phase affects both testing and maintenance profoundly. A well written code reduces the testing and maintenance effort. Since the testing and maintenance cost of software are much higher than the coding cost, the goal of coding should be to reduce the testing and maintenance effort. Hence, during coding the focus should be on developing programs that are easy to write. Simplicity and clarity should be strived for, during the coding phase. An important concept that helps the understandability of programs is structured programming. The goal of structured programming is to arrange the control flow in the program. That is, program text should be organized as a sequence of statements, and during execution, the statements are executed in the sequence in the program. For structured programming, a few single-entry-single-exit constructs should be used. These constructs includes selection (if-then-else), and iteration (while - do, repeat - until etc). With these constructs it is possible to construct a program as sequence of single - entry - single - exit constructs. There are many methods available for verifying the code. Some methods are static in nature that is, that is they do not involve execution of the code. Examples of such methods are data flow analysis, code reading, code reviews, testing (a method that involves executing the code, which is used very heavily). In the coding phase, the entire system is not tested together. Rather, the different modules are tested separately. This testing of modules is called "unit testing". Consequently, this phase is often referred to as "coding and unit testing". The output of this phase is the verified and unit tested code of the different modules.

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

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

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

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.

You can think of Java byte codes as the machine code instructions for the Java Virtual Machine (Java VM). Every Java interpreter, whether its a development tool or a Web browser that can run applets, is an implementation of the Java VM. Java byte codes help make write once, run anywhere possible. You can compile your program into byte codes on any platform that has a Java compiler. The byte codes 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.

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

The Java Platform


A platform is the hardware or software environment in which a program runs. Weve 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 its 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)

Youve already been introduced to the Java VM. Its 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 thats running on the Java platform. As the figure shows, the Java API and the virtual machine insulate the program from the hardware.

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

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 byte code 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 youve surfed the Web, youre 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.

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

How does the API support all these kinds of programs? It does so with packages of software components that provides 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.

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

How Will Java Technology Change My Life?

We cant promise you fame, fortune, or even a job if you learn the Java programming language. Still, it is likely to make your programs better and requires less effort than other languages. We believe that Java technology will help you do the following:

Get started quickly: Although the Java programming language is a powerful object-oriented language, its easy to learn, especially for programmers already familiar with C or C++. Write less code: Comparisons of program metrics (class counts, method counts, and so on) suggest that a program written in the Java programming language can be four times smaller than the same program in C++. Write better code: The Java programming language encourages good coding practices, and its garbage collection helps you avoid memory leaks. Its object orientation, its JavaBeans component architecture, and its wide-ranging, easily extendible API let you reuse other peoples tested code and introduce fewer bugs.

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

Develop programs more quickly: Your development time may be as much as twice as fast versus writing the same program in C++. Why? You write fewer lines of code and it is a simpler programming language than C++. Avoid platform dependencies with 100% Pure Java: You can keep your program portable by avoiding the use of libraries written in other languages. The 100% Pure JavaTM Product Certification Program has a repository of historical process manuals, white papers, brochures, and similar materials online. Write once, run anywhere: Because 100% Pure Java programs are compiled into machine-independent byte codes, they run consistently on any Java platform. Distribute software more easily: You can upgrade applets easily from a central server. Applets take advantage of the feature of allowing new classes to be loaded on the fly, without recompiling the entire program.

Finally we decided to proceed the implementation using Java Networking. And for dynamically updating the cache table we go for MS Access database. JAVA HA TWO THINGS: A PROGRAMMING LANGUAGE AND A PLATFORM. JAVA IS A HIGH-LEVEL PROGRAMMING LANGUAGE THAT IS ALL OF THE FOLLOWING

SIMPLE NEUTRAL

ARCHITECTURE-

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

OBJECT-ORIENTED DISTRIBUTED PERFORMANCE INTERPRETED MULTITHREADED ROBUST SECURE

PORTABLE HIGH-

DYNAMIC

JAVA IS ALSO UNUSUAL IN THAT EACH JAVA PROGRAM IS BOTH COMPILED AND INTERPRETED. WITH A COMPILE YOU TRANSLATE A JAVA PROGRAM INTO AN INTERMEDIATE LANGUAGE CALLED JAVA BYTE CODES THE PLATFORMINDEPENDENT CODE INSTRUCTION IS PASSED AND RUN ON THE COMPUTER.

COMPILATION HAPPENS JUST ONCE; INTERPRETATION OCCURS EACH TIME THE PROGRAM IS EXECUTED. THE FIGURE ILLUSTRATES HOW THIS WORKS.

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

Java Program

Interpreter

Compilers

My Program

YOU CAN THINK OF JAVA BYTE CODES AS THE MACHINE CODE INSTRUCTIONS FOR THE JAVA VIRTUAL MACHINE (JAVA VM). EVERY JAVA INTERPRETER, WHETHER ITS A JAVA DEVELOPMENT TOOL OR A WEB BROWSER THAT CAN RUN JAVA APPLETS, IS AN IMPLEMENTATION OF THE JAVA VM. THE JAVA VM CAN ALSO BE IMPLEMENTED IN HARDWARE.

JAVA BYTE CODES HELP MAKE WRITE ONCE, RUN ANYWHERE POSSIBLE. YOU CAN COMPILE YOUR JAVA PROGRAM INTO BYTE CODES ON MY PLATFORM THAT HAS A JAVA COMPILER. THE BYTE CODES CAN THEN BE RUN ANY IMPLEMENTATION OF THE JAVA VM. FOR EXAMPLE, THE SAME JAVA PROGRAM CAN RUN WINDOWS NT, SOLARIS, AND MACINTOSH.

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

Introduction to Swing
This introduction to using Swing in Java will walk you through the basics of Swing. This covers topics of how to create a window, add controls, postion the controls, and handle events from the controls.
The Main Window

Almost all GUI applications have a main or top-level window. In Swing, such window is usually instance of JFrame or JWindow. The difference between those two classes is in simplicity JWindow is much simpler than JFrame (most noticeable are visual differences - JWindow does not have a title bar, and does not put a button in the operating system task bar). So, your applications will almost always start with a JFrame. Though you can instantiate a JFrame and add components to it, a good practice is to encapsulate and group the code for a single visual frame in a separate class. Usually, I subclass the JFrame and initialize all visual elements of that frame in the constructor. Always pass a title to the parent class constructor that String will be displayed in the title bar and on the task bar. Also, remember to always initialize frame size (by calling setSize(width,height)), or your frame will not be noticeable on the screen. package com.neuri.handsonswing.ch1; import javax.swing.JFrame; public class MainFrame extends JFrame { public MainFrame()

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

{ super("My title"); setSize(300, 300); } } Now you have created your first frame, and it is time to display it. Main frame is usually displayed from the main method but resist the urge to put the main method in the frame class. Always try to separate the code that deals with visual presentation from the code that deals with application logic starting and initializing the application is part of application logic, not a part of visual presentation. A good practice is to create an Application class that will contain initialization code. package com.neuri.handsonswing.ch1; public class Application { public static void main(String[] args) { // perform any initialization MainFrame mf = new MainFrame(); mf.show(); } } If you run the code now, you will see an empty frame. When you close it, something not quite obvious will happen (or better said, will not happen). The application will not end. Remember that the Frame is just a visual application, not application not request application the window closes, your run in the background (look for list). To avoid this problem, line to the MainFrame part of logic if you do termination when program will still it in the process add the following constructor:

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

Before Java2 1.3, you had to register a window listener and then act on the window closing event by stopping the application. Since Java2 1.3, you can specify a simple action that will happen when a window is closed with this shortcut. Other options are HIDE_ON_CLOSE (the default window is closed but application still runs) and DO_NOTHING_ON_CLOSE (rather strange option that ignores a click on the X button in the upper right corner). Adding Components Now is the time to add some components to the window. In Swing (and the Swing predecessor, AWT) all visual objects are subclasses of Component class. The Composite pattern was applied here to group visual objects into Containers, special components that can contain other components. Containers can specify the order, size and position of embedded components (and this can all be automatically calculated, which is one of the best features of Swing). JButton is a component class that represents a general purpose button it can have a text caption or an icon, and can be pressed to invoke an action. Lets add the button to the frame (note: add imports for javax.swing.* and java.awt.* to the MainFrame source code so that you can use all the components). When you work with JFrame, you want to put objects into its content pane special container intended to hold the window contents. Obtain the reference to that container with the getContentPane() method. Container content = getContentPane(); content.add(new JButton("Button 1"));

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

If you try to add more buttons to the frame, most likely only the last one added will be displayed. That is because the default behavior of JFrame content pane is to display a single component, resized to cover the entire area. Grouping Components To put more than one component into a place intended for a single component, group them into a container. JPanel is a general purpose container, that is perfect for grouping a set of components into a larger component. So, lets put the buttons into a JPanel: JPanel panel=new JPanel(); panel.add(new JButton("Button 1")); panel.add(new JButton("Button 2")); panel.add(new JButton("Button 3")); content.add(panel);

Layout Management Basics One of the best features of Swing is automatic component positioning and resizing. That is implemented trough a mechanism known as Layout management. Special objects layout managers are responsible for sizing, aligning and positioning components. Each container can

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

have a layout manager, and the type of layout manager determines the layout of components in that container. There are several types of layout managers, but the two you will most frequently use are FlowLayout (orders components one after another, without resizing) and BorderLayout (has a central part and four edge areas component in the central part is resized to take as much space as possible, and components in edge areas are not resized). In the previous examples, you have used both of them. FlowLayout is the default for a JPanel (that is why all three buttons are displayed without resizing), and BorderLayout is default for JFrame content panes (that is why a single component is shown covering the entire area). Layout for a container is defined using the setLayout method (or usually in the constructor). So, you could change the layout of content pane to FlowLayout and add several components, to see them all on the screen. The best choice for the window content pane is usually a BorderLayout with a central content part and a bottom status (or button) part. The top part can contain a toolbar, optionally. Now, lets combine several components and layouts, and introduce a new component JTextArea. JTextArea is basically a multiline editor. Initialize the frame content pane explicitly to BorderLayout, put a new JTextArea into the central part and move the button panel below. package com.neuri.handsonswing.ch1; import java.awt.*; import javax.swing.*; public class MainFrame extends JFrame { public MainFrame() { super("My title"); setSize(300,300);

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); Container content = getContentPane(); content.setLayout(new BorderLayout()); JPanel panel = new JPanel(new FlowLayout()); panel.add(new JButton("Button 1")); panel.add(new JButton("Button 2")); panel.add(new JButton("Button 3")); content.add(panel, BorderLayout.SOUTH); content.add(new JTextArea(), BorderLayout.CENTER); } } Notice that the layouts for content pane and the button panel are explicitly defined. Also notice the last two lines of code this is the other version of add method, which allows you to specify the way the component is added. In this case, we specify the area of BorderLayout layout manager. Central part is called BorderLayout.CENTER, and other areas are called BorderLayout.NORTH (top), BorderLayout.SOUTH (bottom), BorderLayout.WEST (left) and BorderLayout.EAST (right). If you get confused about this, just remember land-maps from your geography classes. OVERVIEW OF JAVA RMI DISTRIBUTED COMPUTING In the present modern Internet World, Distributed Computing is one of the key areas that play an important role. Distributed systems require that computations running in different address spaces, potentially on different hosts, be able to communicate with each other. . An alternative to sockets used in java is Remote Procedure Call (RPC), which abstracts the communication interface to the level of a procedure call. Instead of working directly with sockets, the programmer has the illusion of calling a local procedure, when in fact the arguments of the call are packaged up and shipped off to the remote target of the call. RPC systems encode arguments and return values using an external data representation, such as XDR. In order to match the semantics of object invocation, distributed object systems require remote method invocation or RMI. . RMI provides the mechanism by which the server and the client communicate and pass information back and forth. Distributed object systems finds its applications to locate remote objects, Communicate with remote objects and Load class byte codes for objects that are passed

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

as parameters or return values. In such systems, a local surrogate (stub) object manages the invocation on a remote object. The Java programming language's RMI system assumes the homogeneous environment of the Java virtual machine (JVM), and the system can therefore take advantage of the Java platform's object model whenever possible. REMOTE METHOD INVOCATION RMI provides the mechanism by which the server and the client communicate and pass information back and forth. Server creates a number of remote objects, makes references to those remote objects. The client gets a remote reference to one or more remote objects in the server and then invokes methods on them. Java provides a program called RMI Registry which executes on the server machine. The Registry maps names to object references and listens for client request on a designated port. The client looks up the remote object by its name in the servers registry and then invokes the method of server object. THE RSA ALGORITHM INTRODUCTION: The RSA scheme is a block cipher in which the plaintext and cipher text are integers between 0 and n-1 for some n.A typical size for n is 1024 bits or 309 decimal digits. The RSA scheme has since that time reigned supreme as the most widely accepted and implemented general purpose to public key encryption. DESCRIPTION: The scheme developed by Rivest, Shamir and Adleman makes use of an expression with exponentials. Plaintext is encrypted in blocks, with each block having a binary value less than some number n.That is, the block size must be less than or equal to log2(n) ; in practice, the block size is k bits, where 2k < n < 2k+1 .Encryption and decryption are of the following form, for some plaintext block M and cipher text block C: C = Me mod n M = Cd mod n = (Me) d mod n = Med mod n Both sender and receiver must know the value of n.The sender knows the value of e and only the receiver knows the value of d.Thus, this is a public key encryption algorithm with a public key of KU = {d,n}. For this algorithm to be satisfactory for public key encryption, the following requirements to be met : 1. It is possible to find the values of e, d, n such that Med = M mod n for all M < n. 2. It is relatively easy to calculate Me and Cd for all values of M < n. 3. It is infeasible to determine d given e and n. For now,we focus on the first requirement and consider the other questions later.We need to find a relationship of the form Med = M mod n

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

Given two prime numbers and q, and two integers and m, such that n=pq and 0<m<n, and arbitrary integer k, the following relationships holds: Mk (n)+1 = mk(p-1)(q-1)+1 = m mod n Where (n) is the eulers totient function, which is the number of positive integers less than n and relatively prime to n. it is shown that for p,q prime, (p,q)=(p-1)(q-1). Thus we can achieve the desired relationship if ed = k(n)+1 This is equivalent to saying: ed = 1 mod (n) d = e-1 mod (n) That is, e and d are multiplicative inverses mod (n). Note that, according to the rules of modular arithmetic, this is true only if d (and therefore e) is relatively prime to (n). Equivalently, gcd ((n),d) = 1. We are now ready to state the rsa scheme.the ingredients are the following: P, q, two prime numbers n = pq e, with gcd((n),e) = 1; 1< e < (n) d = e-1mod (n) (private, chosen) (public, calculated) (public, chosen) (private, calculated)

The private key consist of {d,n} and the public key consists of {e,n}.suppose that user a has published its public key and that user b wishes to send the message M to A. then b calculates C = Me (mod n) and transmits C. on receipt of this cipher text, user a decrypts by calculating M = Cd (mod n). It is worthwhile to summarize the justification for this algorithm. We have chosen e and d such that d = e-1 mod (n) Therefore, Ed = 1 mod (n) Therefore,ed is of the form k(n)+1 So M ed = mod n .Now C = Me mod n M = Cd mod n = (Me)d mod n = M mod n The keys were generated as follows: 1. Select two prime numbers p and q 2. Calculate n = pq 3. Calculate (n) = (p-1) (q-1)

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

4. Select e such that e is relatively prime to (n) and less than (n) 5. Determine d such that de = 1 mod (n) KEY GENERATION Before the application of the public key cryptosystem, each participant must generate a pair of keys. This involves the following tasks: 1. Determining two prime numbers, p and q 2. Selecting either e or d and calculating the other The procedure for picking a prime number is as follows: 1. Pick an odd integer n at random 2. Pick an integer a < n at random 3. Perform the probabilistic primarily test, such as Miller Rabin. If n fails the test, reject the value n and go to step 1. 4. If n has passed a sufficient number of tests, accept n; otherwise, go to step

THE SECURITY OF RSA Three possible approaches to attacking the RSA algorithm are as follows : 1. Brute force: This involves trying all possible private keys. 2. Mathematical attacks: There are several approaches, all equivalent in effect to factoring the product of two primes 3. Timing attacks: These depend on the running time of the decryption algorithm.

SCREEN SHOTS

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

Sample Code:
import javax.swing.*; import java.awt.*; import java.io.*; import java.net.*; import java.rmi.server.*; import java.rmi.*; /** * * @author Admin */ public class Source extends JFrame { /** Creates new form Source */ int i=0; char c; String str=""; String s[]; String ss[]=new String[1]; // ServerSocket serversocket; Socket socket; JLabel l1,l2,l3; JTextField t1,t2,t3; // String s[]; public Source() { initComponents(); //Container con=getContentPane(); setLocation(350,300); setSize(650,500); setTitle("Packet Marking Source");

} /** This method is called from within the constructor to * initialize the form. * WARNING: Do NOT modify this code. The content of this method is * always regenerated by the Form Editor. */

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

/* public void serverStart() { try { //serversocket=new ServerSocket(9001); //while(true) //{ // } } catch(Exception e) { e.printStackTrace(); } }*/ // <editor-fold defaultstate="collapsed" desc="Generated Code">//GEN-BEGIN:initComponents private void initComponents() { jLabel1 = new JLabel(" Packet Marking Source"); jTextField1 = new javax.swing.JTextField(); jButton1 = new javax.swing.JButton("Browse"); jTabbedPane1 = new javax.swing.JTabbedPane(); jPanel1 = new JPanel(); jTabbedPane1.addTab("Client - Machine",jPanel1) ; jLabel2 = new JLabel("Source ID"); jLabel3 = new JLabel("Destination ID"); jTextField2 = new JTextField(); jTextField3 = new JTextField(); jScrollPane1 = new JScrollPane(); jTextArea1 = new JTextArea(); jButton2 = new JButton("Send"); jButton3 = new JButton("Exit"); jPanel2 = new JPanel(); jTabbedPane1.addTab("Leaf - Router",jPanel2); jScrollPane2 =new JScrollPane(); jTextArea2 = new JTextArea(); jLabel4 = new JLabel("Marking - Probability"); jLabel5 = new JLabel("Leaf - Router"); jTextField4 = new JTextField(); jLabel6 = new JLabel("Predefined Value"); jTextField5 = new JTextField(); jButton4 = new JButton("Packet-Marking"); jButton5 = new JButton("Close");

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

l1=new JLabel("Constructed Path-1"); l2=new JLabel("Constructed Path-2"); l3=new JLabel("Constructed Path-3"); t1=new JTextField(10); t2=new JTextField(10); t3=new JTextField(10); setDefaultCloseOperation(javax.swing.WindowConstants.EXIT_ON_CLOSE); setName("Form"); // NOI18N getContentPane().setLayout(null);

jLabel1.setName("jLabel1"); // NOI18N getContentPane().add(jLabel1); jLabel1.setBounds(150, 10, 410, 40); jTextField1.setName("jTextField1"); // NOI18N jTextField1.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(java.awt.event.ActionEvent evt) { jTextField1ActionPerformed(evt); } }); getContentPane().add(jTextField1); jTextField1.setBounds(10, 80, 170, 20); jButton1.setName("jButton1"); // NOI18N jButton1.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(java.awt.event.ActionEvent evt) { jButton1ActionPerformed(evt); } }); getContentPane().add(jButton1); jButton1.setBounds(190, 80, 100, 23); jTabbedPane1.setName("jTabbedPane1"); // NOI18N jPanel1.setName("Leaf-Router"); //jPanel1.setText("Leaf-Router"); // NOI18N jPanel1.setLayout(null); jLabel2.setName("jLabel2"); // NOI18N jPanel1.add(jLabel2);

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

jLabel2.setBounds(10, 30, 100, 20); jLabel3.setName("jLabel3"); // NOI18N jPanel1.add(jLabel3); jLabel3.setBounds(10, 70, 90, 20); jPanel1.add(l1); jPanel1.add(t3); jPanel1.add(t2); jPanel1.add(t1); l1.setBounds(10,110,110,20); t1.setBounds(130,110,100,20); t2.setBounds(130,140,100,20); t3.setBounds(130,170,100,20); jPanel1.add(l2); l2.setBounds(10,140,110,20); jPanel1.add(l3); l3.setBounds(10,170,110,20); jTextField2.setName("jTextField2"); // NOI18N jPanel1.add(jTextField2); jTextField2.setBounds(130, 30, 100, 20); jTextField3.setName("jTextField3"); // NOI18N jPanel1.add(jTextField3); jTextField3.setBounds(130, 70, 100, 20); jTextField3.addFocusListener(new java.awt.event.FocusAdapter() { public void focusLost(java.awt.event.FocusEvent evt) { jTextField3FocusLost(evt); } }); jScrollPane1.setName("jScrollPane1"); // NOI18N jTextArea1.setColumns(20); jTextArea1.setRows(5); jTextArea1.setName("jTextArea1"); // NOI18N jScrollPane1.setViewportView(jTextArea1); jPanel1.add(jScrollPane1);

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

jScrollPane1.setBounds(280, 20, 180, 230); jButton2.setName("jButton2"); // NOI18N jButton2.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(java.awt.event.ActionEvent evt) { jButton2ActionPerformed(evt); } }); jPanel1.add(jButton2); jButton2.setBounds(50, 250, 80, 23); jButton3.setName("jButton3"); // NOI18N jPanel1.add(jButton3); jButton3.setBounds(150, 250, 80, 23);

jPanel2.setName("Client-Machine"); //jPanel2.setText("Client-Machine");// NOI18N jPanel2.setLayout(null); jScrollPane2.setName("jScrollPane2"); // NOI18N jTextArea2.setColumns(20); jTextArea2.setRows(5); jTextArea2.setName("jTextArea2"); // NOI18N jScrollPane2.setViewportView(jTextArea2); jPanel2.add(jScrollPane2); jScrollPane2.setBounds(230, 30, 250, 280); jLabel4.setName("jLabel4"); // NOI18N jPanel2.add(jLabel4); jLabel4.setBounds(10, 40, 110, 20); jLabel5.setName("jLabel5"); // NOI18N jPanel2.add(jLabel5); jLabel5.setBounds(210, 10, 270, 17); jTextField4.setName("jTextField4"); // NOI18N

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

jPanel2.add(jTextField4); jTextField4.setBounds(120, 40, 90, 20); jLabel6.setName("jLabel6"); // NOI18N jPanel2.add(jLabel6); jLabel6.setBounds(10, 90, 100, 14); jTextField5.setName("jTextField5"); // NOI18N jTextField5.addFocusListener(new java.awt.event.FocusAdapter() { public void focusGained(java.awt.event.FocusEvent evt) { jTextField5FocusGained(evt); } }); jPanel2.add(jTextField5); jTextField5.setBounds(120, 90, 90, 20); jButton4.setName("jButton4"); // NOI18N jButton4.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(java.awt.event.ActionEvent evt) { jButton4ActionPerformed(evt); } }); jPanel2.add(jButton4); jButton4.setBounds(10, 170, 105, 23); jButton5.setName("jButton5"); // NOI18N jPanel2.add(jButton5); jButton5.setBounds(120, 170, 100, 23);

getContentPane().add(jTabbedPane1); jTabbedPane1.setBounds(20, 110, 500, 340); }// </editor-fold>//GEN-END:initComponents private void jTextField1ActionPerformed(java.awt.event.ActionEvent evt) {//GENFIRST:event_jTextField1ActionPerformed // TODO add your handling code here:

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

}//GEN-LAST:event_jTextField1ActionPerformed private void jButton1ActionPerformed(java.awt.event.ActionEvent evt) {//GENFIRST:event_jButton1ActionPerformed // TODO add your handling code here: try { FileDialog fd=new FileDialog(this,"open",FileDialog.LOAD); fd.show(); jTextField1.setText(fd.getDirectory()+fd.getFile()); FileInputStream fis=new FileInputStream(fd.getDirectory()+fd.getFile()); while((i=fis.read())!=-1) { c=(char)i; str+=Character.toString(c); } int len=str.length(); int packets=len/48; int rem=len%48; packets++; String source=jTextField2.getText(); String dest=jTextField3.getText(); jTextArea1.append("\n\nSource Address::"+source+"\n\n"); jTextArea1.append("Destiniation Address::"+dest+"\n\n"); jTextArea1.append("Selected File Path "+fd.getDirectory()+fd.getFile()+"\n\n"); jTextArea1.append("Total Length::"+len+"\n\n"); jTextArea1.append("Total Packets::"+packets+"\n\n");

// System.out.print(str); } catch(Exception e) { e.printStackTrace(); } }//GEN-LAST:event_jButton1ActionPerformed private void jTextField5FocusGained(java.awt.event.FocusEvent evt) {//GENFIRST:event_jTextField5FocusGained // TODO add your handling code here: int one=Integer.parseInt(jTextField4.getText()); one+=4; int val=one;

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

jTextField5.setText (""+val); }//GEN-LAST:event_jTextField5FocusGained

private void jTextField3FocusLost(java.awt.event.FocusEvent evt) {//GENFIRST:event_jTextField5FocusGained // TODO add your handling code here: if((jTextField2.getText()).equals("Client-1") && (jTextField3.getText()).equals("Client-4")) { t1.setText("R-101"); t1.setEditable(false); t2.setText("R-102"); t2.setEditable(false); t3.setText("R-103"); t3.setEditable(false); } else { JOptionPane.showMessageDialog(this,"Invalid Path"); } } private void jButton4ActionPerformed(java.awt.event.ActionEvent evt) {//GENFIRST:event_jButton4ActionPerformed // TODO add your handling code here: if((t1.getText()).equals("R-101")) { try { int inc=1; String source=jTextField2.getText(); String dest=jTextField3.getText(); String x=jTextField4.getText(); int xx=Integer.parseInt(x); int pm=Integer.parseInt(jTextField5.getText()); int x1=Integer.parseInt(x.substring(0, 2)); String pktcnt="Packet-"; //JOptionPane.showConfirmDialog(this,xx); //socket=serversocket.accept();

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

socket=new Socket("Spiro9",9001); DataOutputStream dos=new DataOutputStream(socket.getOutputStream()); int gh=s.length+1; dos.writeInt(gh); for(int h=0;h<s.length;h++) { //JOptionPane.showMessageDialog(this,s.length); double assign= (Math.random()*9)+xx; int ch=(int)(assign); //int h1+=h; String pcnt=pktcnt+inc; Tpn t =(Tpn)Naming.lookup("//192.0.0.56/Server"); t.pktEncode(pcnt,ch); if(ch<pm) { String str=Integer.toBinaryString(ch); //JOptionPane.showConfirmDialog(this,str); String app="\n\n@"+str+"@\nSA:"+source+"\nPacket-"+inc+"::$"+s[h]+"$\nDA:"+dest; jTextArea2.append(app); System.out.println(app); //jTextArea2.append("\n\nSA:"+source+"\nPacket-"+inc+"::"+str+""+s[h]+"\nDA:"+dest); // socket=new Socket("localhost",9001); //DataOutputStream dos=new DataOutputStream(socket.getOutputStream()); dos.writeUTF(app); inc++; Thread.sleep(1000); } else { String str=Integer.toBinaryString(ch); //.println("SA:"+source+"Packet-"+inc+""+s[h]+"::"+str+"\n\n"); String a="\n\nSA:"+source+"\nPacket-"+inc+"::$"+s[h]+"$::\nDA:"+dest+"\n@"+str+"@";

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

jTextArea2.append(a); //socket=new Socket("localhost",9001); // DataOutputStream dos=new DataOutputStream(socket.getOutputStream()); dos.writeUTF(a); inc++; Thread.sleep(1000); } } double assign2=(Math.random()*9)+31; int ch1=(int)(assign2); String pcnt=pktcnt+inc; Tpn t =(Tpn)Naming.lookup("//192.0.0.56/Server"); t.pktEncode1(pcnt,ch1); String str1=Integer.toBinaryString(ch1); //JOptionPane.showMessageDialog(this,ch1); if(ch1<pm) { String ap="\n\n@"+str1+"@\nSA:"+source+"\nPacket-"+inc+"::$"+ss[0]+"$\nDA:"+dest; jTextArea2.append(ap); // socket=new Socket("localhost",9001); // DataOutputStream dos=new DataOutputStream(socket.getOutputStream()); dos.writeUTF(ap); System.out.println(ap); Thread.sleep(1000); } else { String ap="\n\nSA:"+source+"\nPacket-"+inc+"$"+ss[0]+"$\nDA:"+dest+"::@"+str1+"@"; jTextArea2.append(ap); // socket=new Socket("localhost",9001); //DataOutputStream dos=new DataOutputStream(socket.getOutputStream()); dos.writeUTF(ap); System.out.println(ap); Thread.sleep(1000); }

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

} catch(Exception e) { e.printStackTrace(); } }

}//GEN-LAST:event_jButton4ActionPerformed /** * @param args the command line arguments */ public static void main(String args[]) { new Source().setVisible(true);

} // Variables declaration - do not modify//GEN-BEGIN:variables private javax.swing.JButton jButton1; private javax.swing.JButton jButton2; private javax.swing.JButton jButton3; private javax.swing.JButton jButton4; private javax.swing.JButton jButton5; private javax.swing.JLabel jLabel1; private javax.swing.JLabel jLabel2; private javax.swing.JLabel jLabel3; private javax.swing.JLabel jLabel4; private javax.swing.JLabel jLabel5; private javax.swing.JLabel jLabel6; private javax.swing.JPanel jPanel1; private javax.swing.JPanel jPanel2; private javax.swing.JScrollPane jScrollPane1; private javax.swing.JScrollPane jScrollPane2; private javax.swing.JTabbedPane jTabbedPane1; private javax.swing.JTextArea jTextArea1; private javax.swing.JTextArea jTextArea2; private javax.swing.JTextField jTextField1; private javax.swing.JTextField jTextField2;

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

private javax.swing.JTextField jTextField3; private javax.swing.JTextField jTextField4; private javax.swing.JTextField jTextField5; // End of variables declaration//GEN-END:variables

Testing:

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

SYSTEM IMPLEMENTATION Implementation is the most crucial stage in achieving a successful system and giving the users confidence that the new system is workable and effective. Implementation of a modified application to replace an existing one. This type of conversation is relatively easy to handle, provide there are no major changes in the system. Each program is tested individually at the time of development using the data and has verified that this program linked together in the way specified in the programs specification, the computer system and its environment is tested to the satisfaction of the user. The system that has been developed is accepted and proved to be satisfactory for the user. And so the system is going to be implemented very soon. A simple operating procedure is included so that the user can understand the different functions clearly and quickly. Initially as a first step the executable form of the application is to be created and loaded in the common server machine which is accessible to all the user and the server is to be connected to a network. The final stage is to document the entire system which provides components and the operating procedures of the system. SCOPE FOR FUTURE DEVELOPMENT Every application has its own merits and demerits. The project has covered almost all the requirements. Further requirements and improvements can easily be done since the coding is mainly structured or modular in nature. Changing the existing modules or adding new modules can append improvements. Further enhancements can be made to the application, so that the web site functions very attractive and useful manner than the present one.

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

CONCLUSION

In this paper, we have studied the problem of combating Internet worms. To that end, we have developed a branching process model to characterize the propagation of Internet worms. Unlike deterministic epidemic models studied in the literature, this model allows us to characterize the early phase of worm propagation. Using the branching process model, we are able to provide a precise bound M on the total number of scans that ensure that the worm will eventually die out. Further, from our model, we also obtain the probability that the total number of hosts that the worm infects is below a certain level, as a function of the scan limit. The insights gained from analyzing this model also allow us to develop an effective and automatic worm containment strategy that does not let the worm propagate beyond the early stages of infection. Our strategy can effectively contain both fast scan worms and slow scan worms without knowing the worm signature in advance or needing to explicitly detect the worm. We show via simulations and real trace data that the containment strategy is both effective and nonintrusive.

BIBLIOGRAPHY

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

A PRECISE TERMINATION CONDITION OF THE PROBABIISTIC PACKET MARKING ALGORITHM

[ Core Java 2 Volume I Fundamentals 7th Edition Pearson Education Sun Microsystems Core Java 2 Volume II Advanced Pearson Education Sun Microsystems Head First Servlets & JSP OReilly SPD JAVA 2: The Complete Reference SPD Effective Java Programming Language Guide Pearson Education Sun Microsystems Java Networking Best Practices OReilly SPD Pure JFC Swing OReilly SPD . Cay S. Hortsman Gary Cornell Cay S. Hortsman Gary Cornell Eric Freeman Elisabeth Freeman Hert Schildt, Herbert Schildt Joshua Bloch George Reese Sathyaraj Pantham Sam Griffith

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

Vous aimerez peut-être aussi