Hyper Ethernet

A PROJECT REPORT ON
HYPER ETHERNET
PROJECT MEMBERS
BHUVAN MITAL IMRAN SADAT PARAG SETHI INTERNAL PROJECT GUIDE PROF. DEVENDRA S. THAKORE EXTERNAL PROJECT GUIDE MR. RANDHIR DUGGAL CALSOFT PVT. LTD.
BHARATI VIDYAPEETH DEEMED UNIVERSITY COLLEGE OF ENGINEERING, PUNE-411043
CERTIFICATE
This is to certify that Mr. BHUVAN MITAL Mr. IMRAN SADAT Mr. PARAG SETHI
Have successfully completed and submitted their Project report on
HYPER ETHERNET
in partial fulfillment of the Graduate Programme in Bachelor of Engineering in Computer Engineering during the academic year 2004-2005.
Prof. Devendra S. Thakore (Internal Project Guide)
Prof. Suhas H. Patil (Head of Department)
BHARATI VIDYAPEETH DEEMED UNIVERSITY COLLEGE OF ENGINEERING, PUNE-411043
ACKNOWLEDGEMENT
We are greatly indebted to all those scientists, researchers, scholars and Linux developers for their relentless effort and without whose great work this thoroughly research-based endeavor would not have been possible. We would like to express our deep sense of gratitude and indebtedness to our project guide Prof. Devendra S. Thakore whose invaluable guidance and unfailing inspiration helped us in our endeavor. We are especially thankful to Mr. Randhir Duggal, External Project Guide, Calsoft Pvt. Ltd., for his invaluable and timely suggestions without which this endeavor would have been a distant dream. We would like to extend our special thanks to Prof. Suhas H. Patil, Head of Department, Department of Computer Engineering and Information Technology, and all the faculty members of the Computer Department for their reassuring support throughout the project.
Project Team
CONTENTS
1 INTRODUCTION ............................................................................................... 1 1.1 Introduction ................................................................................................... 1 1.2 Sponsor Company Profile ............................................................................. 1 2 REQUIREMENT ANALYSIS ............................................................................ 4 2.1 Problem Recognition .................................................................................... 4 2.2 Evaluation and Synthesis .............................................................................. 4 2.3 Software Requirement Specification ............................................................ 5 3 PROJECT PLANNING ....................................................................................... 8 3.1 Scope ............................................................................................................. 8 3.2 Cost Estimation ............................................................................................. 8 3.3 Team Structure ............................................................................................ 12 4 ACTIVITY PLAN ............................................................................................. 13 4.1 Scheduling................................................................................................... 13 4.2 Gantt Chart .................................................................................................. 15 5 RISK MITIGATION, MONITORING AND MANAGEMENT PLAN ........... 20 5.1 Introduction ................................................................................................. 20 5.2 Risk Identification, Analysis and Prioritization .......................................... 21 5.3 RMMM Plan ............................................................................................... 22 6 SOFTWARE QUALITY ASSURANCE .......................................................... 25 6.1 Definition of SQA ....................................................................................... 25 6.2 SQA Activities ............................................................................................ 25 6.3 Documentation ............................................................................................ 26 6.4 Document Standards ................................................................................... 26 6.5 Coding Standards ........................................................................................ 26 6.6 Review Guidelines ...................................................................................... 26 6.7 Metrics ........................................................................................................ 27 6.8 Quality control through testing ................................................................... 27 6.9 Software Reliability .................................................................................... 27 7 SYSTEM DESIGN ............................................................................................ 29 7.1 Introduction ................................................................................................. 29 7.2 Design goals ................................................................................................ 29
BHARATI VIDYAPEETH DEEMED UNIVERSITY COLLEGE OF ENGINEERING
7.3 Analysis....................................................................................................... 30 7.4 Modeling ..................................................................................................... 31 7.5 Development method .................................................................................. 44 8 TEST PROCEDURE ......................................................................................... 56 8.1 Introduction ................................................................................................. 56 8.2 Goals and Objectives .................................................................................. 56 8.3 Testing Strategies ........................................................................................ 57 8.4 Comparison of Hyper Ethernet with TCP/IP .............................................. 63 9 APPLICATIONS ............................................................................................... 66 10 FUTURE .......................................................................................................... 68 10.1 Overview ................................................................................................... 68 10.2 Limitations ................................................................................................ 68 10.3 Enhancements ........................................................................................... 68 APPENDIX A ....................................................................................................... 70 Whats a socket? ............................................................................................... 70 socket() .............................................................................................................. 71 bind() ................................................................................................................. 71 connect() ........................................................................................................... 72 listen() ............................................................................................................... 73 accept() .............................................................................................................. 74 send() and recv() ............................................................................................... 75 close() ................................................................................................................ 76 GLOSSARY ......................................................................................................... 77 REFERENCES ..................................................................................................... 79
Hyper Ethernet Protocol
1 INTRODUCTION
1.1 Introduction
Hyper Ethernet is a reliable, adaptive, connection oriented, high speed bulk data transfer protocol over Ethernet with its application in Local Area Networks (LANs). The high speed is achieved by implementing a completely new protocol independent of existing protocols like IP, AppleTalk, etc. The protocol can be used to communicate between two computers on the same LAN segment only. The protocol has been currently implemented in Linux as a reloadable module. Current applications working on other protocols through the use of Linux sockets can be easily adapted to use our protocol with few or no modifications. Multiple applications can communicate over the protocol at the same time. Our protocol, Hyper Ethernet proves to be faster than the current implementation of TCP/IP considering the special features in its implementation. Hyper Ethernet involves a 6 byte header compared to the 64 bytes of TCP/IP (with padding) thereby involving less overheads, something which TCP/IP suffers from. Hyper Ethernet consumes less number of CPU cycles thereby making it fast. Hyper Ethernet does away with Checksum(for error handling) in its layer by relying on the lower layer Ethernet which already has a Frame Check Sequence(FCS) implementation for Checksum, thereby further improving its speed of transmission. Hyper Ethernet involves a Selective Negative Acknowledgement scheme for handling ACKs with NACKs grouped together being sent after a certain number of packets and not after every packet further enhancing the speed of transmission.
1.2 Sponsor Company Profile

1.2.1 Introduction
CalSoft is a premier software-consulting house providing onsite and offshore development solutions in storage and systems to a rich medley of Fortune 500 as well as high profile startup companies. CalSoft has become a leading consulting organization by virtue of its service profile, adaptable development models, robust
Hyper Ethernet Protocol outsourcing frameworks, and the value proposition it provides in terms of technology, business-cost and services to its clients. The company has a wide expertise in the whole cross-section of storage and systems software starting from operating system internals to cutting edge applications. CalSoft primarily works for ISVs and OEMs, helping them develop key parts of their product offerings. CalSoft is a company promoted by highly qualified and experienced software professionals after working at senior software development positions at leading U.S. computer software companies. The company has the ability to provide solutions starting from nothing but a simple wish list to an end product of the highest quality and thus has earned recognition for pioneering work in providing critical and competitive value to its clients.
1.2.2 Key Areas

CalSoft's core areas are, Storage Cluster File Systems Network File Systems SCSI and iSCSI Fiber Channel (FC) Kernel Internals Device Drivers TCP/IP Stack Internals, TCP/IP Offloading Embedded Systems LVM Migration
Hyper Ethernet Protocol SNMP Networking and Network Management
1.2.3 Components
CalSoft has developed the following cutting edge components based on its vast experience in storage and systems. Apart from pure consulting and software development services, CalSoft also provides consulting services bundled with these components. DirectNFS DirectCIFS NextGenNAS Veritas LVM (VxVM) migrator SCSI test suite WinFSX
2 REQUIREMENT ANALYSIS
2.1 Problem Recognition
To design and implement a reliable, adaptive, connection oriented, high speed bulk data transfer protocol over Ethernet.
2.1.1 Objectives:
1. The Protocol should have minimum overhead 2. The Protocol should involve high-speed data transfer 3. The Protocol should be adaptive 4. The Protocol should provide a transparent interface to the user 5. Easy Migration of existing applications working on other protocols 6. To adapt the existing flow-control mechanism to low-latency LANs
2.2 Evaluation and Synthesis

HYPER ETHERNET MECHANISM
Network Applications
User Kernel
BSD Sockets Socket Interface
Protocol Layers
Hyper Ethernet Protocol ARP
Network Devices Ethernet

The task of protocol design has been divided into the following subtasks:
Hyper Ethernet Protocol 1. The Socket Handler design and implementation : This module of the protocol handles the requests made by an application at the user layer, meant for a particular socket. This interacts with the underlying protocol handler. 2. The Protocol Handler design and implementation: The protocol handler sits on top of the device driver layer and handles the requests passed through the socket handler residing above the protocol handler. It resides at the kernel level and all the calls meant for HyperEthernet protocol are routed through the protocol handler down to the physical layer (where machine to machine flow of data takes place) or from the physical layer up to the socket handler. 3. Integrating the protocol into the existing Linux Kernel : This is the most challenging task of HyperEthernet implementation. There are 2 options for successfully integrating the protocol in the Linux Kernel space. One is to add the corresponding protocol entries in unistd.h and recompile the entire kernel. The other method is to implement the protocol as an insertable module and insert into the kernel. The latter seems to be an obvious choice since buggy modules can make the user recompile the entire kernel multiple number of times, thereby consuming a lot of time, if the first method is used.
2.3 Software Requirement Specification

2.3.1 Introduction
1. System Reference:- The HyperEthernet software is to be developed as a stand alone module. It is platform dependent and is to be developed on a machine running Linux 2.4. The protocol deals with handling the requests from the user layer. 2. Overall Description:- HyperEthernet protocol is to be built in C language using socket programming concepts by using the existing kernel API of Linux. The aim of the protocol is to provide alternative means to existing protocols for handling reliable, adaptive, connection oriented, high speed bulk data. The protocol also aims to do away with the shortcomings and overheads associated with the existing technologies.
Hyper Ethernet Protocol 3. Project Constraints:- The protocol will only handle data transfer requests for LAN segments. The protocol will not support routing because it will not be built on top of IP.
2.3.2 Information Description

