134 lines
3.8 KiB
HTML
Executable File
134 lines
3.8 KiB
HTML
Executable File
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
|
|
<!-- TFTP.html (C) K. J. Turner 18/12/14 -->
|
|
|
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
|
|
|
<head>
|
|
|
|
<title>Trivial File Transfer Protocol</title>
|
|
|
|
<link rev="made" href="http://www.cs.stir.ac.uk/~kjt/"/>
|
|
|
|
</head>
|
|
|
|
<body background="simulator.jpeg">
|
|
|
|
<div style="text-align: center">
|
|
|
|
<h1>Trivial File Transfer Protocol Simulator</h1>
|
|
|
|
<img src="simulator.gif" alt="Simulator Logo"/>
|
|
|
|
</div>
|
|
|
|
<h2>Protocol Description</h2>
|
|
|
|
<p>
|
|
TFTP (Trivial File Transfer Protocol) is an elementary file transfer
|
|
protocol that is typically used by a discless workstation to download its
|
|
bootstrap file. TFTP operates over <a href="UDP.html">UDP (User Datagram
|
|
Protocol)</a> and often in conjunction with <a href="BOOTP.html">BOOTP
|
|
(Boot Protocol)</a>.
|
|
</p>
|
|
|
|
<p>
|
|
A client may initially issue:
|
|
</p>
|
|
|
|
<ul>
|
|
|
|
<li>
|
|
<em>RRQ</em>: read request, to retrieve a named file from the server
|
|
</li>
|
|
|
|
<li><em>WRQ</em>: write request, to send a named file to the server</li>
|
|
|
|
</ul>
|
|
|
|
<p>
|
|
During data transfer, the client or server as appropriate sends:
|
|
</p>
|
|
|
|
<ul>
|
|
|
|
<li>
|
|
<em>DATA</em>: with data content numbered D<em>n</em>, the last data
|
|
being labelled <em>Dlast</em>
|
|
</li>
|
|
|
|
<li>
|
|
<em>ACK</em>: an acknowledgement with the same number as the
|
|
<em>DATA</em> being acknowledged
|
|
</li>
|
|
|
|
<li><em>ERROR</em>: to send an error message due to a serious problem</li>
|
|
|
|
</ul>
|
|
|
|
<p>
|
|
<em>DATA</em> blocks are numbered from 1 onwards with just a name
|
|
<em>D</em>n for their data contents. Normally an <em>ACK</em> quotes this
|
|
number, but in the case of <em>WRQ</em> an acknowledgement with number 0
|
|
is sent. All <em>DATA</em> blocks except the last one are full. The final
|
|
block is less than the normal size, shown with contents D<em>last</em>.
|
|
</p>
|
|
|
|
<p>
|
|
The protocol is unusual in that both sender and receiver may time out. If
|
|
one party does not receive a fresh <em>DATA</em> block after sending an
|
|
<em>ACK</em>, it may retransmit the <em>ACK</em> in case it was lost. A
|
|
complication is that the <em>ACK</em> for the last <em>DATA</em> may be
|
|
lost. For this reason, the receiver must wait until it is satisfied that
|
|
data transfer is complete. If decision "presume all transmissions
|
|
over" is made prematurely, the sender will become stuck because it
|
|
cannot obtain the last <em>ACK</em> it needs.
|
|
</p>
|
|
|
|
<p>
|
|
After completing transfer of a file, the client may start a new transfer.
|
|
<em>ERROR</em> messages may be sent in situations such as incorrect
|
|
sequence numbers or local disc errors. The full protocol allows for
|
|
different modes of transfer, but the simulation supports only octet mode
|
|
(the norm).
|
|
</p>
|
|
|
|
<h2>Protocol Parameters</h2>
|
|
|
|
<p>
|
|
This simulation has no parameters.
|
|
</p>
|
|
|
|
<h2>Protocol Simulation</h2>
|
|
|
|
<p>
|
|
The protocol simulation shows a time-sequence diagram with client and
|
|
server protocol entities, and a communications medium that carries
|
|
messages. The client and server exchange the messages described above,
|
|
starting with an <em>RRQ</em> or <em>WRQ</em> from the client. Several
|
|
files may be transferred consecutively.
|
|
</p>
|
|
|
|
<center>
|
|
|
|
<applet code="simulator.ProtocolSimulator.class"
|
|
archive="ProtocolSimulator.jar" width="750" height="700"
|
|
name="ProtocolSimulator">
|
|
<param name="protocol" value="TFTP"/>
|
|
</applet>
|
|
|
|
</center>
|
|
|
|
<hr/>
|
|
|
|
<p>
|
|
<a href="index.html"><img src="uparrow.gif" alt="Up Arrow"/></a>
|
|
Up one level to <a href="index.html">Protocol Simulators</a>
|
|
</p>
|
|
|
|
</body>
|
|
|
|
</html>
|
|
|