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 Aricents 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
Revisio n No. 1.0 1.1 Date Description of Change N/A Description aboout mode of transfer and multi client support in HLD has been added. Author Reviewed & Approved By TB
8-09-12 12-09-12
Aayush Kumar Harsh Kumar
ARICENT: ARICENT CONFIDENTIAL
Contents
CHAPTER 1: 1. INTRODUCTION________________________________________________5 1.1 PURPOSE....................................................................................................... 5 1.2 SCOPE........................................................................................................... 5 1.3 DEFINITIONS AND ACRONYMS..........................................................................6 1.3.1 Definitions.................................................................................................. 6 1.3.2 Acronyms.................................................................................................. 6 1.4 REFERENCES................................................................................................. 6 1.5 DOCUMENT ORGANIZATION.............................................................................6 1.6 TYPOGRAPHICAL CONVENTIONS (OPTIONAL)....................................................7 1.7 APPROVALS AND AUTHORIZATIONS..................................................................7 1.8 DISTRIBUTION................................................................................................7 2. HIGH LEVEL DESIGN___________________________________________9 2.1 LEVEL 0 DESIGN DESCRIPTION.......................................................................9 2.1.1 Interface Description ................................................................................9 2.2 LEVEL 1 DESIGN DESCRIPTION ....................................................................10 2.2.1 Module name (Level 0)............................................................................10 2.2.1.1 Decomposition Description---------------------------------------------------------10 2.2.1.1.1 Module Description ---------------------------------------------------------------11 2.2.1.1.2 Process Description --------------------------------------------------------------12 2.2.1.2 Interface Description ----------------------------------------------------------------12 2.2.1.2.1 Process Interface ------------------------------------------------------------------12 2.2.1.3 Dependency Description------------------------------------------------------------12 2.2.2 Module 2 (level x-1) ................................................................................12 2.3 LEVEL 2 DESIGN DESCRIPTION.....................................................................12 2.4 CONTROL FLOW SCENARIO...........................................................................13 2.5 STRUCTURE DIAGRAM..................................................................................18 2.5.1 SERVER STRUCTURE DIAGRAM.........................................................18 2.5.2 CLIENT STRUCTURE DIAGRAM...........................................................19 3. ALTERNATE DESIGN __________________________________________21 3.1 ALTERNATE DESIGNS....................................................................................21 3.2 DESIGN EVALUATION REPORT.......................................................................21 3.3 DESIGN LIMITATIONS....................................................................................21 4. DETAILED DESIGN____________________________________________23 4.1 TFTPO CLIENT.......................................................................................... 23 4.1.1 Detailed Data Design .............................................................................23 4.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 datapacket)--------------------------------------------24 4.1.1.4 Data Structure (Struct error)----------------------------------------------------24 4.1.1.5 Data Structure (Struct acknowledgment)-----------------------------------25 4.1.1.6 MACROS---------------------------------------------------------------------------25 4.1.2 Detailed Module Design .........................................................................26 PSEUDOCODE:-................................................................................................. 26 PSEUDOCODE:-................................................................................................. 28 INT READFILE(INT SD, INT FD, INT BYTES_READ ,CHAR *BUF, RRQ_WRQ PACKET) 28 PSEUDOCODE:-................................................................................................. 29 PSEUDOCODE:-................................................................................................. 30 PSEUDOCODE:-................................................................................................. 31
1
CHAPTER 2:
CHAPTER 3:
CHAPTER 4:
SOFTWARE DESIGN DOCUMENT ARICENT CONFIDENTIAL
4.2 TFTPO SERVER........................................................................................ 32 4.2.1 DETAILED DATA DESIGN..........................................................................32 4.2.1.1 Data Structure (Struct request_type)--------------------------------------32 4.2.1.2 Data Structure (Struct option_acknowledgement)-------------------------32 4.2.1.3 Data Structure (Struct datapacket)--------------------------------------------33 4.2.1.4 Data Structure (Struct error)----------------------------------------------------33 4.2.1.5 Data Structure (Struct acknowledgment)-----------------------------------33 4.2.1.6 MACROS----------------------------------------------------------------------------34 4.2.2 Detailed Module Design.........................................................................34 CHAPTER 5: 5. SYSTEM ISSUES______________________________________________45 5.1 PERFORMANCE ........................................................................................... 45 5.2 SCALABILITY................................................................................................. 45 5.3 SYSTEM SIZING............................................................................................ 45 5.4 LOGGING .................................................................................................... 46
Tables
CHAPTER 6: CHAPTER 7: CHAPTER 8: CHAPTER 9:
TABLE 1-1: ACRONYMS USED IN THIS DOCUMENT____________________6 TABLE 1-1: ACRONYMS USED IN THIS DOCUMENT____________________6 TABLE 1-2: APPROVALS AND AUTHORIZATIONS_____________________7 TABLE 1-2: APPROVALS AND AUTHORIZATIONS_____________________7
CHAPTER 10: TABLE 1-3: DISTRIBUTION________________________________________7 CHAPTER 11: TABLE 1-3: DISTRIBUTION________________________________________7 CHAPTER 12: TABLE 4-4: FIELD DESCRIPTION TABLE1___________________________23 CHAPTER 13: TABLE 4-4: FIELD DESCRIPTION TABLE1___________________________23 CHAPTER 14: TABLE 4-2: FIELD DESCRIPTION TABLE2___________________________24 CHAPTER 15: TABLE 4-3: FIELD DESCRIPTION TABLE3___________________________24 CHAPTER 16: TABLE 4-4: FIELD DESCRIPTION TABLE4___________________________24 CHAPTER 17: TABLE 4-5: FIELD DESCRIPTION TABLE5___________________________25 CHAPTER 18: TABLE 4-7: FIELD DESCRIPTION TABLE7___________________________32 CHAPTER 19: TABLE 4-8: FIELD DESCRIPTION TABLE8___________________________33 CHAPTER 20: TABLE 4-9: FIELD DESCRIPTION TABLE9___________________________33 CHAPTER 21: TABLE 4-10: FIELD DESCRIPTION TABLE10_________________________33 23 Table Table Table Table Table Table Table Table Table 4-2: Field Description Table 2.. 24 4-3: Field Description Table 3...24 4-4: Field description Table 425 4-5:Field Description Table 525 4-6:Field Description Table 632 4-7: Field Description Table 7.. 32 4-8: Field Description Table 8...33 4-9: Field description Table 933 4-10:Field Description Table 1033
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 Scope
TFTPO 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.
1.3 Definitions and Acronyms