1. Information Content Representation:- The file to be transferred should be divided into equal size payloads corresponding to the MTU overheads. The first 6 bytes of each payload designate the payload header which should be designed specifically for HyperEthernet protocol. The data requests should be routed through HyperEthernet protocol and the data transfer should take place from the server machine to the client machine by making the appropriate kernel API calls. 2. Information Flow Representation:- UML diagrams can be used to show the information flow.
2.3.3 Functional Partitioning and Functional Description

The protocol will be divided into a main module and many more sub modules. Module Initializer:- The module initializer registers the protocol and the socket handler with the kernel. HyperEthernet Input:- This module takes care of the data reception from the NIC and buffers the input for further processing. HyperEthernet Output:- The socket handler and other functions which need to send data onto the network use this module. This module sends data after adding the appropriate header if required onto the NIC. Socket Handler:- The socket handler handles all the user level communication. It takes care of connection initialization, data transmission, reception, connection closing etc.
2.3.4 Control Description

1. The user makes the desired function call at the application/user layer.
Hyper Ethernet Protocol 2. The call goes to a kernel level socket handler, which looks up the socket type and forwards the call to our socket handler for further processing. 3. The function is carried out by doing the needful and making appropriate calls. 4. While transferring data from the kernel to the NIC the HyperEthernet output module is invoked whereas while transferring data from NIC to kernel the HyperEthernet input module is called.
2.3.5 Behavioral Description

Socket States: CONNECTED, UNCONNECTED Connection States: CONNECTED, CLOSE, SYN_SENT, FIN_WAIT1, FIN_WAIT2, SYN_RCVD Events and Actions: Send, Recv, Accept, Close, Create, Listen, Connect, Bind, Release.
2.3.6 Validation Criteria

Performance Bounds: The protocol is to work on standalone PCs in a conducive LAN environment. The user is assumed to be well versed with the Linux operating environment and also with the basic constructs of socket programming. Functions of Test: The unit testing will be performed for individual modules as well as Integration and Validation testing of the entire software will have to be done. Expected Protocol Response: The response must be fast and reliable.
3 PROJECT PLANNING
3.1 Scope
This document proposes the project plan for the project HyperEthernet. A project plan is absolutely essential for successful completion of such a long term undertaking. This plan describes the various aspects of the project and the approach taken to realize them. Software scope describes the data and control to be processed, function, performance, constraints, interfaces, and reliability. Functions described in the statement of scope are evaluated and in some cases refined to provide more detail prior to the beginning of estimation. Because both costs and schedule estimates are functionally oriented, some degree of decomposition is often useful. Performance consideration encompasses processing and response time requirements. Constraints identify limits placed on the software by external hardware, available memory or other existing systems.
3.2 Cost Estimation

3.2.1 Cost Benefit Analysis
a. Procurement Cost i. Cost of software: none (Open Source) b. Startup Cost i. Cost of Operating System: None (Open Source) ii. Cost of Equipment Installation Standalone system: Rs. 12,000 and above depending upon its configuration. c. Project related Costs
Hyper Ethernet Protocol i. Cost of software modification to fit local system: Cannot be determined at this instant. ii. Cost of Documentation: Cannot be determined at this instant. d. Ongoing Cost i. System Maintenance Cost: This includes servicing cost of the PC which is Rs. 500/- per PC per 6 months. ii. Rental Cost: This includes ISP charges and telephone bills for internet access which is Rs. 20/- per hour.
3.2.2 Software Cost Estimation

We are following the Constructive Cost Model (COCOMO) for estimating the effort required in completing the project. The initial effort (Ei) in man months is calculated using the equation Ei = a * (KLOC)b where a and b are constants depending whether the project belongs to organic, semidetached or embedded category. The values are as follows:System Organic Semidetached Embedded A 3.2 3.0 2.8 b 1.05 1.12 1.20
Our system belongs to the Semidetached category. In the Organic mode, relatively small software teams develop software in a highly familiar, in-house environment. Most people connected with the project have extensive experience in working with related systems within the organization, and have a thorough understanding of how the system under development will contribute to the organizations objectives.
Hyper Ethernet Protocol The Semidetached mode of software development represents an intermediate stage between the organic and embedded modes. "Intermediate" may mean either of two things: An intermediate level of project characteristic. A mixture of the organic and embedded mode characteristics. The major distinguishing factor of an Embedded-mode software project is a need to operate within tight constraints. The product must operate within (is embedded in) a strongly coupled complex of hardware, software, regulations, and operational procedures, such as an electronic funds transfer system or an air traffic control system. Therefore, our project falling into the semidetached category, a = 3.0 and b = 1.12 There are fifteen cost drivers which may either increase or decrease the final effort depending upon the rating. The effort adjustment factor is calculated by multiplying the various cost driver multipliers. The final effort estimate, E, is obtained by multiplying the initial estimate by the EAF. E = EAF * Ei Cost Drivers Software Reliability Requirement Product Complexity Execution Time Constraint Computer Turnaround Time Rating High High High Nominal Multiplier 1.10 1.25 1.15 1.00
10
Cost Drivers Operating Environment Experience Programmer Capability Programming Language Experience Modern Programming Practice Use of Software Tools Development Schedule
Rating High High High Nominal Nominal Nominal
Multiplier 1.20 0.90 0.90 1.00 1.00 1.05
The table above gives the rating and multipliers for the various cost drivers in the project. Thus the Effort Adjustment Factor EAF = 1.10 * 1.25 * 1.15 * 1.00 * 1.20 * 0.90 * 0.90 * 1.00 * 1.00 * 1.05 EAF = 1.61 The estimated lines of code for the various modules are as follows: Module Module Initializer Socket Handler HyperEthernet Input HyperEthernet Output Miscellaneous KLOC 0.5 1.1 0.8 0.6 1
11
3.3 Team Structure

Following are the group members of the project 1. Imran Sadat 2. Parag Sethi 3. Bhuvan Mital The have been supported to a great extent by the External guide Mr. Randhir Duggal of Calsoft Inc., Pune and the Internal guide, Prof. Devendra S. Thakore, Department of Computer Engineering and Information Technology.
12
4 ACTIVITY PLAN
4.1 Scheduling
Tasks 1 1.1 1.2 1.3 1.4 2 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 3 3.1 3.2 3.3 3.4 4 4.1 4.2 4.3 4.4 4.5 Requirements Gathering Study of protocol basic Study of Operating System basics Research on previous efforts on protocol design Study of feasible platform for implementation Requirement Analysis Problem Recognition Feasibility Study Evaluation and Synthesis Software Requirement Specification Task Management System Description Technical Analysis Review of Strategy Learning new Technologies Study of Socket Programming Study of C Programming on Linux Platform Study of Kernel Programming in Linux Study of OS Concepts Implementation System and Data design Outline of HyperEthernet Protocol HyperEthernet Frame Design Design of Implementation Functions UML Diagrams GUI Designing Days 22 days 7 days 7 days 7 days 3 days 39 days 2 days 10 days 8 days 1 day 2 days 7 days 7 days 2 days 30 days 5 days 3 days 17 days 5 days 15 days 6 days 3 days 3 days 2 days 1 day Start Date 05/07/2004 05/07/2004 12/07/2004 21/07/2004 30/07/2004 04/08/2004 04/08/2004 06/08/2004 20/08/2004 01/09/2004 02/09/2004 06/09/2004 15/09/2004 24/09/2004 28/09/2004 28/09/2004 05/10/2004 08/10/2004 04/01/2005 11/01/2005 11/01/2005 19/01/2005 24/01/2005 27/01/2005 31/01/2005 End Date 03/08/2004 13/07/2004 20/07/2004 29/07/2004 03/08/2004 27/09/2004 05/08/2004 19/08/2004 31/08/2004 01/09/2004 03/09/2004 14/09/2004 23/09/2004 27/09/2004 10/01/2005 04/10/2004 07/10/2004 03/01/2005 10/01/2005 31/01/2005 18/01/2005 21/01/2005 26/01/2005 28/01/2005 31/01/2005
13
Tasks 5 6 6.1 6.2 6.3 7 7.1 7.2 7.3 8 9 10 10.1 10.2 11 Modularization of System Implementation Protocol Implementation : Phase I Skeletal Implementation of Socket Handler Skeletal Implementation Protocol Handler Implementation Review of Work Protocol Implementation : Phase II Final Implementation of Socket Handler Final Implementation of Protocol Handler Review of Work GUI Implementation Integration of modules Protocol Testing Validation Testing Integration Testing Documentation and Manual Design
Days 2 days 7 days 3 days 3 days 1 day 26 days 12 days 12 days 2 days 7 days 2 days 10 days 5 days 5 days 4 days
Start Date 01/02/2005 03/02/2005 03/02/2005 08/02/2005 11/02/2005 14/02/2005 14/02/2005 02/03/2005 18/03/2005 22/03/2005 31/03/2005 04/04/2005 04/04/2005 11/04/2005 18/04/2005
End Date 02/02/2005 11/02/2005 07/02/2005 10/02/2005 11/02/2005 21/03/2005 01/03/2005 17/03/2005 21/03/2005 30/03/2005 01/04/2005 15/04/2005 08/04/2005 15/04/2005 21/04/2005
14
4.2 Gantt Chart
15
16
17
18
19
5 RISK
MITIGATION,
MONITORING
AND
MANAGEMENT PLAN
5.1 Introduction
Risk analysis and management are a series of steps that help and software team to understand and manage uncertainty. Many problems can plague a project. A Risk is a potential problem it might happen, it might not. But, regardless of the outcome, its a good idea to identify it, assess its probability of occurrence, estimate its impact and establish a contingency plan should the problem actually occur. Software as well as hardware is a difficult undertaking. Lots of things can go wrong. It is for this reason, that being prepared understanding the risks and taking proactive measures to avoid or manage them is a key element of good project management. An effective risk management strategy must consider 3 issues: Risk Avoidance Risk Monitoring Risk Management and Contingency Planning
Risk Management and Contingency Planning assumes that mitigation efforts have failed and that the risk has become a reality. It is important to note that RMMM steps incur additional project costs. Basically the risks are to be updated in consultation with the project members. Every time a risk is resolved or has less probability of occurring than earlier, the document needs to be revised. We began with nearly all the risks having a catastrophic impact. But slowly as we progressed in the right direction our higher impact risks have obtained lower impact status.
20
5.1.1 Risk Identification

