Hyper Ethernet

8/4/2019 Hyper Ethernet

http://slidepdf.com/reader/full/hyper-ethernet 1/85

A PROJECT REPORT

ON

HYPER ETHERNET

PROJECT MEMBERSBHUVAN MITAL

IMRAN SADATPARAG SETHI

INTERNAL PROJECT GUIDEPROF. DEVENDRA S. THAKORE

EXTERNAL PROJECT GUIDEMR. 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 Prof. Suhas H. Patil

(Internal Project Guide) (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



BHARATI VIDYAPEETH DEEMED UNIVERSITY COLLEGE OF ENGINEERING

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 ............................................................................................................. 83.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 ........................................................................................ 266.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

What‟s 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

BHARATI VIDYAPEETH DEEMED UNIVERSITY COLLEGE OF ENGINEERING 1

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 re-

loadable 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





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





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

BSD Sockets


Ethernet

ARP

User

Kernel

Network Applications

Socket Interface

Protocol Layers

Network Devices

The task of protocol design has been divided into the following subtasks:





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.





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.





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 detailprior 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





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 (E i) 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 A b

Organic 3.2 1.05

Semidetached 3.0 1.12

Embedded 2.8 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.





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 Rating Multiplier

Software Reliability Requirement High 1.10

Product Complexity High 1.25

Execution Time Constraint High 1.15

Computer Turnaround Time Nominal 1.00





Cost Drivers Rating Multiplier

Operating Environment Experience High 1.20

Programmer Capability High 0.90

Programming Language Experience High 0.90

Modern Programming Practice Nominal 1.00

Use of Software Tools Nominal 1.00

Development Schedule Nominal 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 KLOC

Module Initializer 0.5

Socket Handler 1.1

HyperEthernet Input 0.8

HyperEthernet Output 0.6

Miscellaneous 1





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.





4 ACTIVITY PLAN

4.1 Scheduling

Tasks Days Start Date End Date

1 Requirements Gathering 22 days 05/07/2004 03/08/2004

1.1 Study of protocol basic 7 days 05/07/2004 13/07/2004

1.2 Study of Operating System basics 7 days 12/07/2004 20/07/2004

1.3 Research on previous efforts on protocol design 7 days 21/07/2004 29/07/2004

1.4 Study of feasible platform for implementation 3 days 30/07/2004 03/08/2004

2 Requirement Analysis 39 days 04/08/2004 27/09/2004

2.1 Problem Recognition 2 days 04/08/2004 05/08/2004

2.2 Feasibility Study 10 days 06/08/2004 19/08/2004

2.3 Evaluation and Synthesis 8 days 20/08/2004 31/08/2004

2.4 Software Requirement Specification 1 day 01/09/2004 01/09/2004

2.5 Task Management 2 days 02/09/2004 03/09/2004

2.6 System Description 7 days 06/09/2004 14/09/2004

2.7 Technical Analysis 7 days 15/09/2004 23/09/2004

2.8 Review of Strategy 2 days 24/09/2004 27/09/2004

3 Learning new Technologies 30 days 28/09/2004 10/01/2005

3.1 Study of Socket Programming 5 days 28/09/2004 04/10/2004

3.2 Study of C Programming on Linux Platform 3 days 05/10/2004 07/10/2004

3.3 Study of Kernel Programming in Linux 17 days 08/10/2004 03/01/2005

3.4 Study of OS Concepts Implementation 5 days 04/01/2005 10/01/2005

4 System and Data design 15 days 11/01/2005 31/01/2005

4.1 Outline of HyperEthernet Protocol 6 days 11/01/2005 18/01/2005

4.2 HyperEthernet Frame Design 3 days 19/01/2005 21/01/2005

4.3 Design of Implementation Functions 3 days 24/01/2005 26/01/2005

4.4 UML Diagrams 2 days 27/01/2005 28/01/2005

4.5 GUI Designing 1 day 31/01/2005 31/01/2005





Tasks Days Start Date End Date

5 Modularization of System Implementation 2 days 01/02/2005 02/02/2005

6 Protocol Implementation : Phase I 7 days 03/02/2005 11/02/2005

6.1 Skeletal Implementation of Socket Handler 3 days 03/02/2005 07/02/2005

6.2 Skeletal Implementation Protocol Handler Implementation 3 days 08/02/2005 10/02/2005

6.3 Review of Work 1 day 11/02/2005 11/02/2005

7 Protocol Implementation : Phase II 26 days 14/02/2005 21/03/2005

7.1 Final Implementation of Socket Handler 12 days 14/02/2005 01/03/2005

7.2 Final Implementation of Protocol Handler 12 days 02/03/2005 17/03/2005

7.3 Review of Work 2 days 18/03/2005 21/03/2005

8 GUI Implementation 7 days 22/03/2005 30/03/2005

9 Integration of modules 2 days 31/03/2005 01/04/2005

10 Protocol Testing 10 days 04/04/2005 15/04/2005

10.1 Validation Testing 5 days 04/04/2005 08/04/2005

10.2 Integration Testing 5 days 11/04/2005 15/04/2005

11 Documentation and Manual Design 4 days 18/04/2005 21/04/2005





4.2 Gantt Chart





















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, it‟s 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.





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 Category Probability Impact

1. Overly Optimistic Schedule SC 70% 1

2. Wrong Estimate of size and efforts PS 65% 1

3. Requirements keep on changing PE 60% 2

4. Error prone modules require more SC 65% 3





Risks Category Probability Impact

testing and implementation work

5. Cost of Project could be very high CR 30% 2

6. Insufficient knowledge of

technologies required

TE 55% 1

7. Availability of expert guidance in

the required field

SU 10% 1

8. Project may not finish on time SC 25% 2

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.





Risk Monitoring and Management

Keep track of schedule steps.

Modify the estimates as the project develops and it becomesclearer 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.


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.






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.


Perform regular reviews to check if the productivity is being

affected.





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 assuranceapproval 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







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





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 + 0

= 0

because HyperEthernet exhibits 100 % reliability.





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 bebuilt.

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.





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 codeinto 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.





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:









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.





Application data interchange

Hyper-Ethernet

ProtocolClient Server

Request

Request Query

Data

Request/Ack

Data/

Response

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 MTU‟s.

2. A sequence number is allotted to every packet.





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.

Application data

interchange

Packet formation

Packet Relay

Client Server

PacketSequencing

Packet Retransmit

Successful

Transmission

Data Request Data Delivered

Fail

Success

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 modulesbut 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





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.





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

Hyper-Ethernet

Protocol

Display / Print

Requested Data

On The Console

Node Holding

Data Responds

ToThe Request

DFD Level 0





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.

Display / Print

Requested Data

On The Console

Node Holding

Data Responds

ToThe Request

Probe Port

Allot port for

communication

if port is free

Application

(user-layer)

request data

Socket

Handler

Invoke

System Calls

Protocol

Handler

Request Action

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.





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 don‟t 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 handleconnection 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.





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

Connecting Binded

Listening

UnblockUser Proc Acceptconnection Connected

Send/ Recieve

Closeconnection

Connect Bind

Connect

Listen

Got Connection

Accept New Socket

Old Socket

End oftransmission

Establishingconnection

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.







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.





Send SYN/FIN/DATA Server Node

Send Sp. ACK

Client Node

Non Navigable Arrow

shows Bidirectional

Relation.

Packet FormationPacket Transmission

<<include>>

<<include>>

<<include>>

<<include>>

Initator

requesting data

Data resides

at the Server

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.

http://www.donald-firesmith.com/Components/WorkProducts/DiagramSet/DiagramSet.html

http://www.donald-firesmith.com/Components/WorkProducts/ImplementationSet/DataComponent/DataComponent.html

http://www.donald-firesmith.com/Components/WorkProducts/ImplementationSet/DataComponent/DataComponent.html

http://www.donald-firesmith.com/Components/WorkProducts/DiagramSet/DiagramSet.html





Client 1

Request Server

Client 3

Client 2

Hyper-Ethernet Protocol


Floppy

DrivePrinter

Scanner

CD

Drive

Web

Camera

Portable

Harddisk

Trackball

File Server



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?





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 doesn‟t 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.





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. We‟ve 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. It‟s 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.





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 acorresponding 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.





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 andis 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:





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.





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 :





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--





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 connection-

set-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

}





