Week 7: A case study: Design and Implementation of TFTP

Module 6 and Chapter 12 of UNP1e

• how network protocols are defined by finite state machines • how to implement network finite state machine • how to make the overall modular design for network applications • how to design
– network support modules, – user interface modules and – file system modules

Interactive applications
• Interactive programs are constantly interacting with the outside through communication to provide services and they normally run as long as the services are need. • The centre is an infinite loop with the loop body to receive the communication events and act on them according to a protocol.
for (; ; ) { receive an event; process the event with corresponding action; }

• Interactive network applications can be best described through an abstract machine model called Finite State Machine (FSM). • The action to process an event depends on the event itself and the current state of the application. • There can be many states in which the application can be used. FSM • When no event occurs. A state is defined by the value of a collection of variables of the program and used to represent a certain history of the execution.Interactive Network application vs. the program blocks on the receiving statement until the next event occurs. .

A. .Finite States Machines • What is a FSM – A FSM is a 6-tuple: FSM =<S. • f: S × E -> S is the transfer function to determine the next state given an event in E and the current state. • FSM representations – A FSM can be defined by a state diagram or – A FSM can be defined by a set of tables for the transfer function f and output function g. events and actions. q0> • where S. respectively. E. f. E and A are the finite sets of states. and q0 is the initial state of the FSM. g. • g: S × E -> A is the output function which defines the action to take given an event in E and the current state.