Recognizing what can go wrong is the first step called Risk Identification. Risk Mitigation is done before the actual start of the project. It is a proactive approach towards the risk. To mitigate the risk, project management must develop a strategy for reducing the turnover.
5.1.2 Risk Analysis

Next each risk is analyzed to determine the likelihood that it will occur and the damage it will do if it occurs. As the project proceeds, risk monitoring activities commence. The project manager monitors factors that may provide an indication of whether the risk is becoming less or more likely. In addition to the monitoring events, the project manager should also monitor the effectiveness of risk mitigation steps.
5.1.3 Risk Prioritization

Once the information Of Risk Identification and Risk Analysis is established, risks are ranked, by a probability and impact.
5.1.4 Risk Control

Finally, a plan is developed to manage those risks with high probability and high impact.
5.2 Risk Identification, Analysis and Prioritization

Risks 1. Overly Optimistic Schedule 2. Wrong Estimate of size and efforts 3. Requirements keep on changing 4. Error prone modules require more Category SC PS PE SC Probability 70% 65% 60% 65% Impact 1 1 2 3
21
Risks testing and implementation work 5. Cost of Project could be very high 6. Insufficient knowledge of
Category
Probability
Impact
CR TE
30% 55%
2 1
technologies required 7. Availability of expert guidance in the required field 8. Project may not finish on time SC 25% 2 SU 10% 1
Categories: SC Schedule Risk, PS Project Size Risk, PE Performance Risk, CR Cost Risk, TE Technology Risk, SU Support Risk. Impact Values: 1 Catastrophic, 2 Critical, 3 Marginal, 4 Negligible
5.3 RMMM Plan

A plan can now be developed to manage those risks with high probability and high impact. After risks have been categorized, prioritized and their probability of occurrence determined, action should be taken to control these risks, which involve mitigation and monitoring these risks. The key steps for risk control are as follows:1. Risk: Overly Optimistic Schedule Risk Mitigation Use available Estimation tools to find the rough schedule estimate. Have best case, worst case and average case times on each project activity. This would give an idea on the confidence factor on estimates.
22
Hyper Ethernet Protocol Risk Monitoring and Management Keep track of schedule steps. Modify the estimates as the project develops and it becomes clearer as the development phases progress. 2. Risk: Wrong estimate of size and efforts Risk Mitigation Quantify the size and schedule using ranges, so that the schedule estimate is not treated as very precise and gives sufficient padding for schedule estimates. Efforts of team members should be kept track of so that they are not overly burdened. Risk Monitoring and Management Keep track of project by module size and complexity. Keep track of number of man hours spent. Modify the estimates as the project develops and it becomes clearer as the development phases progress. 3. Risk: Requirements keep on changing Risk Mitigation Study of project in detail and coming up with a comprehensive and detail list of requirements. Understand the problem definition precisely so that there is smaller probability of changes later.
23
Hyper Ethernet Protocol Risk Monitoring and Management Keep track of progress and check if something had been forgotten when the requirements were laid down. Incase of change of requirements; follow a reverse engineering approach so that the change reflects in all the work performed till date. 4. Risk: Error prone modules require more testing and implementation work Risk Mitigation Involve all team members in a joint assignment to nurture the understanding among team members. Discuss each others problems and try to solve them through mutual consensus. Risk Monitoring and Management Perform regular reviews to check if the productivity is being affected.
24
6 SOFTWARE QUALITY ASSURANCE

6.1 Definition of SQA
Software Quality Assurance (SQA) is defined as a planned and systematic approach to the evaluation of the quality of and adherence to software product standards, processes, and procedures. SQA includes the process of assuring that standards and procedures are established and are followed throughout the software acquisition life cycle. Compliance with agreed-upon standards and procedures is evaluated through process monitoring, product evaluation, and audits. Software development and control processes should include quality assurance approval points, where an SQA evaluation of the product may be done in relation to the applicable standards.
6.2 SQA Activities

The software quality assurance task comprises of a variety of tasks that need to be undertaken to ensure the quality of the product, viz. the Hyper-Ethernet protocol. The various tasks are as follows: 1. Preparing an SQA plan for the project: This plan is developed during the project planning and is reviewed by all interested parties (Calsoft Pvt. Limited). The plan identifies the following: Evaluations to be performed Reviews of the modules used in the protocol Protocol standards that are applicable to Hyper-Ethernet Error reporting and tracking procedure Amount of feedback provided by the software sponsors
25
Hyper Ethernet Protocol 2. Reviewing software engineering activities to verify compliance with the defined software process 3.Auditing of the work by the project sponsors to verify compliance with those defined as part of the software process.
6.3 Documentation
As a part of ensuring software quality, following documents should be prepared: System Requirements Specification System Design Specification Activity Plan Project Plan Risk Mitigation, Monitoring and Management Plan Standards, Practices and Conventions
6.4 Document Standards

All documents will be written in Microsoft Word in Font Times New Roman and size 12. The heading will be size 14 or bold 14 with chapter headings at size ranging 16. The documents will be fully justified.
6.5 Coding Standards

The code is C code written in KWrite in Linux. The code is based by and large on kernel level socket programming.
6.6 Review Guidelines

All the work done will be properly documented and kept track of. A project journal will be maintained. Weekly reports to the Project Guide Prof. Devendra S. Thakore will be submitted about the status of the project.
26
Hyper Ethernet Protocol Reports will be submitted to the external project guide Mr. Randhir Duggal, Calsoft Pvt. Ltd.
6.7 Metrics
The following metrics will be used to ensure software quality: Team meeting every weekend to discuss progress Meeting with external guide, Mr. Randhir Duggal, every fortnight to discuss the progress till date, discussing changes for improvement and decide the future course of action Logging of daily work product by every team member. Diagrammatic representation of concepts in Rational Rose.
6.8 Quality control through testing

Test cases will be designed to test the hardware thoroughly. Each test consists of a setup which describes the requirements for performing the test : Test which describes the exact procedure to be carried out, Expected Results which indicate the correct results of the test while possible defects indicate the errors which the test might expose.
6.9 Software Reliability

Software reliability is defined in statistical terms as the probability of failure free operation of a computer program in a specified environment for a specified time. Software reliability is often measured by the "mean time between failure"(MTBF), but it can also be measured by estimating the number of errors left in the software that are of high criticality - that is, that prevent the software or some major function from operating. Correctness can be measured by stating the percentage of errors within a program that must be removed. This implies the ability to estimate the number of errors in the software. One industry guideline is to expect approximately 7 errors per 1000 Source Lines of Code. This estimate is helpful in an overall estimate of the
27
Hyper Ethernet Protocol number of errors, but does not take into account the rate at which errors are found. If the rate of finding errors has not started to flatten out, the projection is that if the software is released, the risk to reliability is high that it will not meet the qualifications. MTBF = MTTF + MTTR where MTTF and MTTR are meat-time-to-failure and mean-time-to-repair respectively. MTBF = = 0 because HyperEthernet exhibits 100 % reliability. 0+0
28
7 SYSTEM DESIGN
7.1 Introduction
It is important to have a blue print of the house before we start building it. In the same way it is important to have a design of the final product we are going to build. Design is the meaningful representation of something that is to be built. Before starting the actual coding part of the project it is important to have a design which represents exactly what the final product is intended to perform. Design begins with the requirements model. We work to transform this model into four levels of design details: The data structure The system architecture The interface representation and The component level design The data design transforms the information domain model created during analysis into the data structures that will be required to implement the software. The architectural design defines the relationship between major structural elements of the software. The interface design describes how the software communicates within itself, with systems that interoperate with it, and with humans who use it. The component level design transforms structural elements of the software architecture into a procedural description of the software components.
7.2 Design goals

Design is a meaningful engineering representation of something that is to be built. Software design sits at the technical kernel of the software engineering and is applied regardless of the software process model this is used. The following are the goals of the design: The design must implement all the explicit requirements contained in the analysis model.
29
Hyper Ethernet Protocol It must accommodate all the implicit requirements desired by the user. The design must be readable and must serve as a guide while developing the actual product and also while testing. It must provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective. A design must be modular i.e., the software must be logically partitioned into elements that perform specific functions and sub functions. A design should lead to data structures that are appropriate for the objects to be implemented. A design must lead to components that exhibit independent functional characteristics. A design should lead to interfaces that reduce the complexity of connections between modules and with the external environment.
To minimize conceptual (semantic) errors 7.3 Analysis

We found out that HyperEthernet will be working in a highly reliable environment and hence negligible errors may occur. Since HyperEthernet will be working on the Ethernet protocol which already has an error detection mechanism built into it, we found that the frames we received were always error free. This gave us a two fold advantage of speed as well as reliability. Since the frame drop rate is very low so instead of sending an acknowledgement after each frame a bulk acknowledgement with selective negative acknowledgements is sent after a preset amount of frames which saves bandwidth. In the implementation part we had two choices. One was to embed the code into the kernel and recompile the whole thing and the second one was to make HyperEthernet as a re-loadable module. The second approach although difficult to implement is found more suitable since the advantages outweigh the disadvantages. The advantage lies in the fact that the code can be deployed quickly and efficiently. Compiling the whole kernel again and again would be highly inefficient as in the amount of time taken in compiling it.
30
Hyper Ethernet Protocol We studied the already existing protocol implementations in Linux and found out that Linux system provides a socket interface for user to kernel interaction which can be modified to suit our needs. The implementation can be sub divided into two main parts:i. Socket handler: Responsible for user-kernel interaction by socket calls. ii. Protocol handler: Responsible for sending/receiving data to/from the network.
7.4 Modeling
7.4.1 HyperEthernet Frame Structure
The frames will be structured as follows:
31
32
A System context diagram (SCD) is the most abstract view of a system, showing the system as a whole, its inputs and outputs from/to external systems. SCD is very helpful in understanding the context in which the system will be used, and therefore, is an important part of Software engineering
7.4.2 Architecture Context Diagram

