Network Clients - Java - page 522

Program: TFTP UDP Client
This program implements the client half of the TFTP application protocol, a once-well-
known service that has been used in the Unix world for network booting of workstations
since before Windows 3.1, now primarily used for network bootstrapping of computers. I
chose this protocol because it's widely implemented on the server side, so it's easy to find a
test server for it.
The TFTP protocol is a bit odd. The client contacts the server on the well-known UDP port
number 69, from a generated port number, [ 42 ] and the server responds to the client from a
generated port number. Further communication is on the two generated port numbers.
Getting into more detail, as shown in Figure 13-1 , the client initially sends a read request
with the filename and reads the first packet of data. The read request consists of two bytes (a
short ) with the read request code (short integer with a value of 1, defined as OP_RRQ), two
bytes for the sequence number, then the ASCII filename, null terminated, and the mode
string, also null terminated. The server reads the read request from the client, verifies that it
can open the file and, if so, sends the first data packet (OP_DATA), and then reads again.
The client reads from its end and, if the read is OK, turns the packet into an acknowledge-
ment packet, and sends it. This read-acknowledge cycle is repeated until all the data is read.
Note that each packet is 516 bytes (512 bytes of data, plus 2 bytes for the packet type and 2
more for the packet number) except the last, which can be any length from 4 (zero bytes of
data) to 515 (511 bytes of data). If a network I/O error occurs, the packet is resent. If a given
packet goes astray, both client and server are supposed to perform a timeout cycle. This cli-
ent does not, but the server does. You could add timeouts either using a thread (see Rendez-
vous and Timeouts ) or by invoking setSoTimeout() on the socket and, if packets do get
lost, catching the SocketTimeoutException , retransmitting the ACK (or RRQ), perhaps up
to some max # of attempts. This is left as an exercise for the reader. The current version of
the client code is shown in Example 13-9 .