Else

RetransmitAll Frames from Buffer

//Connection close





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 connection-

set-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





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 --





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.





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





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.





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 object-

oriented programming, automatic code generation and code re-use becomes more

prevalent, analysis of source code itself becomes less important and functional testsbecome 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), adefined 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.





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 sub-

set 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.





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 orperformance 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.





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 softwareproperly 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.





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 forhandling 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.





8.4.2 Comparative Figures

File

size(kb)

TCP/IP HyperEthernet

Timetaken(ms)

Timetaken(ms)

AverageTimetaken(ms)

Timetaken(ms)

Average%age

Improvement

14.4 2 2 2 2 2 2 0

60.1 9 9 9 8 7 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

3 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





Average Transfer Time for TCP/IP and HyperEtherne t (Less is bette r)

0

5000

10000

15000

20000

25000

30000

14.4 60.1 192 623.2 3000 7200 41700 64100 148800

File Size (kb)

T i m e T a k e n ( m s )

TCP/IP HyperEthernet





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 high-

speed 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





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.





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 doesn‟t 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 isn‟t 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.







APPENDIX A

What’s 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: intthat’s right just a simple integer. The following structure holds socket address information for many types of

sockets:

struct sockaddr {unsigned short sa_family; // address family, AF_xxxchar sa_data[14]; // 14 bytes of protocol

address};