The following Architecture Context Diagram gives the abstract view of the Hyper-Ethernet protocol. The top block shows the application which requests or receives the data at the user layer of the system. The process and control functions are carried out by the central block or the protocol block. The input/output processing is done at the client and server blocks. In response to a request from the client the data (from file or user) is transferred by the server.
33
Application data interchange
Request Request
Query
Request/Ack
Client
Data
Hyper-Ethernet Protocol
Data/ Response
Server
Hyper-Ethernet: Architecture Context Diagram

7.4.3 Architecture Flow Diagram
Architecture flows define how information is exchanged between different elements in the architecture. Architecture flows are also called information flows. An architecture flow diagram will show the elements involved in the flow, the name of the flow, the status of the flow and the direction of flow. The following diagram shows the flow of information between the elements of the Hyper-Ethernet protocol. As compared to architecture context diagram (as shown above), this diagram uncovers some abstractions of the various elements of system design along with the flow and direction of information between them. As shown below the Hyper-Ethernet protocol block has been broken into smaller blocks. The following is the sequence of events that occurs for a successful data transmission operation: 1. The data chunk (mostly a file on disk) to be transmitted is broken into MTUs. 2. A sequence number is allotted to every packet.
34
Hyper Ethernet Protocol 3. The packet is put in a transmission queue and transmitted to its destination. 4. Upon receiving a fixed number of packets (SACK strategy), an acknowledgement frame is dispatched. 5. In the case of a packet loss, the packet has to be retransmitted by the sender.
Data Request
Application data interchange
Data Delivered
Packet formation
Packet Sequencing
Client
Successful Transmission
Success
Server
Packet Relay
Fail
Packet Retransmit
Hyper-Ethernet: Architecture Flow Diagram

7.4.4 Data Flow Diagrams
Graphical Description of a System's data & how the process transforms the data is known as Data Flow Diagram or simply DFD. Unlike detail flowcharts, DFDs do not supply detailed descriptions of modules but graphically describe a system's data & how the data interact with the system. A semi-formal way of representing computer system functions in a diagram. Some prominent features are: DFDs represent major components or functions with Circles The actions for input by a user or system go in Rectangular Boxes
35
Hyper Ethernet Protocol Databases are represented by parallel lines enclosing a phrase Display or output information is represented by a box with a truncated top right corner A Data Flow Diagram (DFD) is also known as a Process Model. Process Modeling is an analysis technique used to capture the flow of inputs through a system (or group of processes) to their resulting output. The model is fairly simple in that there are only four types of symbols process, dataflow, external entity, data store. Process Modeling is used to visually represent what a system is doing. It is much easier to look at a picture and understand the essence than to read through verbiage describing the activities. System Analyst after talking with various users will create DFD diagrams and then show them to users to verify that their understanding is correct. The process models can be created to represent an existing system as well as a proposed system. The following clarifies what each symbol in Process Modeling represents: Process An activity or a function that is performed for some specific reason; can be manual or computerized; ultimately each process should perform only one activity Data Flow single piece of data or logical collection of information like a bill Data Store collection of data that is permanently stored External Entity A person, organization, or system that is external to the system but interacts with it A Context Model is done first when completing the process models for a system. It represents the system with a single process and then shows the external agents with which the system interacts. A context diagram is often named the name of the system and does not start with a verb as do other processes. Typically data stores are not part of a context model since these would be internal to the system. By creating the context model first the system analyst focuses on the outward communications and exchanges and later the inward communications and exchanges.
36
Hyper Ethernet Protocol After the context model is created the process is exploded to the next level to show the major processes in the system. Depending upon the complexity of the system each of these processes can also be exploded into their own process model. This continues until the goal of each process accomplishing a single function is reached. Because of this approach the context model is referred to as Level 0 (Zero) DFD, the next as Level 1 DFD, etc. 7.4.4.1 DFD Levels The level 0 DFD shows an overall summary of the data flowing in the system.
Application (user-layer) request data
Display / Print Requested Data On The Console
Node Holding Data Responds ToThe Request
DFD Level 0
37
Hyper Ethernet Protocol The level 1 DFD elaborates on this and splits the functionality into sub modules. In the following diagram the protocol explodes into its key modules namely, the socket handler and the protocol handler.
Application (user-layer) request data
Invoke System Calls
Socket Handler
Probe Port Request Action
Protocol Handler Display / Print Requested Data On The Console
Allot port for communication if port is free
Node Holding Data Responds ToThe Request
DFD Level 1
7.4.5 State Machine Diagrams State diagrams show the dynamic behavior of a system. The diagram shows the various states that an object can get into and the transitions that occur between the states. The taxonomy related to state diagrams is as follows: State: The state object is a snapshot of an object at a particular point in its life. A state may have an activity describing the function being performed.
38
Hyper Ethernet Protocol Initial State: The initial state is the starting state of the object with reference to the behavior that the diagram explains. Each state diagram should have only one initial state. Final State: Each final state is the ending state of the object with reference to the behavior that the diagram explains. There may be multiple final states for an object. Transition: The transition link represents the relationship between different states of an object. The transition guard is a condition which limits the cases in which a transition can occur. The transition action is performed during the transition and cannot be interrupted. Socket State Machine Initially a new end point socket is created and table space is allocated for it. An ordinary file descriptor (returned by socket call) is used by all succeeding calls. Newly created sockets dont have network addresses. These are assigned at the BIND state. The LISTEN state allocates space to queue incoming calls, when several clients try to connect at the same time.(This is a non blocking call). To block waiting for an incoming connection, the server executes the Accept call. When a request for a new connection arrives, a new socket with same properties as the previous is created and a file descriptor is returned for it. The server can then fork off a process to handle connection on the socket and go back to waiting for the next connection on the original socket. ACCEPT returns a fd which can be used for normal read/write. At the client side, a BIND is not required since the address used does not matter to the server. The CONNECT primitive blocks the caller and actively starts the connection process. When it completes, the client process is unblocked and the connection is established.
39
Hyper Ethernet Protocol Both sides can now use send/ receive to transmit data over the full duplex connection. Connection release with sockets is symmetric. When both sides have executed a CLOSE primitive, the connection is released.
Start do/ Initialised
Connect
Bind
Connecting Connect
Binded
Listen Establishing connection Old Socket Listening
Got Connection
Connected New Socket
Accept connection
Accept
Unblock User Proc
Send/ Recieve End of transmission Close connection
Socket State Machine

The Hyper-Ethernet protocol connection management scheme has been modeled as follows by a FSM which is similar to a TCP implementation as prescribed by RFC-793. Each connection starts in the closed state. Either a passive (LISTEN) or active open (CONNECT) can occur causing it to leave its state.
40
Hyper Ethernet Protocol If other side does the opposite one, a connection as established and the state becomes ESTABLISHED. At the time of connection establishment, a SYN (sent by the initiator) must be followed by Special ACK & SYN to complete the 3-way handshake. For connection closing a FIN is followed by an ACK and again by a FIN & ACK to complete the 4 way handshake, much like the way TCP/IP functions.
CONNECT/SYN
CLOSED
CLOSE LISTEN CLOSE
LISTEN
SYN/SYN + SP ACK SEND/SYN
SYN RCVD
SYN/SYN +ACK ACK SYN/SYN +ACK
SYN SENT
ESTABLISHED
CLOSE/FIN (Active Close) FIN/ACK FIN/ACK (Passive Close)
FIN WAIT 1
CLOSING
CLOSE WAIT
CLOSE/FIN
ACK ACK
FIN WAIT 2
LAST ACK
FIN/ACK
CLOSED
ACK
Connection State Diagram
41
7.4.6 Use Case

Use Case Diagram is a diagram that shows the relationships among actors and use cases within a system Use case diagrams are often used to: Provide an overview of all or part of the usage requirements for a system or organization in the form of an essential model or a business model Communicate the scope of a development project Model the analysis of the usage requirements in the form of a system use case model A use case model is comprised of one or more use case diagrams and any supporting documentation such as use case specifications and actor definitions. Within most use case models the use case specifications tend to be the primary artifact with use case diagrams filling a supporting role as the glue that keeps the requirements model together. Use case models should be developed from the point of view of project stakeholders and not from the (often technical) point of view of developers. The scenarios in Hyper-Ethernet protocol usage could be: 1. Connection Establishment 2. Data Transfer 3. Connection Termination A generalized use case has been created (shown in the figure) which can be used to depict any of the three scenarios mentioned above.
42
Initator requesting data
Non Navigable Arrow shows Bidirectional Relation.
Client Node
Send SYN/FIN/DATA
Server Node
<<include>> Send Sp. ACK
<<include>>
Data resides at the Server
<<include>>
<<include>>
Packet Transmission
Packet Formation
Use Cases
7.4.7 Deployment diagram
A deployment diagram is a mid-level architecture diagram work product that primarily documents the static deployment of the major data components and software components to the hardware components. The following figure shows the deployment diagram for Hyper-Ethernet protocol. The different clients and the servers have been shown as they will exist in a typical LAN environment. The noticeable feature is the high speed of data transfer that will occur between the clients and the servers and between the different servers consequent to the use of Hype-Ethernet protocol.
43
Printer
Floppy Drive
File Server Scanner Client 1
Hyper-Ethernet Protocol CD Drive
Client 2 Hyper-Ethernet Protocol
Request Server
Web Camera
Portable Harddisk
Client 3
Trackball
The Request Server requests data from the File Servers.Due to the use of Hyper-Ethernet,the bulk data transfer gets faster.
Deployment Diagram 7.5 Development method

Before the development phase begins all the hardware requirements and the software requirements must be analyzed and must be available. The development phase attempts to define How data are to be structured? How function is to be implemented? How procedural details are to be implemented? How interfaces are to be characterized? How the design will be translated in to a programming language? How testing will be performed?
44
Hyper Ethernet Protocol Initially all the software requirements and hardware requirements are gathered. The data is arranged and available with the help of various respective data structures and buffers:
7.5.1 User Level Sockets

