LAB-JAVA_BASH-MAYNOOTH_CS380/lab8_protocols/jasper/html/TFTP.html

134 lines
3.8 KiB
HTML
Raw Normal View History

2020-12-08 21:10:13 +01:00
<!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 &quot;presume all transmissions
over&quot; 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>