1.3.1 Definitions
N/A
1.3.2 Acronyms
Table 1-1: Acronyms Used in this Document
Acronym RRQ TFTPO TIDs UDP WRQ Explanation Read Request Trivial File Transfer Protocol with options Transfer identifiers User Datagram Protocol 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

# 1 2 3 4 5 Chapter Introduction High Level Design Alternate Design Detailed design System Issues Contents Introductory information for the entire Project and Design Document Explains the context of the system, and gives an overview of required functionality Specifies any constraints and mentions choice of design over alternate design options The low level design that can translate to code is detailed 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 Approved by Authorized by Quality Co-ordinator Engineering Manager Name <Name> <Name> Date <dd/mm/yyyy> <dd/mm/yyyy>
1.8 Distribution
Table 1-3: Distribution
Copy No. 1 2 3 4 Holders Designation Engineering Manager Project Co-ordinator Quality Co-ordinator Team members Issue Date <dd/mm/yyyy> <dd/mm/yyyy> <dd/mm/yyyy> <dd/mm/yyyy>
Chapter
2
2.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.
2.2 Level 1 Design Description
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.
10
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. Server Server 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.
11
TRIVIAL FILE TRANSFER PROTOCOL
WITH OPTIONS
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
2.3 Level 2 Design Description

N/A
12
2.4 Control Flow Scenario
Fig. 2.4.1 Normal Processing
13
WITH OPTIONS
Fig. 2.4.2. Acknowledgement timed out
14
Fig 2.4.3. Data Timed out.
Fig 2.4.4 normal Connection Termination.
15
WITH OPTIONS
16
Fig 2.4.5 Premature Termination.
17
WITH OPTIONS
2.5 Structure Diagram
2.5.1 SERVER STRUCTURE DIAGRAM
server
IP address, P ort no S ock et descriptor
bind
R R Q_WR Q pack et
C oncurrent server (thread)