The Programmer wanting to use HyperEthernet as the underlying protocol will be communicating through the use of sockets. In Linux nearly all the communication over the network is done using sockets. To create a socket the function socket() is called with three parameters. the domain specifies the address family of the socket. For internet it is AF_INET, and for HyperEthernet it is AF_HETH. the type specifies the type of the protocol. It can take the values SOCK_STREAM, SOCK_DGRAM, SOCK_RAW etc. the protocol specifies the sub protocol to be used. This is an optional field and the value depends on the protocol family being used. Mostly this value is set to 0 so that the correct protocol based on type selection is used. Further on the programmer can call send(), recv(), connect(), bind(), listen() etc. functions to do the needful and finally the close() function to release the socket. Whenever any function is called the call gets routed to the kernel. The kernel then checks which protocol is the socket associated with and calls the appropriate function of that protocol. The protocol function does the needful and returns. The return value gives an indication to the user whether the operation was successful or not and if not what went wrong. The underlying complexity of implementing the protocol is completely hidden from the programmer. The programmer doesnt need to know how the connection is setup, how data is being sent, how it will be received etc. but he will just make these calls and the needful is done.
45
7.5.2 Kernel Level Sockets

The kernel level sockets are the socket handlers residing at the kernel level. At the user level the socket is merely a socket descriptor. Everything related to the socket like the sequence numbers, packets received, packets queued etc. have to be taken care of at the kernel level. For this we require data structures which are capable of taking care of all this but at the same time are easy to implement and use. The linux kernel comes with one such data structure for socket programmers known as sock. We modified the sock structure to suit our needs and named it sock2 so that it is not confused with the existing sock. Weve used sock2 extensively in the kernel level to do housekeeping and keeping track of connections at the individual level.
7.5.3 Kernel Level Socket Buffers

The data passed on to the kernel level from the user level is nothing but a pointer and the length of the data, and after the return from the call the user may modify the data. Hence we need a copy of the data. The data passed onto the kernel level also needs headers, trailers, etc. so that it can be given to the NIC for transmission. To handle this the kernel programmers have created a data structure known as sk_buff i.e. socket kernel buffer. Its a buffer at the kernel socket level for buffering of data. Also this data structure can be manipulated through the use of various functions like skb_put(), skb_trim(), skb_push(), skb_reserve(), skb_pull() etc. These functions make it easier to add headers, trailers to the data being buffered by the skb. Whenever a packet is received from the network card which carries the protocol number of HyperEthernet a skb containing the data is passed onto our function for further processing. Hence the use of skb also helped in seamless integration with the already existing implementation. The sk_buff structure needed no modification and was found suitable as it was.
46
7.5.4 Module Division

There are two main modules of HyperEthernet with many more sub-modules. 7.5.4.1 Socket handler The socket handler is responsible for user-kernel interaction. The already existing mechanism is used by the HyperEthernet protocol mechanism. The socket handler handles the issues of creating a socket pair for the data transfer to take place, listening and connecting, binding and releasing of sockets as and when required. As HyperEthernet does not work on IP, so in order to know which machine to send/receive data to/from, the socket handler of HyperEthernet protocol implements an IP address to MAC address resolution which gives the MAC address of a corresponding IP address of a machine. The socket handler of HyperEthernet includes the message sending and receiving functionalities for sending/receiving the data from the user level. The various modules are as under: hyper_ethernet.c: This various functions implemented are as follows: a. init_module(): This function registers the HyperEthernet protocol into the kernel protocol linked list. Also the socket handler is registered into the socket handler table. b. cleanup_module(): This function removes the HyperEthernet protocol handler from the protocol linked list as well as the socket handler from the socket handler tables. c. heth_sendmsg(): This function is called by the sys_sendmsg when user calls a send on a socket of type AF_HETH. The heth_sendmsg further calls another function senddata. Also the number of bytes sent successfully are returned by this function which are finally returned to the user. d. heth_accept(): This function is called by sys_accept when an accept call is made to a socket of HyperEthernet. This function accepts a pending connection request.
47
Hyper Ethernet Protocol e. heth_listen(): This function puts the socket of HyperEthernet into the listening mode. For this all the connection tables as well as the listener tables are updated. f. heth_connect(): This function makes a connection request to a remote server on the LAN. First a SYN frame is sent and when we get a SYN+SPACK frame, the HyperEthernet protocol sends back a SPACK Frame and the call returns indicating a successful connection. g. heth_bind(): The bind call is used to bind the socket to a particular port. Although this step is not necessary when doing a client side connection but this function must be called before making a listen call on a server. h. heth_release(): This function is called when a socket is no longer needed i.e. a close call has been made at the user level. This function releases all the memory reserved for the socket at the kernel level. 7.5.4.2 Protocol handler As mentioned above, the protocol handler is responsible for sending/receiving data to/from the network. The various modules are as under: i. hyper_input.c: This module is responsible for taking the input from the network. The respective functions implemented are: a. heth_net_rcv(): This function is invoked by the kernel whenever NIC receives a frame that has HyperEthernet protocol number in it. If the two bytes of protocol number in the Ethernet frame match HyperEthernet protocol number the heth_net_rcv function is called and is passed the socket kernel buffer as the parameter which encapsulates the received frame. This function further processes the frame received and checks the type of frame. After the frame type has been identified appropriate action is taken. ii. hyper_output.c: This module is responsible for giving the output to the network. The various respective functions implemented are:
48
Hyper Ethernet Protocol a. heth_dev_xmit(): This function transmits the data contained in the sk_buff buffer over the network. b. create_frame(): This function creates a frame to be sent across the network according to the type of flags i.e. the type of HyperEthernet frame to be created viz. an acknowledgement frame, a special acknowledgement frame, a fin frame etc. c. create_data_frame(): This function creates a data frame. For this the respective flags are passed to the create_frame() function. d. send_data(): This function is called by the heth_sendmsg() when the user calls a send. This function breaks the data into multiple frames to be sent if it is greater than MTU of the NIC. Each frame is then sent and finally number of bytes successfully sent are returned. e. send_ack(): This function first creates an acknowledgement frame by passing the appropriate flags to the create_frame() function and then sends it over the network. Any missing frame numbers are also sent so that they are resent. f. send_syn():This function first creates a SYN frame by passing the appropriate flags to the create_frame() function and then sends it over the network. Initiallly, after connection set-up, the window size of the sender and the receiver are exchanged for dynamic window resizing for flow control so that the network congestion if any is taken into account and a slow receiver is not swamped by a fast sender. g. send_spack(): This function first creates a special acknowledgement frame (a frame to denote an acknowledgement for an
acknowledgement, SYN or a FIN frame) by passing the appropriate flags to the create_frame() function and then sends it over the network.
49
7.5.5 Pseudo Codes

