tftp design doc_1.1

Trivial File Transfer Protocol with Options

Software Design Document

ARICENT:

Revision Number: 1.1

Copyright © 2012 The Aricent Group. All Rights Reserved. No part of this document may be reproduced, stored in a retrieval system, distributed or transmitted, in any form, or by any means, electronic or otherwise, including photocopying, reprinting, or recording, for any purpose, without the express prior written permission of The Aricent Group.

Printed in ________

TRADEMARKS: Aricent and the Aricent Logo are marks and registered trademarks of The Aricent Group in the U.S. and certain other countries. The use of these trademarks without Aricent’s prior written consent is strictly prohibited. Other third party trademarks referenced are the property of their respective owners. Please note that the above list is not all-inclusive, and the absence of any mark from this list does not mean that it is not an Aricent trademark.

DISCLAIMER The information in this book is provided “AS - IS”, without warranty of any kind, express or implied, including but not limited to a warranty of merchantability, fitness for any particular purpose, title or non-infringement of third party rights, and Aricent specifically disclaims all other warranties, conditions or representations. This document is provided for informational purposes only, and should not be construed as a representation or a commitment on the part of Aricent. Information in this document is subject to change without notice.

REQUESTS For information requests or for obtaining permission for the use of this work, please submit a written request to: Corporate Marketing and Legal, The Aricent Group, One Tower Center Boulevard, 18th Floor, East Brunswick, NJ 08816, USA.

DOCUMENT No.: ARICENT:

REVISION HISTORY

Revision No.

Date Description of Change

Author Reviewed & Approved By

1.0 8-09-12 N/A Aayush Kumar TB

1.1 12-09-12 Description aboout mode of transfer and multi client support in HLD has been added.

Harsh Kumar

3 ARICENT:ARICENT CONFIDENTIAL

Contents

CHAPTER 1: 1. INTRODUCTION________________________________________________51.1 PURPOSE....................................................................................................51.2 SCOPE........................................................................................................51.3 DEFINITIONS AND ACRONYMS......................................................................61.3.1 Definitions...............................................................................................61.3.2 Acronyms................................................................................................61.4 REFERENCES..............................................................................................61.5 DOCUMENT ORGANISATION.........................................................................61.6 TYPOGRAPHICAL CONVENTIONS (OPTIONAL)................................................71.7 APPROVALS AND AUTHORIZATIONS..............................................................71.8 DISTRIBUTION.............................................................................................7

CHAPTER 2: 2. HIGH LEVEL DESIGN____________________________________________92.1 LEVEL 0 DESIGN DESCRIPTION....................................................................92.1.1 Interface Description...............................................................................92.2 LEVEL 1 DESIGN DESCRIPTION..................................................................102.2.1 Module name (level 0)..........................................................................102.2.1.1 Decomposition Description------------------------------------------------------102.2.1.1.1 Module Description------------------------------------------------------------112.2.1.1.2 Process Description-----------------------------------------------------------122.2.1.2 Interface Description--------------------------------------------------------------122.2.1.2.1 Process Interface--------------------------------------------------------------122.2.1.3 Dependency Description---------------------------------------------------------122.2.2 Module 2 (level x-1)..............................................................................122.3 LEVEL (X+1) DESIGN DESCRIPTION............................................................122.4 CONTROL FLOW SCENARIO.......................................................................13

2.5 STRUCTURE DIAGRAM…………………………………………………….18 2.5.1 SERVER STRUCTURE DIAGRAM………………………………………….182.5.2 CLIENT STRUCTURE DIAGRAM…………………………………………..19

CHAPTER 3: 3. ALTERNATE DESIGN___________________________________________213.1 ALTERNATE DESIGNS................................................................................213.2 DESIGN EVALUATION REPORT....................................................................213.3 DESIGN LIMITATIONS.................................................................................21

CHAPTER 4: 4. DETAILED DESIGN____________________________________________234.1 TFTPO CLIENT.........................................................................................234.1.1 Detailed Data Design............................................................................234.1.1.1 Data Structure (Struct request_type)-----------------------------------------23

4.1.1.2 Data Structure (Struct option_acknowledgement)……………… 24 4.1.1.3 Data Structure (Struct data_packet)………………………… 24