g(s. a2. q0 = A.a2 B. C}.FSM state diagram S = {A.a2 C.e).e) e1/a3 C e2/a3 . E ={e1.a3 e1/a2 e2/a2 A e2/a1 e1/a1 B f(s.a3 A. a3} q0 S A B C A e1 B.a1 A. B.a1 e2 C. e2} and A = {a1.

– The event set E includes all events from both the user and network • Typical network events are receiving a certain type of packet from a socket • user event arise when the user of the program(most client program) acts on the user interface. S.Network Application protocols • One of the key steps to develop a network application is to identify three sets E. and A. – The actions set A usually includes • sending some types of packet to a socket • issuing system calls on the file system • delivering outputs to the user interface. • usually representing conditions after certain network packets or user command are received. – The state set S should include all states which may last non-zero times. .

g.Developing network applications • Application specification defined in the form RFC includes function f and g. f. – A network application normally requires two different programs for the client and server. q0> of each FSM. • The first step is to translate the application specification into a network protocol in the form of two FSMs for the client and server. E. which are the core of the FSM of a program. each of which is a FSM. – identify the content of each element in the 6-tuple <S. A. . – Two FSMs define the formal protocol of the application.

– both the client and the server can be the sender and receiver. it is a complicated process. . because – we have to ensure the every byte of the file to be delivered to the destination – a separate formal protocol in the form of FSMs for each client and server. • The file transfer is implemented using UDP. – It takes away many features of FTP such as directory listing and authentication from FTP. but concentrates on the file transfer only.TFTP protocol • TFTP is a simplified version of File Transfer Protocol (FTP).

This component requires two FSMs for the client and the server as the formal protocol. . • File Transfer design:. These operations are part of the actions in the FSMs • Network Module design:.This component is responsible for accessing the file systems of the sender and receiver.This is to hide the details of the network operations and provides a higher-level interface to the FSMs for the actions which needs network interactions. respectively. The sender and receiver have to read and write corresponding files. The events considered are only the receiving of the network packets.Design to implement TFTP • User Interface design:. User command put or get starts a file transfer. • File system module design:. It concentrates on the network packets between the server and the receiver for the file transfer.This is used by the client to interact with user.

Overall design for TFTP user interface File transfer Protocol FSM FSM user client FS interface network interface server FS interface File system Network File system .

The following five formats are necessary.Network packet design • To identify the event sets of the FSMs. we need to design the format of the possible network packets between the client and the server. opcode read request (RRQ) write request (WRQ) data acknowledgment (ACK) string EOS string EOS 01 2 bytes filename n bytes 0 1 byte mode n bytes 0 1 byte opcode string EOS string EOS 02 2 bytes filename n bytes 0 1 byte mode n bytes 0 1 byte opcode 03 2 bytes block# 2 bytes n bytes data opcode 04 2 bytes block# 2 bytes opcode error string EOS 05 2 bytes errcode 2 bytes errstring n bytes 0 1 byte .

Its event set E includes the receiving of the five types of packets from the client.FSM for the server • The initial state of the server is STANDBY. standby RRQ/Data(1) WRQ/Ack(0) Data_Sent Ack_Sent ACK(n)/Data(n+1) Data(n)/AcK(n) .

does not belong to the state set of FSM client. INIT (R)/RRQ RRQ_Sent Data(1)/ACK(1) Ack_Sent ERR/RQERR (W)/WRQ WRQ_Sent ACK(0)/DATA(1) Data_Sent EXIT Data(n)/ACK(n) ACK(n)/DATA(n+1) • (R) and (W) are not part of the event set of the FSM.FSM for the client • State INIT is a state of the user interface. They are merely the user interface operations to trigger the FSM to send RRQ and WRQ to the server. .

they need not to appear in the FSM. To add reliability to the transmission. – a time-out is setup when a data packet Data(k) or an acknowledgement ACK(j) is sent – if the corresponding ACK(k) or Data(j+1) is not received within the time-out.Reliability in UDP implementation • Using UDP to implement TFTP could result in the data lose. . the technology of time-out and retransmission need to be used. • The time-out and retransmission can be handled at the code level. the same Data(k) or ACK(j) is retransmitted.

there will be double DATA(k) for all k>=n+1 and double ACK(j) for all j>=n+1 even though there are not time-outs. This problem is called Sorcerer’s apprentice syndrome • The problem with this is double traffic generated if we follow strictly the mechanism of timeout and retransmission. • A simple fix of the problem is to disable sending Data(n+1) after receiving ACK(n) if this ACK(n) is a duplicated one.Sorcerer’s apprentice syndrome • if ACK(n) is received after DATA(n) is retransmitted due to the time-out. .

Sorcerer’s apprentice syndrome send DATA(n) (timeout) retransmit DATA(n) receive ACK(n) send DATA(n+1) receive ACK(n) (dup) send DATA(n+1) (dup) receive ACK(n+1) send DATA(n+2) receive ACK(n+1) (dup) send DATA(n+2) (dup) receive DATA(n) send ACK(n) receive DATA(n) (dup) send ACK(n) (dup) receive DATA(n+1) send ACK(n+1) receive DATA(n+1) (dup) send ACK(n+1) (dup) receive DATA(n+2) (dup) send ACK(n+2) (dup) .

. enter a infinite loop as follows: for (. fsm_ptr.Basic techniques for implementing FSM • Construct a table of function pointers. a special function can be used to indicate the invalidness of reaching this point. • For the undefined pairs of state-event. a 2D array of function pointers • To start the FSM. } • The function called for the action should – call some functions to complete the action – change variable state to reflect the transition to the next state. call function(*fsm_ptr[state][event])(ags…).) { event = receive the input event. . – ie. with – the rows representing the states of the FSM and – the columns representing the events of the FSM.

MAXBUFF)) < 0 ) { net_send(sendbuff. sendlen).FSM: Infinite Loop engine • The code dealing with time-out and retransmission have been taken. continue.. } op_recv = ldshort(recvbuff). if ((*fsm_ptr[op_sent][op_recv])(recvbuff+2. int fsm_loop(int opcode) { op_sent = opcode.) { if ((nbytes = net_recv(recvbuf.nbytes-2) < 0) { } } } . for (.

Function recv_ACK() recv_DATA() recv_RQERR() recv_RRQ() recv_WRQ() used by client and server client and server client only server only server only invoked when an ACK(n) received in valid state a DATA(n) received in valid state a ERROR for RRQ or WRQ is received a RRQ received in state STANDBY a WRQ received in state STANDBY .FSM: Functions for actions and State Transitions • All of them have two arguments: – a char * pointer to the receiver buffer just past the opcode – an int variable for the number of bytes of the remaining data in the buffer.

FSM: Functions for actions and State Transitions • When the client receives the read or write request from the user also need to send RRQ or WRQ packets to the server. Function send_ACK() send_DATA() send_RQ() used by recv_DATA() recv_ACK() the User Interface invoked when send ACK to the DATA received send next DATA after receiving ACK send RRQ or WRQ to the server .

User interface design • • • • main program of client commands dispatch command format and parser command processing .

(*cmd_func)(). } Cmds. cmd_ascii. …………. – docmd() uses it to array commands[] char int search a command dispatch table in typedef struct Cmds { *cmd_name. cmd_connect. …. …. “ascii”. cmd_verbose } . cmd_help. Cmds commands[] = { “?”. “verbose”.Commands dispatch • The argument of docmd() is a character string for the command to execute. “connect”. ………….

net_close(). – The most interesting ones are cmd_get() and cmd_put() for file transfer between the client and server. t_stop(). fsm_loop(OP_RRQ).Commands processing • The 13 command processing functions cmd_xxx(). port) < 0) return. file_close(). locfname). TFTP_SERVICE. remfname. modetype). t_start(). } . send_QR(OP_RPQ. void cmd_get(){ if (gettpken(remfname) == NULL) err_cmd(“”). do_get(remfname. } void do_get() { if ( file_open() == NULL) { } if (net_open(hostname.

Network support design • Since the client and the server is not symmetric. we need two sets of network operations functions for them • For the client Function net_open() net_close() net_send() net_recv() Purpose create a socket to communicate with the server close the communication socket send a network packet to the server receive a network packet from the server • For the server Function net_initi() net_open() net_close() net_send() net_recv() Purpose initialize the network connection for the server receive the first packet from a client and fork a child close the communication socket send a network packet to the client receive a network packet from the client .

• These functions themselves are implemented by using the file systems call such as read() and write in Unix OS.File system module design • This module would include many file system functions at a level higher than the file system calls. the rest of application is system-independent. – This makes the port of the same application from one OS to another easy. • The file system module is system-dependent. .

Functions File_open() File_close() File_read() File_write purpose Open a local file for reading and writing Close an opened file Read data from file into buffer Write data from buffer to file .Four functions for file system module They are used by both the client and server.

• The Jacobson/Karel model for timeout and retransmission will be used (details can be found in Module 8). . • The client and server expect to receive the SIGALRM signal generated by the timeout.Reliability design • UDP implementation must use the technique of timeout and retransmission to ensure the reliability required.

reset tout_flag and set the timeout clock with timeout value returned by rtt_start(). • Set the SIGALRM signal handler to be func_timeout() which set tout_flag. func_timeout). statements Signal(SIGALRM. Tout_flag = 0.. .Reliability module design • In the beginning of each iteration of for(.) loop. Alarm(rtt_start(&rttinfo)).

Rtt_init() Rtt_newpack() Rtt_start() Rtt_stop() Rtt_timeout() Initialize the values in argument rttinfo Initialize retransmit counter to 0 Calculate and return the timeout value Calculate RTT and update the values in rttinfo Increment retransmit counter.Jacobsob/Karel model • rtt_xxx() functions for timeout and retransmission. return -1 if it exceeds limit .

c file.c cmdgetput.c cmdsubr.c maincli.c netudp.c initvars.c fsm.UDP Implementation • The TFTP program consists of – a client program – a server program • The files for UPD version Filename cmd.c mainserv.c sendrecv.c yes yes Client yes yes yes yes yes yes yes Server Notes only client processes user commands only client processes user commands only client processes user commands yes yes yes client and server file I/O finite state machine to drive system initialize all global variables client main program server main program client and server network I/O .UDP client and server TFTP functions yes yes yes .

netudp. . we can easily replace them with functions that use another protocol.c file • This file defines five functions that are used by both client and server function net_init net_open net_close net_send net_recv Notes initialize a network connection (server only) open a network connection close a network connection send a packet receive a packet • By using these functions in the TFTP functions.

char **argv) { while () { for () { // process options // turn on some flags } do { // open each given files // mainloop: process a given file } } // read more } .maincli.c file void main(int argc.

– This allows the inetd daemon to start another read on the server’s well-known port to process the next request from some other client. the wait mode is specified.Starting the TFTP server • The TFTP server can be started either by – inetd superserver or – independently. – Once the TFTP server has read the datagram from the client on its well-known port. . • The server is started by inetd – When started by the inetd daemon. we want the TFTP server to fork with the parent existing.

TFTP server invoked by inetd select on the well-known port recvfrom on socket when a datagram arrives invoke TFTP server Spwan child process then exit Create new socket bind any local address process client’s request inetd daemon fork exec TFTP server(parent) fork TFTP server(child) initial send to well-known port 1st response from server TFTP client .

– The server must provide the concurrency. Initiate another recvfrom on well-known socket Create new socket bind any local address process client’s request TFTP server(parent) fork TFTP server(child) initial send to well-known port 1st response from server TFTP client . – The TFTP parent must start another recvfrom after a child process is spawned recvfrom on well-known socket Blocks until client request arrives Spwan child process.Starting the TFTP server • The server is started independently of the inetd.

Sign up to vote on this title
UsefulNot useful