7.5.5.1 Pseudo code for connection establishment by 3-way handshake Initiator : Establish Connection { Set SYN bit=1; Set WND_SIZE bit=1; Set the 16 bit WINDOW_SIZE field= Our Buffer Window; Assign SEQUENCE_NUMBER= Generate_ISN( ); // Generate_ISN is a function to generate the initial sequence number Send SYNFrame Start Timeout Timer WaitForSYNAcknowledgement CreateNew Frame and Set Sp. Acknowledgement=1 SendFrame } Initiator Connection Established
Receiver :
50
Hyper Ethernet Protocol On Receiving a SYN Packet { Set SYN bit=1; Set WND_SIZE bit=1; Set Sp. ACK bit=1; Set the 16 bit WINDOW_SIZE field= Our Window Size; SEQUENCE_NUMBER= Generate_ISN(); SendFrame Start Timer On Timeout Repeat the process Max. 3 times } Receiver Side Connection Established
--END OF 3-WAY HANDSHAKE--
51
Hyper Ethernet Protocol 7.5.5.2 Pseudo code depicting Adaptive Flow control from Sender Perspective Three way handshake for connection set-up // After connection set-up (receiver having sent its window size in connectionset-up) SendData Function // Called from User Space If datalength < maxdatalength (MTU header size) then send only maxdatalength data while ( we have a free receiver window) { CreateNewFrame Set DataBit in Frame Copy Data from UserSpace into Frame Increment SequenceNumber Transmit&PutInBuffer } Acknowledgement and Timeout handler for transmitted frames // Called from our packet handler if acknowledgement received or from a timer handler If acknowledgement received { NextData is Sent with SpecialAckBit Set Clear All Acknowledged Frames from Buffer and retransmit NACK Frames }
52
Hyper Ethernet Protocol Else RetransmitAll Frames from Buffer //Connection close
53
Hyper Ethernet Protocol 7.5.5.3 Pseudo code depicting Adaptive Flow control from Receiver Perspective Three way handshake for connection set-up // After connection set-up (receiver having sent its window size in connectionset-up and sender having sent the first packet) framereceived Put frame in appropriate location in the receiver buffer Start Timer If total frames in receive buffer=advertised window size) then SendAcknowledgement Data Read //User Check for data in receive buffer. If data available return data and free the buffer Recalculate the window size SendAcknowledgement // Called from frame received or when timer elapses Check frames in Received buffer Calculate the acknowledgements needed to be sent Send the Acknowledgement Frame //Connection Close
54
Hyper Ethernet Protocol 7.5.5.4 Connection Closing Initiator:CloseConnection { CreateFrame Set FIN Bit SendFrame Start Timer on Timeout Resend Frame WaitForSpAcknowledgement If FIN Bit Also Set in Sp. Ack Frame then { Create Frame Set Sp. Ack bit SendFrame } } Receiver And Initiator FIN Frame Received { Acknowledge the Connection Close by Sending a Sp. Ack Frame No More Data to Receive hence free all Receive Buffers } --CONNECTION CLOSED --
55
8 TEST PROCEDURE
8.1 Introduction
Testing is a critical element of Software Quality Assurance and represents the ultimate review of specification, design and code generation. If a system is implemented without being tested it may lead to erroneous working and dissatisfaction on the part of the customer. It will also prove disastrous to the reputation of the development team. Only a well planned testing strategy will ensure a successful design and implementation of the protocol. If testing is conducted successfully it will uncover errors in the software. As a secondary benefit, testing demonstrates that the software functions appear to be working according to specification, that behavioral and performance requirements appear to have been met. In addition, data collected as testing is conducted provide a good indication of software reliability and some indication of the software quality as a whole. But testing cannot show the absence of errors or defects, it can show only that software errors and defects are present.
8.2 Goals and Objectives

The testing of the HyperEthernet protocol is being carried out to assess whether the operational capability of the protocol is equivalent to the specifications mentioned in the Requirement Analysis. Software Testing Goals: The data received at the terminal should be exactly the same as sent from the other terminal. All the functions should work as anticipated. Whether the HyperEthernet protocol is fulfilling its basic objectives of being a reliable, high speed, bulk data transfer protocol.
56
Hyper Ethernet Protocol Whether errors which have negligible probability of occurring are being handled properly. Whether memory being allocated is being freed after use. Whether flow control is working properly in all situations as intended.
8.3 Testing Strategies

The following discusses basic software testing principles that apply whether your application runs on a mainframe, PC, Web browser, or cell-phone. Software in general has an abysmal quality record. There is one basic fact that is crucial to the improving the overall quality of software: it requires a management commitment by the entire organization to improving the process by which they produce software. Studies by the Software Engineering Institute have conclusively shown that software problems are ultimately management issues rather than technical issues. Treating software production as a manufacturing process rather than a craft-like creation process can solve these problems.
8.3.1 Testing: the hardest task

You can write a program in an hour that can have 50 million possible combinations to test. The labor involved can cost fortunes. Therefore testing is often the first thing to slip when resources stretch - but it's the entire organization that suffers when a defect causes problems. Lost revenue or reputation is probably the least harmful result of defects. Measurements show that a defect discovered during design that costs $1 to rectify will cost $1,000 to repair in production. This is a tremendous cost differential and clearly points out the advantage of early error detection.
8.3.2 Testing vs. Quality Assurance

Quality Assurance is the process of making sure that the customers gets enough of what they pay for to satisfy their needs. Testing is the means by which we perform the process. We can test without assuring quality, but you can't assure quality without testing. A common problem with software quality is that the
57
Hyper Ethernet Protocol assurance is in the hands of the producers. While the producers can certainly create and perform insightful, powerful tests, it is perfectly possible to design tests that will churn away forever and never discover a defect. This is the psychological temptation when the software producers program tests to evaluate them.
8.3.3 Quality Process Management

The best way to assure quality is to create a process that emphasizes testing at all points in the process, including the process itself. Understanding test types, phases and tools can help you plan an effective testing strategy. A complete software development process that defines and enforces your standards and provides a reasonable framework for appropriate tools will significantly increase your productivity and quality. Inappropriate tools will make matters worse. Automating a bad process makes things get worse faster.
8.3.4 Software Testing Basics

Structural (usually called white box) testing and functional ("black box") testing have unique characteristics, advantages and limitations that make them more or less applicable to certain stages of test.
8.3.5 White box testing

Structural tests verify the structure of the software itself and require complete access to the object's source code. This is known as white box testing because you see into the internal workings of the code. White-box tests make sure that the software structure itself contributes to proper and efficient program execution. Complicated loop structures, common data areas, 100,000 lines of spaghetti code and nests of ifs are evil. Well-designed control structures, sub-routines and reusable modular programs are good. Many studies show that the single most effective defect reduction process is the classic structural test - the code inspection or walk-through. Code inspection is like proofreading - it can find the mistakes the author missed - the typo's" and logic errors that even the best programmers can produce. Debuggers are typical white-box tools.
58
Hyper Ethernet Protocol White-box testing's strength is also its weakness. The code needs to be examined by highly skilled technicians. That means that tools and skills are highly specialized to the particular language and environment. Also, large or distributed system execution goes beyond one program, so a correct procedure might call another program that provides bad data. In large systems, it is the execution path as defined by the program calls, their input and output and the structure of common files that is important. This gets into a hybrid kind of testing that is often employed in intermediate or integration stages of testing.
8.3.6 Black Box Testing

Functional tests examine the observable behavior of software as evidenced by its outputs without reference to internal functions. Hence black box testing. If the program consistently provides the desired features with acceptable performance, then specific source code features are irrelevant. It's a pragmatic and down-to-earth assessment of software. Black box tests better address the modern programming paradigm. As objectoriented programming, automatic code generation and code re-use becomes more prevalent, analysis of source code itself becomes less important and functional tests become more important. Black box tests also better attack the quality target. Since only the people paying for an application can determine if it meets their needs, it is an advantage to create the quality criteria from this point of view from the beginning. Black box tests have a basis in the scientific method. Like the process of science, functional tests must have a hypothesis (your specifications), a
defined method or procedure (your test), reproducible components (your test data), and a standard notation to record the results. You can re-run black box tests after a change to make sure the change only produced intended results with no inadvertent effects.
59
8.3.7 Test Phases

There are several type of testing in a comprehensive software test process, many of which occur simultaneously.
8.3.8 Unit Test

In some organizations, a peer review panel performs the design and/or code inspections. Unit or component tests usually involve some combination of structural and functional tests by programmers in their own systems. Component tests often require building some kind of supporting framework that allows components to execute.
8.3.9 Integration test

The individual components are combined with other components to make sure that necessary communications, links and data sharing occur properly. It is not truly system testing because the components are not implemented in the operating environment. The integration phase requires more planning and some reasonable subset of production-type data. Larger systems often require several integration steps. There are three basic integration test methods: All-at-once Bottom-up Top-down
The all-at-once method provides a useful solution for simple integration problems, involving a small program possibly using a few previously tested modules. Bottom-up testing involves individual testing of each module using a driver routine that calls the module and provides it with needed resources. Bottom-up testing often works well in less structured shops because there is less dependency on availability of other resources to accomplish the test. It is a more intuitive approach to testing that also usually finds errors in critical routines earlier than the top-down method. However, in a new system many modules must be integrated to produce
system-level behavior, thus interface errors surface late in the process.
60
Hyper Ethernet Protocol Top-down testing fits a prototyping environment that establishes an initial skeleton that fills individual modules are completed. The method lends itself to more structured organizations that plan out the entire test process. Although interface
errors are found earlier, errors in critical low-level modules can be found later than you would like. What all this implies is that a combination of low-level bottom-up testing works best for critical modules, while high-level top-down modules provide an early working program that can give management and users more confidence in results early on in the process. There may be need for more than one set of integration environments to support this hybrid approach.
8.3.10 System Test

The system test phase begins once modules are integrated enough to perform tests in a whole system environment. System testing can occur in parallel with integration test, especially with the top-down method.
8.3.11 Performance / Stress Test

An important phase of the system test, often called load, volume or performance test, stress tests try to determine the failure point of a system under extreme pressure. Stress tests are most useful when systems are being scaled up to
larger environments or being implemented for the first time. Web sites, like any other large-scale system that requires multiple accesses and processing, contain vulnerable nodes that should be tested before deployment. Unfortunately, most stress testing can only simulate loads on various points of the system and cannot truly stress the entire network as the users would experience it. Fortunately, once stress and load factors have been successfully overcome, it is only necessary to stress test again if major changes take place. A drawback of performance testing is that can easily confirm that the system can handle heavy loads, but cannot so easily determine if the system is producing the correct information. In other words, processing incorrect transactions at high speed can cause much more damage and liability than simply stopping or slowing the processing of correct transactions.
61
8.3.12 Regression Test

Regression tests confirm that implementation of changes have not adversely affected other functions. Regression testing is a type of test as opposed to a phase in testing. Regression tests apply at all phases whenever a change is made.
8.3.13 Quality Assurance Test

Some organizations maintain a Quality Group that provides a different point of view, uses a different set of tests, and applies the tests in a different, more complete test environment. The group might look to see that organization standards have been followed in the specification, coding and documentation of the software. They might check to see that the original requirement is documented, verify that the software properly implements the required functions, and see that everything is ready for the users to take a crack at it.
8.3.14 User Acceptance Test and Installation Test

Traditionally, this is where the users get their first crack at the software. Unfortunately, by this time, it's usually too late. If the users have not seen
prototypes, been involved with the design, and understood the evolution of the system, they are inevitably going to be unhappy with the result. If you can perform every test as user acceptance tests, you have a much better chance of a successful project.
8.3.15 Repair
The whole point of all quality processing is to prevent defects as much as possible, and to discover those defects that do occur before the customer does. The repaired code should start the testing process all over again.
62
8.4 Comparison of Hyper Ethernet with TCP/IP

8.4.1 Introduction
TCP/IP, being the prevalent protocol in the current general network environment, an obvious issue of comparison with HyperEthernet comes to mind. HyperEthernet comes out to be successful and competitive as compared to TCP/IP in some important aspects. HyperEthernet includes a 6 Byte Header as compared to a 64 Byte Header (with Padding) of TCP/IP thereby involving less overheads, something at which TCP/IP suffers making TCP/IP slow. HyperEthernet does away with Checksum (for error handling) in its layer by relying on the lower layer Ethernet which already has a Frame Check
Sequence(FCS) implementation for Checksum, thereby further improving its speed of transmission. HyperEthernet consumes less number of CPU Cycles thereby making it fast HyperEthernet involves a Selective Negative Acknowledgement scheme for handling ACKs with bulk NACKs being sent after a certain number of packets and not after every packet further enhancing the speed of transmission. More space for data in a Data Transmission Unit as the protocol header is only 6 Bytes.
63
8.4.2 Comparative Figures

TCP/IP File size (kb) HyperEthernet
Time taken (ms)
Time taken (ms)
Average
Time taken (ms)
Time taken (ms)
Average
%age Improve ment
14.4
60.1
7.5
16.6667
192
20
20
20
17
16
16.5
17.5
623.2
75
74
74.5
59
60
59.5
20.134
426
427
426.5
351
363
357
16.295
7.2
1937
1900
1918.5
1577
1611
1594
41.7
10976
11253
11114.5
9302
9289
9295.5
16.366
64.1
16470
16484
16477
13529
13730
13629.5
17.281
148.8
23876
23995
23935.5
20364
19849
20106.5
15.997
64
Average Transfer Tim e for TCP/IP and HyperEthernet (Less is better)
30000
25000
20000
Time Taken (ms)
15000
10000
5000
0 14.4 60.1 192 623.2 3000 File Size (kb) TCP/IP HyperEthernet 7200 41700 64100 148800
65
9 APPLICATIONS
Today's high-performance networks are handling increasingly complex data at faster speeds, sometimes placing prohibitive processing burdens on systems which can degrade network application performance. Technologies that can cost-effectively boost the performance of moving data between application servers and clients across networks will be of great value. The HyperEthernet is just such a protocol. HyperEthernet increase IT productivity in network-intensive applications by dramatically reducing the burden of processing the Transmission Control Protocol (TCP) and Internet Protocol (IP) overhead in network transactions. The systems can focus on processing application requests rather than network protocols. This results in increased network performance, application response times and IT productivity. Being a protocol designed and implemented for Local Area Networks (LAN), HyperEthernet finds an enormous application in the industry. HyperEthernet is a highspeed bulk data transfer protocol. It can be used in the industry for bulk data transfer for various widespread applications as in the file transfer applications, huge databases, efficient transfer of files, movie editing, etc. HyperEthernet protocol can support applications in financial data services, government agencies, the military, utilities, transportation, and telecommunications. It is available for use for a wide variety of network and commercial applications which enable a myriad of different tasks and functions to be accomplished, ranging from implementing essential business tasks to pure entertainment by users. HyperEthernet can be used in a wide variety of commercial applications such as in terminal data link units used in manufacturing, process control, energy management, etc. One of the widespread applications of HyperEthernet is in the area of telecommunications. As the telecoms sector undergoes rapid changes and businesses increasingly rely on data networks to fuel growth in the digital economy, network operators are beset with the daunting task of staying ahead of the technology curve while keeping costs low. Today, they are caught in a struggle within the telecoms industry over networking protocols. HyperEthernet provides a speedy, reliable and flexible solution to the problem. It can provide support for a wide range of
66
Hyper Ethernet Protocol applications such as high-resolution imaging and high-speed data transfer for multimedia communications. HyperEthernet improves network performance, accelerates application performance, frees up CPU cycles thereby leading to a faster network environment to work in. Industries such as scientific computing, oil & gas exploration and bio informatics will likely benefit from performance efficiency of the HyperEthernet protocol. The types of applications and environments that will benefit include File Serving, High Performance Technical Computing, High End Backup and Restore, Video Editing, etc. HyperEthernet can be used in high-performance computing applications such as immersive real-time visualization of satellite imagery, computational fluid dynamics, ocean and weather modeling, and space physics as well.
67
10 FUTURE
10.1 Overview
HyperEthernet comes out to be a reliable, adaptive, connection oriented, high speed bulk data transfer protocol over Ethernet with its application in Local Area Networks (LANs). We have seen the various aspects and stages of the project development. In this section we discuss the limitations and a futuristic approach to the future enhancements to overcome those limitations.
10.2 Limitations
The project deals with the design and implementation of a reliable, adaptive, connection oriented, high speed bulk data transfer protocol over Ethernet. Here under some limitations of the HyperEthernet protocol are mentioned: HyperEthernet protocol works in a reliable environment with negligible probability of errors. The practical work environment could involve a lot of errors and problems. HyperEthernet doesnt work for internet as it is not based on IP. This limits its application compared to other IP based protocols such as TCP/IP etc. The existing HyperEthernet protocol implementation isnt for large networks involving Routers as it is not IP based.
10.3 Enhancements
HyperEthernet can be made more robust towards a more error prone work environment. HyperEthernet does not involve the Multi casting functionality. Multi-casting is the method by which packets are sent to a 'host-group'. This group may consist of zero or more hosts identified by single IP address. Future enhancements of the protocol can involve this added feature.
68
Hyper Ethernet Protocol HyperEthernet can be made more scalable as in a protocol for more than LAN i.e. for large networks. We can provide the feature of Dynamic parameter configuration based on network conditions. This would be a great welcome from the users point of view. The current implementation of HyperEthernet involves standard Ethernet frames. The future enhancements can involve a support for 10G Jumbo Frames with a frame size of 9000 bytes. QoS (Quality of Service) is the capability of a network to provide better service to selected network traffic over various underlying technologies like Frame Relay, ATM, IP and routed networks etc. In other words, it is that feature of the network by which it can differentiate between different classes of traffic and treat them differently. Today's networks need to support multiple kinds of traffic over single network links. Different kinds of traffic demand different treatments from the network. Therefore, the future enhancement of HyperEthernet could involve the provision so that it can deliver multiple classes of service - that is HyperEthernet can be QoS conscious.
69
APPENDIX A
Whats a socket?
A socket is one of the most fundamental technologies of computer networking. Sockets allow applications to communicate using standard mechanisms built into network hardware and operating systems. A socket descriptor is the following type:
int thats right just a simple integer.
The following structure holds socket address information for many types of sockets:
struct sockaddr { unsigned short char address };
sa_family; // address family, AF_xxx sa_data[14]; // 14 bytes of protocol
Another structure used for AF_INET family. This can also be used with the HyperEthernet.
struct sockaddr_in { short int sin_family; unsigned short int sin_port; struct in_addr sin_addr; unsigned char sin_zero[8]; the same size as struct sockaddr }; // // // // Address family Port number IP address To make this structure
This structure makes it easy to reference elements of the socket address. Note that sin_zero (which is included to pad the structure to the length of a struct
sockaddr)
should be set to all zeros with the function memset().Also, notice that corresponds to sa_family in a struct sockaddr and should be set to
sin_family
"AF_HETH". The sin_port and sin_addr must be in Network Byte Order. The following functions should be used for Order conversion from host to network and vice-versa.

htons() -- "Host to Network Short" htonl() -- "Host to Network Long" ntohs() -- "Network to Host Short" ntohl() -- "Network to Host Long"
70
socket()
Here's the socket system call.
#include <sys/types.h> #include <sys/socket.h> int socket(int domain, int type, int protocol);
The domain should be set to "AF_HETH", just like in the struct sockaddr (above.) Next, the type argument tells the kernel what kind of socket this is: SOCK_STREAM or SOCK_RAW. Finally, just set protocol to "0" to have socket() choose the correct protocol based on the type.
socket()
simply returns to you a socket descriptor that you can use in later
system calls, or -1 on error. The global variable errno is set to the error's value.
bind()
Once you have a socket, you might have to associate that socket with a port on your local machine. (This is commonly done if you're going to listen() for incoming connections on a specific port). The port number is used by the HyperEthernet to match an incoming packet to a certain process's socket descriptor. If you're going to be doing a connect() only, this is unnecessary. Here is the synopsis for the bind() system call:
#include <sys/types.h> #include <sys/socket.h> int bind(int sockfd, struct sockaddr *my_addr, int addrlen); sockfd
is the socket file descriptor returned by socket(). my_addr is a
pointer to a struct sockaddr that contains information about your port. addrlen can be set to sizeof(struct sockaddr). For example:
#include #include #include #include <string.h> <sys/types.h> <sys/socket.h> <netinet/in.h>
71
#define MYPORT 3 main() { int sockfd; struct sockaddr_in my_addr; sockfd = socket(AF_HETH, SOCK_STREAM, 0); // do some error checking! my_addr.sin_family = AF_HETH; my_addr.sin_port = htons(MYPORT); order my_addr.sin_addr.s_addr = inet_addr("10.12.110.57"); memset(&(my_addr.sin_zero), '\0', 8); // zero the rest of the struct // don't forget your error checking for bind(): bind(sockfd, (struct sockaddr *)&my_addr, sockaddr)); . . . sizeof(struct // host byte order // short, network byte
There are a few things to notice here: my_addr.sin_port is in Network Byte Order.
bind()
also returns -1 on error and sets errno to the error's value.
connect()
Connect is used to initiate a connection and connect to a remote host. The connect() call is as follows:
#include <sys/types.h> #include <sys/socket.h> int connect(int sockfd, addrlen); sockfd serv_addr
struct
sockaddr
*serv_addr,
int
is the socket file descriptor, as returned by the socket() call,
is a struct sockaddr containing the destination port and IP address of
the remote machine running HyperEthernet, and addrlen can be set to

sizeof(struct sockaddr).
72
Hyper Ethernet Protocol For example:

#include #include #include #include <string.h> <sys/types.h> <sys/socket.h> <netinet/in.h>
#define DEST_IP "10.12.110.57" #define DEST_PORT 23 main() { int sockfd; struct sockaddr_in dest_addr; addr sockfd = socket(AF_INET, SOCK_STREAM, 0); // do some error checking! dest_addr.sin_family = AF_INET; // host byte order dest_addr.sin_port = htons(DEST_PORT); // short, network byte order dest_addr.sin_addr.s_addr = inet_addr(DEST_IP); memset(&(dest_addr.sin_zero), '\0', 8); // zero the rest of the struct // don't forget to error check the connect()! connect(sockfd, (struct sockaddr *)&dest_addr, sizeof(struct sockaddr)); . . .
// will hold the destination
Be sure to check the return value from connect()- it'll return -1 on error and set the variable errno.
listen()
To listen for connections youll have to use the listen call. The listen call is fairly simple, but requires a bit of explanation:
int listen(int sockfd, int backlog); sockfd backlog
is the usual socket file descriptor from the socket() system call.
is the number of connections allowed on the incoming queue.
Again, as usual, listen() returns -1 and sets errno on error.
73
Hyper Ethernet Protocol We need to call bind() before we call listen(). So if you're going to be listening for incoming connections, the sequence of system calls you'll make is:
socket(); bind(); listen(); /* accept() goes here */
accept()
The accept call accepts a pending connection. What's going to happen is this: someone will try to connect() to your machine on a port that you are listen()ing on. Their connection will be queued up waiting to be accept()ed. You call accept() and you tell it to get the pending connection. It'll return to you a brand new socket file descriptor to use for this single connection. The original socket is still listening on your port and the newly created one is finally ready to send() and recv(). The call is as follows:
#include <sys/socket.h> int accept(int sockfd, void *addr, int *addrlen); sockfd addrlen
is the listen()ing socket descriptor. addr should be set to NULL and
should be set to 0. returns -1 and sets errno if an error occurs.
accept()
Heres an example.
#include #include #include #include <string.h> <sys/types.h> <sys/socket.h> <netinet/in.h> // the port users will be connecting to // how many pending connections queue
#define MYPORT 3 #define BACKLOG 10 will hold
main() { int sockfd, new_fd; new_fd
// listen on sock_fd, new connection on
struct sockaddr_in my_addr; // my address information struct sockaddr_in their_addr; // connector's address information
74

int sin_size; sockfd = socket(AF_INET, SOCK_STREAM, 0); // do some error checking! my_addr.sin_family = AF_INET; my_addr.sin_port = htons(MYPORT); order my_addr.sin_addr.s_addr = INADDR_ANY; // auto-fill with my IP memset(&(my_addr.sin_zero), '\0', 8); // zero the rest of the struct // don't forget your error checking for these calls: bind(sockfd, (struct sockaddr *)&my_addr, sizeof(struct sockaddr)); listen(sockfd, BACKLOG); sin_size = sizeof(struct sockaddr_in); new_fd = accept(sockfd, (struct sockaddr &sin_size); . . . *)&their_addr, // host byte order // short, network byte
Note that you use the socket descriptor new_fd for all send() and recv() calls. If you're only getting one single connection ever, you can close() the listening
sockfd
in order to prevent more incoming connections on the same port, if you so
desire.
send()
and recv()
These two functions are for communicating over HyperEthernet protocol. The send() call:
int send(int sockfd, const void *msg, int len, int flags); sockfd
is the socket descriptor you want to send data to (whether it's the one
returned by socket() or the one you got with accept().) msg is a pointer to the data you want to send, and len is the length of that data in bytes. Just set flags to 0. Some sample code might be:
char *msg = "HyperEthernet was here!"; int len, bytes_sent; .
75

. len = strlen(msg); bytes_sent = send(sockfd, msg, len, 0); . . . send()
returns the number of bytes actually sent out--this might be less than
the number you told it to send! See, sometimes you tell it to send a whole gob of data and it just can't handle it. It'll fire off as much of the data as it can, and trust you to send the rest later. Remember, if the value returned by send() doesn't match the value in len, it's up to you to send the rest of the string. Again, -1 is returned on error, and errno is set to the error number. The recv() call is similar in many respects:
int flags); sockfd recv(int sockfd, void *buf, int len, unsigned int
is the socket descriptor to read from, buf is the buffer to read the
information into, len is the maximum length of the buffer, and flags can again be set to 0.
recv()
returns the number of bytes actually read into the buffer, or -1 on
error (with errno set, accordingly.)

recv()
can return 0. This can mean only one thing: the remote side has closed
the connection on you! A return value of 0 is recv()'s way of letting you know this has occurred.
close()
After sending and receiving data the connection can be closed by calling the close() function.
close(sockfd);
This will prevent any more reads and writes to the socket. Anyone attempting to read or write the socket on the remote end will receive an error.
76
GLOSSARY
ACK: Short for acknowledgment. A message sent by the receiving unit to the sending station or computer indicating either that the unit is ready to receive a transmission or that a transmission was received without error. Big Endian: A system of transmitting and storing numbers in which the most significant byte is placed first. Channel: In communications, a medium for transferring information. Checksum: A calculated value that is used to test data for errors that can result when data is transmitted or written to disk. Cyclic Redundancy Check: A procedure used for error checking in data transmission. Fault Tolerance: The ability of a computer or an operating system to respond to a catastrophic event or fault, such as a power outage or a hardware failure, in a way that ensures that no data is lost and any work in progress is not corrupted. HyperText Transfer Protocol: A protocol that carries requests from a browser to a Web server and transports pages from Web servers back to the requesting browser. Internet Protocol: A connectionless network-layer communications protocol. Internetwork: Multiple local-area networks (LANs) that are connected to create wide-area networks (WANs), and WANs that are connected to form even larger WANs. Interprocess Communication: The ability of one task or process to communicate with another in a multitasking operating system. Common methods include pipes, semaphores, shared memory, queues, signals, and mailboxes. Little Endian: A system of storing numbers in which the least significant byte is placed first.
77
Hyper Ethernet Protocol Intranet: A private network that uses Internet products and technologies (for example, Web servers) but is not available to external Internet users. NACK: Short for negative acknowledge. A control code that is transmitted to a sending station or computer by the receiving unit as a signal that transmitted information has arrived incorrectly. Packet: A unit of information transmitted as a whole from one device to another on a network. Alternatively, in packet-switching networks, a transmission unit of fixed maximum size that consists of binary digits representing both data and a header that contains an identification number, source and destination addresses, and sometimes error-control data. Protocol: A set of rules and conventions for sending information over a network. These rules govern the content, format, timing, sequencing, and error control of messages exchanged among network devices. Socket: A socket can be used in computer networking to form one end of a bidirectional communication link between two programs, likely over a network Transmission Control Protocol: A connection-oriented network transport that is layered on top of the Internet Protocol (IP).
78
REFERENCES
Books:
1. Neil Matthew, Richard Stones, Beginning Linux Programming, Wiley publishing Inc., 3rd Edition, 2004 2. Gerard J. Holzmann, Design and Validation of Computer protocols, Prentice Hall, 1991 3. Alessandro Rubini and Jonathan Corbet, Linux Device Drivers, OReilly, Second Edition 4. W. Richard Stevens, TCP/IP Illustrated, Volume 1: The Protocols, AddisonWesley, 1994 5. W. Richard Stevens, TCP/IP Illustrated, Volume 2: The Implementation, Addison-Wesley, 1995 6. W. Richard Stevens, TCP/IP Illustrated, Volume 3: TCP for Transactions, HTTP, NNTP, and the UNIX Domain Protocols", Addison-Wesley, 1996 7. Brian Beej Hall, Beejs guide to Network programming, Using Internet Sockets, 2001
Web References:
1. http://www.linux.it/~rubini/docs/ksys/ksys.html 2. http://kernelnewbies.org/documents/kdoc/kernel-api/linuxkernelapi.html 3. http://www.kevinboone.com/linux_kernel_file_0.html 4. http://uqconnect.net/~zzoklan/lkd/using_files.html 5. http://limnos.csrd.uiuc.edu/notes/linux-networking/core.html 6. http://hxdef.czweb.org/knowhow/syscalls.htm 7. http://www.movement.uklinux.net/linux-net.html
79
Hyper Ethernet Protocol 8. http://lxr.linux.no/source/ 9. http://www.tldp.org/LDP/lkmpg/2.6/html/x149.html 10. http://www.win.tue.nl/~aeb/linux/vfs/trail.html#toc3 11. http://packetstormsecurity.org/docs/hack/LKM_HACKING.html
80

Hyper Ethernet

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Hyper Ethernet

Transféré par

Droits d'auteur :

Formats disponibles

A PROJECT REPORT ON

BHARATI VIDYAPEETH DEEMED UNIVERSITY COLLEGE OF ENGINEERING, PUNE-411043

Have successfully completed and submitted their Project report on

Prof. Devendra S. Thakore (Internal Project Guide)

Prof. Suhas H. Patil (Head of Department)

BHARATI VIDYAPEETH DEEMED UNIVERSITY COLLEGE OF ENGINEERING, PUNE-411043

BHARATI VIDYAPEETH DEEMED UNIVERSITY COLLEGE OF ENGINEERING

BHARATI VIDYAPEETH DEEMED UNIVERSITY COLLEGE OF ENGINEERING

Hyper Ethernet Protocol

1.2 Sponsor Company Profile

BHARATI VIDYAPEETH DEEMED UNIVERSITY COLLEGE OF ENGINEERING

1.2.2 Key Areas

BHARATI VIDYAPEETH DEEMED UNIVERSITY COLLEGE OF ENGINEERING

Hyper Ethernet Protocol SNMP Networking and Network Management

BHARATI VIDYAPEETH DEEMED UNIVERSITY COLLEGE OF ENGINEERING

Hyper Ethernet Protocol

2.2 Evaluation and Synthesis

BSD Sockets Socket Interface

Hyper Ethernet Protocol ARP

Network Devices Ethernet

BHARATI VIDYAPEETH DEEMED UNIVERSITY COLLEGE OF ENGINEERING

2.3 Software Requirement Specification

BHARATI VIDYAPEETH DEEMED UNIVERSITY COLLEGE OF ENGINEERING

2.3.2 Information Description

2.3.3 Functional Partitioning and Functional Description

2.3.4 Control Description

BHARATI VIDYAPEETH DEEMED UNIVERSITY COLLEGE OF ENGINEERING

2.3.5 Behavioral Description

2.3.6 Validation Criteria

BHARATI VIDYAPEETH DEEMED UNIVERSITY COLLEGE OF ENGINEERING

Hyper Ethernet Protocol

3.2 Cost Estimation

BHARATI VIDYAPEETH DEEMED UNIVERSITY COLLEGE OF ENGINEERING

3.2.2 Software Cost Estimation

BHARATI VIDYAPEETH DEEMED UNIVERSITY COLLEGE OF ENGINEERING

BHARATI VIDYAPEETH DEEMED UNIVERSITY COLLEGE OF ENGINEERING

Hyper Ethernet Protocol

Rating High High High Nominal Nominal Nominal

Multiplier 1.20 0.90 0.90 1.00 1.00 1.05

BHARATI VIDYAPEETH DEEMED UNIVERSITY COLLEGE OF ENGINEERING

Hyper Ethernet Protocol

3.3 Team Structure

BHARATI VIDYAPEETH DEEMED UNIVERSITY COLLEGE OF ENGINEERING

Hyper Ethernet Protocol

BHARATI VIDYAPEETH DEEMED UNIVERSITY COLLEGE OF ENGINEERING

Hyper Ethernet Protocol

BHARATI VIDYAPEETH DEEMED UNIVERSITY COLLEGE OF ENGINEERING

Hyper Ethernet Protocol

4.2 Gantt Chart

BHARATI VIDYAPEETH DEEMED UNIVERSITY COLLEGE OF ENGINEERING

Hyper Ethernet Protocol

BHARATI VIDYAPEETH DEEMED UNIVERSITY COLLEGE OF ENGINEERING

Hyper Ethernet Protocol

BHARATI VIDYAPEETH DEEMED UNIVERSITY COLLEGE OF ENGINEERING

Hyper Ethernet Protocol

BHARATI VIDYAPEETH DEEMED UNIVERSITY COLLEGE OF ENGINEERING

Hyper Ethernet Protocol

BHARATI VIDYAPEETH DEEMED UNIVERSITY COLLEGE OF ENGINEERING

Hyper Ethernet Protocol

BHARATI VIDYAPEETH DEEMED UNIVERSITY COLLEGE OF ENGINEERING

Hyper Ethernet Protocol

5.1.1 Risk Identification

5.1.2 Risk Analysis