4.1.1.4 Data Structure (Struct error)………………………………… 25 4.1.1.5 Data Structure (Struct acknowledgement)……………………25 4.1.1.6 Macros……………………………………………………….. 254.1.2 Detailed Module design........................................................................264.2 TFTPO SERVER …………………………………………………………………………………… 324.2.1 Detailed Data Design............................................................................32

4.2.1.1 Data Structure …………………………………………………………………324.2.1 Macros………………………………………………………………………..34

4.2.2 Detailed Module Design………………………………………………………34

SOFTWARE DESIGN DOCUMENT 1ARICENT CONFIDENTIAL

CHAPTER 5: 5. SYSTEM ISSUES______________________________________________455.1 PERFORMANCE.........................................................................................455.2 SCALABILITY.............................................................................................455.3 SYSTEM SIZING.........................................................................................455.4 Logging……………………………………………………………………….45


Tables

Table 1-1: Definitions Used in this Document..............................................................................................6Table 1-2: Acronyms Used in this Document...............................................................................................6Table 1-3: Approvals and Authorizations.....................................................................................................7Table 1-4: Distribution.................................................................................................................................. 7Table 4-1: Field Description Table1...............................................................................................................23Table 4-2: Field Description Table 2……………………………………………………………………………….. 24Table 4-3: Field Description Table 3………………………………………………………………………………...24Table 4-4: Field description Table 4…………………………………………………………………………………25Table 4-5:Field Description Table 5…………………………………………………………………………………25Table 4-6:Field Description Table 6…………………………………………………………………………………32Table 4-7: Field Description Table 7……………………………………………………………………………….. 32Table 4-8: Field Description Table 8………………………………………………………………………………...33Table 4-9: Field description Table 9…………………………………………………………………………………33Table 4-10:Field Description Table 10………………………………………………………………………………33


Chapter

1

1.Introduction

1.1 Purpose

Trivial File Transfer Protocol with options(TFTPO) is a simple protocol to transfer files with the option of negotiation of timestamp and block size. It has been implemented on top of the User Datagram Protocol (UDP) using port number 69.

TFTP only reads and writes files (or mail) from/to a remote server. It cannot list directories, and has no provisions for user authentication.

TFTP defines two modes of transfer: netascii and octet.

Any client can connect to the server if it knows the port number and IP address of the server.

The intended audience are the users of the system.

1.2 ScopeTFTPO is implemented. An implementation of WRQ, RRQ, ERROR, ACK and OACK procedures of TFTP.

The software will not provide authentication and login facility to the client to get connected to the server. There will be no encryption/decryption to provide security of data.

The main application of the product is to send and receive data form client to a server with timeout and block size options.

The product shall be used to demonstrate TFTP procedures with options.


http://en.wikipedia.org/wiki/User_Datagram_Protocol

TRIVIAL FILE TRANSFER PROTOCOL WITH OPTIONS

1.3 Definitions and Acronyms

1.3.1 Definitions

N/A

1.3.2 Acronyms

Table 1-1: Acronyms Used in this Document

Acronym Explanation

RRQ Read Request

TFTPO Trivial File Transfer Protocol with options

TID’s Transfer identifiers

UDP User Datagram Protocol

WRQ Write Request

1.4 References

RFC 1350, Trivial File Transfer Protocol(Version 2), 1992

RFC 2347, TFTP Option Extension, May 1998

RFC 2349, TFTP Timeout Interval and Trransfer Size Option, May 1998

Aricent IPC ppt slides.

1.5 Document Organization# Chapter Contents

1 Introduction Introductory information for the entire Project and Design Document

2 High Level Design Explains the context of the system, and gives an overview of required functionality

3 Alternate Design Specifies any constraints and mentions choice of design over alternate design options

4 Detailed design The low level design that can translate to code is detailed

5 System Issues Other system issues related performance, logs etc are detailed


1.6 Typographical Conventions (Optional)

N/A

1.7 Approvals and Authorizations

Table 1-2: Approvals and Authorizations

Designation Name Date

Approved by Quality Co-ordinator <Name> <dd/mm/yyyy>

Authorized by Engineering Manager <Name> <dd/mm/yyyy>

1.8 Distribution

Table 1-3: Distribution

Copy No. Holder’s Designation Issue Date

1 Engineering Manager <dd/mm/yyyy>

2 Project Co-ordinator <dd/mm/yyyy>