S ock et descriptor , F ile descriptor , Buffer ,P acket
Bytes written F ile des criptor, P acket
Recvfrom
Write file
Read file
Fig No: 2.5.1 Server Structure Diagram
18
2.5.2 CLIENT STRUCTURE DIAGRAM
Port
Client
S ocket server
Get port
status
S end receive data Ack packet Ack packet
Get connection Get packet S end ack S end data Receive data
Formpacket Ack packet request
Receive Request
Get packet
F ormdata packet S end Request
2.5.2 Client Structure Diagram
19
Chapter
3
3.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.
21
Chapte r
4
4.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 Request Mode Field Description Determines read or write request. Determine which mode is to used for transfer(Netascii or Octet) Set time limit for Packet transfer Size (bytes) 2 2
Timeout
23
Blocksize Filename
Determine the size of data packet Stores filename
2 32
4.1.1.2 Data Structure (Struct option_acknowledgement)

Field Name Timeout opcode Blocksize Field Description Time duration in which packet Is sent Acknowledgement is within time or not Determine size of each block 2 2 Size (bytes) 2
4.1.1.3
Data Structure (Struct datapacket)

Field Name Opcode Blockno Data Field Description Shows which type of request Determine block no Data to be sent or recieved Size (bytes) 2 2 1024
4.1.1.4
Data Structure (Struct error)

Field Name Opcode Msg Field Description Shows which type of error Stores error message Size (bytes) 2 1024
24
4.1.1.5
Data Structure (Struct acknowledgment)

