This is a complete implementation of the following IETF standards:
The only feature that not is implemented is the "netascii" transfer mode.
The
On the client side,
function
A TFTP server can be configured to start statically when starting
the
The TFTP server can be stopped using
The TPFT client is of such a temporary nature that it is not
handled as a service in the
Most of the options are common for both the client and the server
side, but some of them differs a little.
The available
Controls the level of debug printouts.
Default is
The name or IP address of the host where the TFTP daemon resides. This option is only used by the client.
The TFTP port where the daemon listens. Defaults is
the standardized number 69. On the server side, it can
sometimes make sense to set it to 0, meaning that
the daemon just picks a free port (which one is
returned by function
If a socket is connected already, option
Policy for the selection of the temporary port that is used
by the server/client during the file transfer. Default is
Flag for automated use of option
Threshold for the maximal filesize in bytes. The transfer
is aborted if the limit is exceeded.
Default is
Threshold for the maximal number of active connections.
The daemon rejects the setup of new connections if
the limit is exceeded. Default is
Name and value of a TFTP option.
Controls which features to reject. This is mostly useful for the server as it can restrict the use of certain TFTP options or read/write access.
Registration of a callback module. When a file is to be
transferred, its local filename is matched to the regular
expressions of the registered callbacks. The first matching
callback is used during the transfer. See
The callback module must implement the
Callback module for customized logging of errors, warnings, and
info messages. The callback module must implement the
Threshold for the maximal number of retries. By default the server/client tries to resend a message up to five times when the time-out expires.
Starts a daemon process listening for UDP packets on a port. When it receives a request for read or write, it spawns a temporary server process handling the actual transfer of the (virtual) file.
Reads a (virtual) file
If
If
If
Writes a (virtual) file
If
If
If
Returns information about all TFTP daemon processes.
Returns information about all TFTP server processes.
Returns information about a TFTP daemon, server, or client process.
Changes configuration for all TFTP daemon processes.
Changes configuration for all TFTP server processes.
Changes configuration for a TFTP daemon, server, or client process.
Starts the
A
On the server side, the callback interaction starts with a call to
On the client side, the callback interaction is the same, but it
starts and ends a bit differently. It starts with a call to
If a callback (performing the file access in the TFTP server) takes too long time (more than the double TFTP time-out), the server aborts the connection and sends an error reply to the client. This implies that the server releases resources attached to the connection faster than before. The server simply assumes that the client has given up.
If the TFTP server receives yet another request from the same client (same host and port) while it already has an active connection to the client, it ignores the new request if the request is equal to the first one (same filename and options). This implies that the (new) client will be served by the already ongoing connection on the server side. By not setting up yet another connection, in parallel with the ongoing one, the server consumes less resources.
Prepares to open a file on the client side.
No new options can be added, but those present in
This is followed by a call to
Opens a file for read or write access.
On the client side, where the
On the server side, where there is no preceding
Reads a chunk from the file.
The callback function is expected to close the file when the last file chunk is encountered. When an error is encountered, the callback function is expected to clean up after the aborted file transfer, such as closing open file descriptors, and so on. In both cases there will be no more calls to any of the callback functions.
Writes a chunk to the file.
The callback function is expected to close the file when the last file chunk is encountered. When an error is encountered, the callback function is expected to clean up after the aborted file transfer, such as closing open file descriptors, and so on. In both cases there will be no more calls to any of the callback functions.
Invoked when the file transfer is aborted.
The callback function is expected to clean up its used resources after the aborted file transfer, such as closing open file descriptors and so on. The function is not invoked if any of the other callback functions returns an error, as it is expected that they already have cleaned up the necessary resources. However, it is invoked if the functions fail (crash).
A
Logs an error message.
See
Logs a warning message.
See
Logs an info message.
See