3 Quality Co-ordinator <dd/mm/yyyy>

4 Team members <dd/mm/yyyy>


Chapter

22.High Level Design

2.1 Level 0 Design Description

Fig 2.1 Level ‘0’ DFD

2.1.1 Interface Description

The end user interacts the system through command line interface and transfers files/ receive files to/from a server.




Fig 2.2 Level ‘1’ Design Description

2.2.1 Module name (Level 0)

This module uses TFTP for exchange of files from client to server. TFTP

uses UDP to transfer files in the form of datagram.

2.2.1.1 Decomposition Description

The TFTPO System can be decomposed into two subsystems Client and a Server.

Client is the system through which user interacts and selects mode of transfer, type of request and options.

The server system responds to the client as per the request or return error message in case of any failure.

TFTPO supports two modes of data transfer:

1) Netascii: Netascii is a modified form of ASCII. It consists of an 8-bit extension of the 7-bit ASCII character.

2) Octet: Octet allows for the transfer of arbitrary 8-bit bytes, with the received file identical to the sent file. If a host receives an octet file and then returns it, the returned file must be identical to the original.


2.2.1.1.1 Module Description

Client

Client request server for read request or write request. If it gets suitable response from the server then data transfer can be initiated.

Client supports connect, get, put, mode, timeout, blocksize, exit options.

ServerServer makes connection with the client and accepts the request as mentioned by the client.

Data Description

Various requests and responses are:

1. Read request (RRQ)

2. Write request (WRQ)

3. Data (DATA)

4. Acknowledgement (ACK)

5. Error (ERROR)

6. Option Acknowledgement (OACK)

1. WRQ/RRQ packet:

RRQ and WRQ packet have opcodes 1 and 2 respectively. The file name is a sequence of bytes in netascii. The mode field contains the string "netascii", "octet”. A host which receives netascii mode data must translate the data to its own format. Octet mode is used to transfer a file that is in the 8-bit format of the machine from which the file is being transferred.

2. Data (DATA) packet:

Data is actually transferred in DATA packets. DATA packets (opcode = 3) have a block number and data field. The block numbers on data packets begin with one and increase by one for each new block of data. This restriction allows the program to use a single number to discriminate between new packets and duplicates. The data field is from zero to 512 bytes long. If it is 512 bytes long, the block is not the last block of data; if it is from zero to 511 bytes long, it signals the end of the transfer.

3. Acknowledgement (ACK):

The WRQ and DATA packets are acknowledged by ACK or ERROR packets, while RRQ and ACK packets are acknowledged by DATA or ERROR packets. The opcode is 4 for ack packet. The block number in an ACK echoes the block number of the DATA packet being acknowledged. A WRQ is acknowledged with an ACK packet having a block number of zero.

4. Error (ERROR):

An ERROR packet can be the acknowledgment of any other type of packet. The error code is an integer indicating the nature of the error.



5. Option Acknowledgement (OACK):

If server supports option negotiation, and it recognizes one or more of the options specified in the request packet, the server respond with OACK.

2.2.1.1.2 Process Description

Server can support multiple clients simultaneously. Here we are creating threaded concurrent server where each detached thread will be serving each client request .Thus server will support multiple clients.

2.2.1.2 Interface Description

Here Client acts as an interface with the user. The user can specify command line arguments and specify his/her request.

2.2.1.2.1 Process Interface

N/A

2.2.1.3 Dependency Description

N/A

2.2.2 Module 2 (level x-1)

N/A


N/A


2.4 Control Flow Scenario

Fig. 2.4.1 Normal Processing



Fig. 2.4.2. Acknowledgement timed out


Fig 2.4.3. Data Timed out.

Fig 2.4.4 normal Connection Termination.


Fig 2.4.5 Premature Termination.



2.5 Structure Diagram

2.5.1 SERVER STRUCTURE DIAGRAM

Fig No: 2.5.1 Server Structure Diagram


2.5.2 CLIENT STRUCTURE DIAGRAM

2.5.2 Client Structure Diagram


Chapter

33.Alternate Design

3.1 Alternate Designs

We can also use TCP protocol instead of UDP protocol, but it will involve additional overhead.

3.2 Design Evaluation Report

N/A

3.3 Design Limitations

TFTP supports only 32 MB of data transfer.