Field Name opcode blockno Field Description Shows which type of request Shows block no Size (bytes) 2 1024
4.1.1.6
Macros Name BUFFERSIZE FLENAMESIZE SERVER_PORT BLOCKSIZE TIMEOUT SUCCESS FAILURE O_WRITE O_READ O_DATA O_ACK O_ERROR O_OACK
MACROS
Desciption Size of buffer in which data is read Size of name of file Port number on which application is running Size of block Time duration Successful execution Execution failure Option for write Option for read Option for data Option for acknowlegdement Option for error Option Acknowlegdement Values 1024 32 1112 512 5 0 1 1 2 3 4 5 6
25
WITH OPTIONS
4.1.2 Detailed Module Design
Prototype
Int main(int,char *[])
Purpose/ Description Prerequisites Input(s) Output(s) Return Value(s) Called By Calls
Creatiion of socket,connect to server,taking user input and calls differents function according to user input. The server should be ready to serve incoming client connections. Command Line Arugumets i.e it is taking number of arguments and array of character pointers.(IP address of server). Implementation of required functionality of client SUCCESS OR FAILURE NONE. readFile,WriteFile,write_process,read_process ,alarm_alert
Pseudocode:int main(int C, char *V[]) { Signal();//generating alarm for timeout Socket(); // creating UDP socket input(); // 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 packet
26 ARICENT: ARICENT CONFIDENTIAL
If( error pakcet received) { Display(); // display error message } Elseif(option_acknowlegdement) { Recvfrom();//receive from server all the options } Alarm(); // generating alarm If( 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; }
Int readFile(int,int,int,char *, RRQ_WRQ)
Prototype
Purpose/ Description Pre-requisites Input(s) Output(s) Return Value(s) Called By Calls
Reads socket and write in the file descriptor The server should be ready to serve incoming client connections. Socket descriptor ,File descriptor,bytes to be read,buffer,packet Reads the socket SUCCESS OR FAILURE Main() NONE
27
WITH OPTIONS
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; }
28
Prototype
int WriteFile(int ,char *,RRQ_WRQ )
Implementing WRQ The server should be ready to serve incoming client connections. Socket descriptor ,address of client structure,client length,request pakcet Writing on file existing on server No of bytes to be written in socket Main() 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; }
29
WITH OPTIONS
Prototype
int read_process(int,struct sockaddr_in *,socket_length,RRQ_WRQ * )
Implementing RRQ The server should be ready to serve incoming client connections. Socket descriptor ,address of client structure,client length,request pakcet Reading of file existing on server SUCCESS or FAILURE Main() 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 request Alarm(); // setting timeout While( !last_packet) { If(last_packet ==1) { Close(); // closing file descriptor Return Failure; } Recvfrom(); // receiving first data packet from server Sendto(); // sending acknowledge packet along with blockno of next packet If( blocksize > packet.data) { Last_pakcet=1; } readFile(); // Reads socket and write in the file descriptor
close(); // closing file descriptor
Return SUCCESS;
30
Prototype
Int write_process(int,structsockaddr_in *,socket_length,RRQ_WRQ * )
Implementing WRQ The server should be ready to serve incoming client connections. Socket descriptor ,address of client structure,client length,request pakcet Writing data to socket SUCCESS or FAILURE Main() WriteFile
Pseudocode:-
Int write_process(int sd,struct sockaddr_in *serveraddress,socket_t length,RRQ_WRQ *packet) { Open(); // opening file While( !last_packet) { If(alarm_alert) { Close(); // closing file descriptor Return Failure; } writeFile(); // Writing on file existing on server If( blocksize > packet.data) { Last_pakcet=1; } Sendto(); // sending data for writing Recvfrom(); // receiving ack packet from server Close(); //closing file descriptor Return SUCCESS;
WITH OPTIONS
4.2 TFTPO SERVER

4.2.1 Detailed Data Design
4.2.1.1 Data Structure (Struct request_type) Table 4-6: Field Description Table6
Field Name Request Mode Field Description Determines read or write request. Determine which mode is to used for transfer(Netascii or Octet) Set time limit for Packet transfer Determine the size of data packet Stores filename Size (bytes) 2 2
Timeout Blocksize Filename
2 2 32
4.2.1.2 Data Structure (Struct option_acknowledgement)

Field Name Timeout opcode Blocksize
32
Field Description Time duration in which packet Is sent Acknowledgement is within time or not Determine size of each block
Size (bytes) 2 2 2
4.2.1.3
Data Structure (Struct datapacket)

Field Name Opcode Blockno Data Field Description Shows which type of request Determine block no Data to be sent or recieved Size (bytes) 2 2 1024
4.2.1.4
Data Structure (Struct error)

Field Name Opcode Msg Field Description Shows which type of error Stores error message Size (bytes) 2 1024
4.2.1.5
Data Structure (Struct acknowledgment)

Field Name opcode blockno Field Description Shows which type of request Shows block no Size (bytes) 2 1024
33
WITH OPTIONS
4.2.1.6
Macros Name PACKETSIZE BUFFERSIZE FLENAMESIZE MYPORT
MACROS
Desciption Size of packet Size of buffer in which data is read Size of name of file Port number on which application is running Values 512 1024 32 11111
4.2.2 Detailed Module Design
Int main() Prototype
Creatiion of socket,binding, and calls differents function . NONE NONE Performing client request SUCCESS OR FAILURE NONE concurrent_server
34
Pseudocode:-
int main(int C, char *V[]) { Socket(); // creating UDP socket Bind(); // binding to socket For(; ;) { Pthread_create(); // creating threads to accept request from client. Pthread_join(); // waiting for thread to terminate } Return SUCCESS; }
Void* concurrent_server(void*) Prototype
Accpeting request from client and provide service NONE Socket descriptor Accepting client request NULL Main Read_process,write_process,get_port
35
WITH OPTIONS
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_mutex_unlock(); Pthread_exit(); } Else { Close(); // closing file descriptor Sendto(); // sending ack packet to client } Pthread_mutex_unlock();
Elseif( write request) {
Pthread_mutex_lock(); Sendto(); // sending ack packet Pthread_mutex_unlock(); } If( read_request) { Pthread_mutex_lock(); Read_process(); // processing read request Pthread_mutex_unlock(); } Elseif(write request) { Pthread_mutex_lock(); Write_process(); // processing write request Pthread_mutex_unlock(); } Else { Display(); //wrong option entered by client } Close(); // close socket descriptor Pthread_exit(); }
37
WITH OPTIONS
Prototype
Intread_process(int,structsockaddr_in*,socket_length,char *,RRQ_WRQ * )
Implementing RRQ NONE Socket descriptor ,address of client structure,client length,filename,request pakcet Writing data to socket SUCCESS or FAILURE Main() 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
38
If( block_size > bytes_written) { Last_packet=1; } Recvfrom(); //recive ack packet Sendto(); // sending data packet Close(); // close file descriptor Return SUCCESS; }
Prototype
Int write_process(int,structsockaddr_in *,socket_length,RRQ_WRQ * )
Implementing WRQ NONE Socket descriptor ,address of client structure,client length,request pakcet Writing data from socket to file SUCCESS or FAILURE Main() WriteFileServer
39
WITH OPTIONS
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) { Close(); // close file descriptor } 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; }
40
Prototype
Int get_port()
Purpose/ Description Prerequisites Input(s) Output(s) Return Value(s)
Generating port NONE NONE Return port port
Pseudocode:Int get_port() { Srand(time(0)); // generating port randomly; Return port; }
Prototype
Int writeFileBuffer(int,RRQ_WRQ)
Purpose/ Description Pre-requisites Input(s) Output(s) Return Value(s) Called By

41
writing content of the requested file in buffer NONE File descriptor , request packet Writing data of file to buffer Number of bytes read Concurrent_server
WITH OPTIONS
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/ Description Pre-requisites Input(s) Output(s) Return Value(s)

42
Writing content of socket in file NONE Socket descriptor,file descriptor,bytes_read,buffer,request packet Writing data of buffer in the file Return SUCCESS or FAILURE
Called By Calls
Concurrent_server 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 }
43
Chapter
5
5.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
45
5.4 Logging
N/A
46
47

TFTP Design Doc - 1.1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TFTP Design Doc - 1.1

Uploaded by

Copyright:

Available Formats

Trivial File Transfer Protocol with Options

Software Design Document

ARICENT: Revision Number: 1.1

Aayush Kumar Harsh Kumar

ARICENT: ARICENT CONFIDENTIAL

SOFTWARE DESIGN DOCUMENT ARICENT CONFIDENTIAL

SOFTWARE DESIGN DOCUMENT ARICENT CONFIDENTIAL

CHAPTER 6: CHAPTER 7: CHAPTER 8: CHAPTER 9:

SOFTWARE DESIGN DOCUMENT ARICENT CONFIDENTIAL

SOFTWARE DESIGN DOCUMENT ARICENT CONFIDENTIAL

1.3 Definitions and Acronyms

1.5 Document Organization

SOFTWARE DESIGN DOCUMENT ARICENT CONFIDENTIAL

1.6 Typographical Conventions (Optional)

1.7 Approvals and Authorizations

ARICENT: ARICENT CONFIDENTIAL

Fig 2.1 Level 0 DFD

2.1.1 Interface Description

SOFTWARE DESIGN DOCUMENT ARICENT CONFIDENTIAL

2.2 Level 1 Design Description

Fig 2.2 Level 1 Design Description

2.2.1 Module name (Level 0)

SOFTWARE DESIGN DOCUMENT ARICENT CONFIDENTIAL

ARICENT: ARICENT CONFIDENTIAL

TRIVIAL FILE TRANSFER PROTOCOL

2.2.2 Module 2 (level x-1)

2.3 Level 2 Design Description

ARICENT: ARICENT CONFIDENTIAL

2.4 Control Flow Scenario

Fig. 2.4.1 Normal Processing

ARICENT: ARICENT CONFIDENTIAL

TRIVIAL FILE TRANSFER PROTOCOL

Fig. 2.4.2. Acknowledgement timed out

ARICENT: ARICENT CONFIDENTIAL

Fig 2.4.3. Data Timed out.

Fig 2.4.4 normal Connection Termination.

ARICENT: ARICENT CONFIDENTIAL

TRIVIAL FILE TRANSFER PROTOCOL

ARICENT: ARICENT CONFIDENTIAL

Fig 2.4.5 Premature Termination.

ARICENT: ARICENT CONFIDENTIAL

TRIVIAL FILE TRANSFER PROTOCOL

2.5 Structure Diagram

2.5.1 SERVER STRUCTURE DIAGRAM

C oncurrent server (thread)

Fig No: 2.5.1 Server Structure Diagram

ARICENT: ARICENT CONFIDENTIAL

2.5.2 CLIENT STRUCTURE DIAGRAM

S end receive data Ack packet Ack packet

Formpacket Ack packet request

F ormdata packet S end Request

2.5.2 Client Structure Diagram

ARICENT: ARICENT CONFIDENTIAL

3.2 Design Evaluation Report

3.3 Design Limitations

SOFTWARE DESIGN DOCUMENT ARICENT CONFIDENTIAL

Table 4-4: Field Description Table1

SOFTWARE DESIGN DOCUMENT ARICENT CONFIDENTIAL

Determine the size of data packet Stores filename

4.1.1.2 Data Structure (Struct option_acknowledgement)

Table 4-2: Field Description Table2

Data Structure (Struct datapacket)

Table 4-3: Field Description Table3

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

Int write_process(int,structsockaddr_in ,socket_length,RRQ_WRQ )

Int write_process(int,structsockaddr_in ,socket_length,RRQ_WRQ )