Another structure used for AF_INET family. This can also be used with the

HyperEthernet.

struct sockaddr_in {short int sin_family; // Address familyunsigned short int sin_port; // Port number

struct in_addr sin_addr; // IP addressunsigned char sin_zero[8]; // To make this structure

the same size as struct sockaddr};

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

sin_family corresponds to sa_family in a struct sockaddr and should be set to

"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"





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 latersystem 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 <string.h>#include <sys/types.h>

#include <sys/socket.h>#include <netinet/in.h>





#define MYPORT 3

main(){int sockfd;

struct sockaddr_in my_addr;

sockfd = socket(AF_HETH, SOCK_STREAM, 0); // do some errorchecking!

my_addr.sin_family = AF_HETH; // host byte ordermy_addr.sin_port = htons(MYPORT); // short, network byte

ordermy_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, sizeof(structsockaddr));...

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, struct sockaddr *serv_addr, int

addrlen);

sockfd is the socket file descriptor, as returned by the socket() call,

serv_addr 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).





For example:

#include <string.h>#include <sys/types.h>#include <sys/socket.h>

#include <netinet/in.h>

#define DEST_IP "10.12.110.57"#define DEST_PORT 23

main(){int sockfd;struct sockaddr_in dest_addr; // will hold the destination

addr

sockfd = socket(AF_INET, SOCK_STREAM, 0); // do some errorchecking!

dest_addr.sin_family = AF_INET; // host byte orderdest_addr.sin_port = htons(DEST_PORT); // short, network

byte orderdest_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));..

.

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 you‟ll 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 is the usual socket file descriptor from the socket() system call.

backlog is the number of connections allowed on the incoming queue.

Again, as usual, listen() returns -1 and sets errno on error.





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 is the listen()ing socket descriptor. addr should be set to NULL and

addrlen should be set to 0.

accept() returns -1 and sets errno if an error occurs.

Here‟s an example. #include <string.h>#include <sys/types.h>

#include <sys/socket.h>#include <netinet/in.h>

#define MYPORT 3 // the port users will be connecting to

#define BACKLOG 10 // how many pending connections queuewill hold

main(){int sockfd, new_fd; // listen on sock_fd, new connection on

new_fdstruct sockaddr_in my_addr; // my address informationstruct sockaddr_in their_addr; // connector's address

information





int sin_size;

sockfd = socket(AF_INET, SOCK_STREAM, 0); // do some errorchecking!

my_addr.sin_family = AF_INET; // host byte order

my_addr.sin_port = htons(MYPORT); // short, network byteorder

my_addr.sin_addr.s_addr = INADDR_ANY; // auto-fill with my IPmemset(&(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 *)&their_addr,&sin_size);

.

.

.

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;.







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.





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 bi-

directional 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).





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”, O‟Reilly,

Second Edition

4. W. Richard Stevens, “TCP/IP Illustrated, Volume 1: The Protocols”, Addison-

Wesley, 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, “Beej‟s 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

http://www.amazon.com/exec/obidos/search-handle-url/index=books&field-author=W.%20Richard%20Stevens/002-4360907-5728852






http://www.linux.it/~rubini/docs/ksys/ksys.html


http://kernelnewbies.org/documents/kdoc/kernel-api/linuxkernelapi.html


http://www.kevinboone.com/linux_kernel_file_0.html


http://uqconnect.net/~zzoklan/lkd/using_files.html


http://limnos.csrd.uiuc.edu/notes/linux-networking/core.html


http://hxdef.czweb.org/knowhow/syscalls.htm


http://www.movement.uklinux.net/linux-net.html















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

http://lxr.linux.no/source/


http://www.tldp.org/LDP/lkmpg/2.6/html/x149.html


http://www.win.tue.nl/~aeb/linux/vfs/trail.html#toc3



http://packetstormsecurity.org/docs/hack/LKM_HACKING.html







Date post:	07-Apr-2018
Category:	Documents
Upload:	geetika28
View:	217 times
Download:	0 times

Hyper Ethernet

Documents