Chapter

44.Detailed Design

4.1 TFTPO CLIENT

4.1.1 Detailed Data Design

4.1.1.1 Data Structure (Struct request_type)

Table 4-4: Field Description Table1

Field Name Field Description Size (bytes)

Request Determines read or write request.

2

Mode Determine which mode is to used for transfer(Netascii or Octet)

2

Timeout Set time limit for Packet transfer 2

Blocksize Determine the size of data packet

2

Filename Stores filename 32


4.1.1.2 Data Structure (Struct option_acknowledgement)



Timeout Time duration in which packet

Is sent

2

opcode Acknowledgement is within time or not

2

Blocksize Determine size of each block 2

4.1.1.3 Data Structure (Struct datapacket)



Opcode Shows which type of request 2

Blockno Determine block no 2

Data Data to be sent or recieved 1024

4.1.1.4 Data Structure (Struct error)



Opcode Shows which type of error 2

Msg Stores error message 1024


4.1.1.5 Data Structure (Struct acknowledgment)



opcode Shows which type of request 2

blockno Shows block no 1024

4.1.1.6 MACROS

Macros Name Desciption Values

BUFFERSIZE Size of buffer in which data is read

1024

FLENAMESIZE Size of name of file 32SERVER_PORT Port number on which application

is running1112

BLOCKSIZE Size of block 512TIMEOUT Time duration 5SUCCESS Successful execution 0FAILURE Execution failure 1O_WRITE Option for write 1O_READ Option for read 2O_DATA Option for data 3O_ACK Option for acknowlegdement 4O_ERROR Option for error 5O_OACK Option Acknowlegdement 6



4.1.2 Detailed Module Design

Prototype Int main(int,char *[])

Purpose/

Description

Creatiion of socket,connect to server,taking user input and calls differents function according to user input.

Pre-requisites

The server should be ready to serve incoming client connections.

Input(s) Command Line Arugumets i.e it is taking number of arguments and array of character pointers.(IP address of server).

Output(s) Implementation of required functionality of client

Return Value(s)

SUCCESS OR FAILURE

Called By NONE.

Calls readFile,WriteFile,write_process,read_process ,alarm_alert

Pseudocode:-

int main(int C, char *V[]){

Signal();//generating alarm for timeoutSocket(); // creating UDP socketinput(); // taking user input( request,mode,options,filename)sendto(); // sending request packet to server

if ( request == 1) //write request {

open();//opening file close(); //closing file

}Sendto(); // sending request packet to server


Recvfrom(); // receive from server either error packet or requested packetIf( error pakcet received){

Display(); // display error message}Elseif(option_acknowlegdement){

Recvfrom();//receive from server all the options}Alarm(); // generating alarmIf( request == 2) //read request{

Read_process(); // processing read request }elseif(request == 1) // write request{

Write_process(); // processing write request }

Else{ Display error message for wrong request;}

Return SUCCESS;}

Prototype Int readFile(int,int,int,char *, RRQ_WRQ)

Purpose/

Description

Reads socket and write in the file descriptor

Pre-requisites The server should be ready to serve incoming client connections.

Input(s) Socket descriptor ,File descriptor,bytes to be read,buffer,packet

Output(s) Reads the socket

Return Value(s)

SUCCESS OR FAILURE

Called By Main()

Calls NONE



Pseudocode:-

int readFile(int sd, int fd, int bytes_read ,char *buf, RRQ_WRQ packet)

{ If(netascii_mode)

{

While(no_of_bytes < bytes_read)

{

If(buf[no_of_bytes] == ‘\r’)

{

No_of_bytes ++;

Else

{

Write(fd,&buf[no_of_bytes],1);

No_of_bytes ++;

}

}

}

Else

{

Write(); // writing data to file in octet mode

}

Return SUCCESS OR FAILURE;

}


Prototype int WriteFile(int ,char *,RRQ_WRQ )

Purpose/

Description

Implementing WRQ

Pre-requisites


Input(s) Socket descriptor ,address of client structure,client length,request pakcet

Output(s) Writing on file existing on server

Return Value(s)

No of bytes to be written in socket

Called By Main()

Calls NONE

Pseudocode:-

Int WriteFile(int fd, char *sendbuffer ,RRQ_WRQ packet){ If(netascii mode)

{Read(); // reading data from file byte by byte and storing it in sendbuffer

}Else

{no_of_bytes= read(); // reading in octet mode and storing it in sendbuffer

}Return no_of_bytes;

}



Prototype int read_process(int,struct sockaddr_in *,socket_length,RRQ_WRQ * )

Purpose/

Description

Implementing RRQ

Pre-requisites



Output(s) Reading of file existing on server

Return Value(s)

SUCCESS or FAILURE

Called By Main()

Calls readFile

Pseudocode:-

Int read_process(int sd,struct sockaddr_in *serveraddress,socket_t length,RRQ_WRQ *packet){

Open(); // opening file Sendto(); // sending acknowlegdement packet for read requestAlarm(); // setting timeoutWhile( !last_packet){

If(last_packet ==1){

Close(); // closing file descriptorReturn Failure;

}Recvfrom(); // receiving first data packet from serverSendto(); // sending acknowledge packet along with blockno of next packetIf( blocksize > packet.data){

Last_pakcet=1;}readFile(); // Reads socket and write in the file descriptorclose(); // closing file descriptorReturn SUCCESS;


Prototype Int write_process(int,structsockaddr_in *,socket_length,RRQ_WRQ * )

Purpose/

Description

Implementing WRQ

Pre-requisites



Output(s) Writing data to socket

Return Value(s)

SUCCESS or FAILURE

Called By Main()

Calls WriteFile

Pseudocode:-

Int write_process(int sd,struct sockaddr_in *serveraddress,socket_t length,RRQ_WRQ *packet){

Open(); // opening fileWhile( !last_packet){

If(alarm_alert){

Close(); // closing file descriptorReturn Failure;

}writeFile(); // Writing on file existing on serverIf( blocksize > packet.data){

Last_pakcet=1;}Sendto(); // sending data for writingRecvfrom(); // receiving ack packet from serverClose(); //closing file descriptor



Return SUCCESS;}

4.2 TFTPO SERVER

4.2.1 Detailed Data Design

4.2.1.1 Data Structure (Struct request_type)



Request Determines read or write request.

2

Mode Determine which mode is to used for transfer(Netascii or Octet)

2

Timeout Set time limit for Packet transfer 2

Blocksize Determine the size of data packet

2

Filename Stores filename 32

4.2.1.2 Data Structure (Struct option_acknowledgement)



Timeout Time duration in which packet

Is sent

2

opcode Acknowledgement is within time or not

2


Blocksize Determine size of each block 2

4.2.1.3 Data Structure (Struct datapacket)



Opcode Shows which type of request 2

Blockno Determine block no 2

Data Data to be sent or recieved 1024

4.2.1.4 Data Structure (Struct error)



Opcode Shows which type of error 2

Msg Stores error message 1024

4.2.1.5 Data Structure (Struct acknowledgment)



opcode Shows which type of request 2

blockno Shows block no 1024



4.2.1.6 MACROS

Macros Name Desciption Values

PACKETSIZE Size of packet 512 BUFFERSIZE Size of buffer in which data is

read1024

FLENAMESIZE Size of name of file 32MYPORT Port number on which application

is running11111

4.2.2 Detailed Module Design

Prototype

Int main()

Purpose/

Description

Creatiion of socket,binding, and calls differents function .

Pre-requisites

NONE

Input(s) NONE

Output(s) Performing client request

Return Value(s)

SUCCESS OR FAILURE

Called By NONE

Calls concurrent_server


Pseudocode:-

int main(int C, char *V[]){

Socket(); // creating UDP socketBind(); // binding to socket

For(; ;) {

Pthread_create(); // creating threads to accept request from client.Pthread_join(); // waiting for thread to terminate

}

Return SUCCESS;}

Prototype

Void* concurrent_server(void*)

Purpose/

Description

Accpeting request from client and provide service

Pre-requisites

NONE

Input(s) Socket descriptor

Output(s) Accepting client request

Return Value(s)

NULL

Called By Main

Calls Read_process,write_process,get_port



Pseudocode:-

Void* concurrent_server(void* sd)

{

Recvfrom( );//receiving request packet from client

If(request == 0)

{

Pthread_exit(); // wrong request thread exiting;

}

Pthread_mutex(); // locking thread for crtical section

Get_port(); // generating port randomly

Socket(); // socket descriptor

Bind(); // binding port to socket

Pthread_mutex_unlock();

Pthread_detach(); // creating detach thread

If(read request)

{

Pthread_mutex_lock(); // locking thread for crtical section

Open(); // opening file descriptor

If(file cant open)

{

Sendto(); // error message to client


Pthread_exit();

}

Else

{

Close(); // closing file descriptor


Sendto(); // sending ack packet to client

}


Elseif( write request)

{

Pthread_mutex_lock();

Sendto(); // sending ack packet


}

If( read_request)

{


Read_process(); // processing read request


}

Elseif(write request)

{


Write_process(); // processing write request


}

Else

{

Display(); //wrong option entered by client

}

Close(); // close socket descriptor

Pthread_exit();

}



Prototype Intread_process(int,structsockaddr_in*,socket_length,char *,RRQ_WRQ * )

Purpose/

Description

Implementing RRQ

Pre-requisites

NONE

Input(s) Socket descriptor ,address of client structure,client length,filename,request pakcet

Output(s) Writing data to socket

Return Value(s)

SUCCESS or FAILURE

Called By Main()

Calls WriteFileBuffer

Pseudocode:-

int read_process(int n_sd,struct sockaddr_in *cliaddr,socket_length length,char* file,RRQ_WRQ * packet)

{

Open(); // opening file

While(! Last_packet)

{

If(g_alarm_alert)

{

Close(); // close file descriptor

Return FAILURE;


}

WriteFileBuffer(); // Writing data of file to buffer

If( block_size > bytes_written)

{

Last_packet=1;

}

Recvfrom(); //recive ack packet

Sendto(); // sending data packet


Return SUCCESS;

}

Prototype Int write_process(int,structsockaddr_in *,socket_length,RRQ_WRQ * )

Purpose/

Description

Implementing WRQ

Pre-requisites

NONE


Output(s) Writing data from socket to file

Return Value(s)

SUCCESS or FAILURE

Called By Main()

Calls WriteFileServer



Pseudocode:-

Int write_process(int n_sd,structsockaddr_in *cliaddr ,socket_t length,RRQ_WRQ * packet)

{

Open(); //open file send by client

If( file not exist)

{

Return FAILURE;

}

While( ! last_packet)

{

If(g_alarm_alert)

{


}

Recvfrom() // receiving data from client for writing

If( block_size > bytes_tobe_written)

{

Last_packet=1;

}

Sendto(); // sending ack packet to client

WriteFileServer(); //Writing data of buffer in the file

Close(); // closing file

Return SUCCESS;

}


Prototype Int get_port()

Purpose/

Description

Generating port

Pre-requisites

NONE

Input(s) NONE

Output(s) Return port

Return Value(s)

port

Pseudocode:-

Int get_port()

{

Srand(time(0)); // generating port randomly;

Return port;

}

Prototype Int writeFileBuffer(int,RRQ_WRQ)

Purpose/

Descriptionwriting content of the requested file in buffer

Pre-requisites NONE

Input(s) File descriptor , request packet



Output(s) Writing data of file to buffer

Return Value(s)

Number of bytes read

Called By Concurrent_server

Calls NONE

Pseudocode:-

int writeFileBuffer (int fd,RRQ_WRQ packet)

{

If (netascii_mode)

{

Reading data in netascii mode

}

Else

{

Read( ); //Receiving data in octet mode

}

Return num_of_bytes;

}

Prototype Int writeFileServer(int, int,int,char *,RRQ_WRQ)

Purpose/

DescriptionWriting content of socket in file


Pre-requisites NONE

Input(s) Socket descriptor,file descriptor,bytes_read,buffer,request packet

Output(s) Writing data of buffer in the file

Return Value(s)

Return SUCCESS or FAILURE

Called By Concurrent_server

Calls NONE

Pseudocode:-

Int writeFileServer (int sd,int fd,int bytes_read,char *buf,RRQ_WRQ packet)

{

If(netascii_mode)

{

Writing data in netascii mode

}

else

{

Write ( ); //writing data in octet mode

}

Return SUCCESS or FAILURE

}


Chapter

55.System Issues

5.1 Performance

N/A

5.2 Scalability

Scalable system as more options can be added if required.

5.3 System sizing

N/A

5.4 Logging

N/A


tftp design doc_1.1

Documents