aboutsummaryrefslogtreecommitdiffstats
path: root/lib/inets/doc
diff options
context:
space:
mode:
Diffstat (limited to 'lib/inets/doc')
-rw-r--r--lib/inets/doc/src/Makefile1
-rw-r--r--lib/inets/doc/src/inets.xml4
-rw-r--r--lib/inets/doc/src/introduction.xml3
-rw-r--r--lib/inets/doc/src/part.xml1
-rw-r--r--lib/inets/doc/src/ref_man.xml5
-rw-r--r--lib/inets/doc/src/tftp.xml647
6 files changed, 4 insertions, 657 deletions
diff --git a/lib/inets/doc/src/Makefile b/lib/inets/doc/src/Makefile
index d66ef31ba6..90c1258d4a 100644
--- a/lib/inets/doc/src/Makefile
+++ b/lib/inets/doc/src/Makefile
@@ -47,7 +47,6 @@ XML_CHAPTER_FILES = \
XML_REF3_FILES = \
inets.xml \
- tftp.xml \
http_uri.xml\
httpc.xml\
httpd.xml \
diff --git a/lib/inets/doc/src/inets.xml b/lib/inets/doc/src/inets.xml
index 9b17567fd4..eb4e51584f 100644
--- a/lib/inets/doc/src/inets.xml
+++ b/lib/inets/doc/src/inets.xml
@@ -189,8 +189,8 @@
<section>
<title>SEE ALSO</title>
<p><seealso marker="httpc">httpc(3)</seealso>,
- <seealso marker="httpd">httpd(3)</seealso>,
- <seealso marker="tftp">tftp(3)</seealso></p>
+ <seealso marker="httpd">httpd(3)</seealso>
+ </p>
</section>
</erlref>
diff --git a/lib/inets/doc/src/introduction.xml b/lib/inets/doc/src/introduction.xml
index c006599a21..faf911f188 100644
--- a/lib/inets/doc/src/introduction.xml
+++ b/lib/inets/doc/src/introduction.xml
@@ -37,7 +37,6 @@
<p><c>Inets</c> is a container for Internet clients and servers
including the following:</p>
<list type="bulleted">
- <item>A TFTP client and server</item>
<item>An <term id="HTTP"></term> client and server</item>
</list>
<p>The HTTP client and server are HTTP 1.1 compliant as
@@ -49,7 +48,7 @@
<title>Prerequisites</title>
<p>It is assumed that the reader is familiar with the Erlang
programming language, concepts of OTP, and has a basic
- understanding of the TFTP and HTTP protocols.</p>
+ understanding of and HTTP protocol.</p>
</section>
</chapter>
diff --git a/lib/inets/doc/src/part.xml b/lib/inets/doc/src/part.xml
index e7a786d47b..b9c8ed674c 100644
--- a/lib/inets/doc/src/part.xml
+++ b/lib/inets/doc/src/part.xml
@@ -33,7 +33,6 @@
<p>The <c>Inets</c> application provides a set of
Internet-related services as follows:</p>
<list type="bulleted">
- <item>A TFTP client and server</item>
<item>An <term id="HTTP"></term> client and server</item>
</list>
<p>The HTTP client and server are HTTP 1.1 compliant as
diff --git a/lib/inets/doc/src/ref_man.xml b/lib/inets/doc/src/ref_man.xml
index 33886d1a41..58c1a651f9 100644
--- a/lib/inets/doc/src/ref_man.xml
+++ b/lib/inets/doc/src/ref_man.xml
@@ -30,12 +30,9 @@
<file>ref_man.xml</file>
</header>
<description>
- <p><c>Inets</c> is a container for Internet clients and
- servers. An HTTP client and server, and
- a TFTP client and server are incorporated in <c>Inets</c>.</p>
+ <p><c>Inets</c> is a container for an HTTP client and server.</p>
</description>
<xi:include href="inets.xml"/>
- <xi:include href="tftp.xml"/>
<xi:include href="httpc.xml"/>
<xi:include href="httpd.xml"/>
<xi:include href="httpd_custom_api.xml"/>
diff --git a/lib/inets/doc/src/tftp.xml b/lib/inets/doc/src/tftp.xml
deleted file mode 100644
index 10398f5088..0000000000
--- a/lib/inets/doc/src/tftp.xml
+++ /dev/null
@@ -1,647 +0,0 @@
-<?xml version="1.0" encoding="utf-8" ?>
-<!DOCTYPE erlref SYSTEM "erlref.dtd">
-
-<erlref>
- <header>
- <copyright>
- <year>2006</year><year>2015</year>
- <holder>Ericsson AB. All Rights Reserved.</holder>
- </copyright>
- <legalnotice>
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
-
- </legalnotice>
-
- <title>tftp</title>
- <prepared></prepared>
- <docno></docno>
- <date></date>
- <rev></rev>
- </header>
- <module>tftp</module>
- <modulesummary>Trivial FTP.</modulesummary>
- <description>
- <p>This is a complete implementation of the following IETF standards:</p>
- <list type="bulleted">
- <item>RFC 1350, The TFTP Protocol (revision 2)</item>
- <item>RFC 2347, TFTP Option Extension</item>
- <item>RFC 2348, TFTP Blocksize Option</item>
- <item>RFC 2349, TFTP Timeout Interval and Transfer Size Options</item>
- </list>
- <p>The only feature that not is implemented is
- the "netascii" transfer mode.</p>
- <p>The <seealso marker="#start/1">start/1</seealso> function 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 transfer.</p>
- <p>On the client side,
- function <seealso marker="#read_file/3">read_file/3</seealso>
- and <seealso marker="#write_file/3">write_file/3</seealso>
- spawn a temporary client process establishing
- contact with a TFTP daemon and perform the file transfer.</p>
- <p><c>tftp</c> uses a callback module to handle the file
- transfer. Two such callback modules are provided,
- <c>tftp_binary</c> and <c>tftp_file</c>. See
- <seealso marker="#read_file/3">read_file/3</seealso> and
- <seealso marker="#write_file/3">write_file/3</seealso> for details.
- You can also implement your own callback modules, see
- <seealso marker="#tftp_callback">CALLBACK FUNCTIONS</seealso>.
- A callback module provided by
- the user is registered using option <c>callback</c>, see
- <seealso marker="#options">DATA TYPES</seealso>.</p>
- </description>
-
- <section>
- <title>TFTP SERVER SERVICE START/STOP</title>
-
- <p>A TFTP server can be configured to start statically when starting
- the <c>Inets</c> application. Alternatively, it can be started dynamically
- (when <c>Inets</c> is already started) by calling the <c>Inets</c> application
- API <c>inets:start(tftpd, ServiceConfig)</c> or
- <c>inets:start(tftpd, ServiceConfig, How)</c>,
- see <seealso marker="inets">inets(3)</seealso> for details.
- The <c>ServiceConfig</c> for TFTP is described in
- the <seealso marker="#options">DATA TYPES</seealso>
- section.</p>
-
- <p>The TFTP server can be stopped using <c>inets:stop(tftpd, Pid)</c>,
- see <seealso marker="inets">inets(3)</seealso> for details.</p>
-
- <p>The TPFT client is of such a temporary nature that it is not
- handled as a service in the <c>Inets</c> service framework.</p>
-
- </section>
-
- <section>
- <marker id="options"></marker>
- <title>DATA TYPES</title>
- <p><c>ServiceConfig = Options</c></p>
- <p><c>Options = [option()]</c></p>
- <p>Most of the options are common for both the client and the server
- side, but some of them differs a little.
- The available <c>option()</c>s are as follows:</p>
- <taglist>
- <tag><c>{debug, Level}</c></tag>
- <item>
- <p><c>Level = none | error | warning | brief | normal | verbose | all</c></p>
- <p>Controls the level of debug printouts.
- Default is <c>none</c>.</p>
- </item>
- <tag><c>{host, Host}</c></tag>
- <item>
- <p><c>Host = hostname()</c>, see
- <seealso marker="kernel:inet">inet(3)</seealso>.</p>
- <p>The name or IP address of the host where the TFTP daemon
- resides. This option is only used by the client.</p>
- </item>
- <tag><c>{port, Port}</c></tag>
- <item>
- <p><c>Port = int()</c></p>
- <p>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 <c>info/1</c>).</p>
- <p>If a socket is connected already, option
- <c>{udp, [{fd, integer()}]}</c> can be used to pass the
- open file descriptor to <c>gen_udp</c>. This can be automated
- by using a command-line argument stating the
- prebound file descriptor number. For example, if the
- port is 69 and file descriptor 22 is opened by
- <c>setuid_socket_wrap</c>, the command-line argument
- "-tftpd_69 22" triggers the prebound file
- descriptor 22 to be used instead of opening port 69.
- The UDP option <c>{udp, [{fd, 22}]}</c> is automatically added.
- See <c>init:get_argument/</c> about command-line arguments and
- <c>gen_udp:open/2</c> about UDP options.</p>
- </item>
- <tag><c>{port_policy, Policy}</c></tag>
- <item>
- <p><c>Policy = random | Port | {range, MinPort, MaxPort}</c></p>
- <p><c>Port = MinPort = MaxPort = int()</c></p>
- <p>Policy for the selection of the temporary port that is used
- by the server/client during the file transfer. Default is
- <c>random</c>, which is the standardized policy. With this
- policy a randomized free port is used. A single port or a range
- of ports can be useful if the protocol passes through a
- firewall.</p>
- </item>
- <tag><c>{udp, Options}</c></tag>
- <item>
- <p><c>Options = [Opt]</c>, see
- <seealso marker="kernel:gen_udp#open/1">gen_udp:open/2</seealso>.</p>
- </item>
- <tag><c>{use_tsize, Bool}</c></tag>
- <item>
- <p><c>Bool = bool()</c></p>
- <p>Flag for automated use of option <c>tsize</c>. With
- this set to <c>true</c>, the <c>write_file/3</c> client
- determines the filesize and sends it to the server as
- the standardized <c>tsize</c> option. A <c>read_file/3</c>
- client acquires only a filesize from the server by sending
- a zero <c>tsize</c>.</p>
- </item>
- <tag><c>{max_tsize, MaxTsize}</c></tag>
- <item>
- <p><c>MaxTsize = int() | infinity</c></p>
- <p>Threshold for the maximal filesize in bytes. The transfer
- is aborted if the limit is exceeded.
- Default is <c>infinity</c>.</p>
- </item>
- <tag><c>{max_conn, MaxConn}</c></tag>
- <item>
- <p><c>MaxConn = int() | infinity</c></p>
- <p>Threshold for the maximal number of active connections.
- The daemon rejects the setup of new connections if
- the limit is exceeded. Default is <c>infinity</c>.</p>
- </item>
- <tag><c>{TftpKey, TftpVal}</c></tag>
- <item>
- <p><c>TftpKey = string()</c> <br></br>
-<c>TftpVal = string()</c></p>
- <p>Name and value of a TFTP option.</p>
- </item>
- <tag><c>{reject, Feature}</c></tag>
- <item>
- <p><c>Feature = Mode | TftpKey</c> <br></br>
-<c>&nbsp;Mode = read | write</c> <br></br>
-<c>&nbsp;TftpKey = string()</c></p>
- <p>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.</p>
- </item>
- <tag><c>{callback, {RegExp, Module, State}}</c></tag>
- <item>
- <p><c>RegExp = string()</c> <br></br>
-<c>Module = atom()</c> <br></br>
-<c>State = term()</c></p>
- <p>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
- <seealso marker="#read_file/3">read_file/3</seealso> and
- <seealso marker="#write_file/3">write_file/3</seealso>.
- </p>
- <p>The callback module must implement the <c>tftp</c> behavior, see
- <seealso marker="#tftp_callback">CALLBACK FUNCTIONS</seealso>.</p>
- </item>
-
- <tag><c>{logger, Module}</c></tag>
- <item>
- <p><c>Module = module()()</c></p>
-
- <p>Callback module for customized logging of errors, warnings, and
- info messages. The callback module must implement the
- <c>tftp_logger</c> behavior, see
- <seealso marker="#tftp_logger">LOGGER FUNCTIONS</seealso>.
- The default module is <c>tftp_logger</c>.</p>
- </item>
-
- <tag><c>{max_retries, MaxRetries}</c></tag>
- <item>
- <p><c>MaxRetries = int()</c></p>
-
- <p>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.</p>
- </item>
- </taglist>
- </section>
-
- <funcs>
- <func>
- <name>change_config(daemons, Options) -> [{Pid, Result}]</name>
- <fsummary>Changes configuration for all daemons.
- </fsummary>
- <type>
- <v>Options = [option()]</v>
- <v>Pid = pid()</v>
- <v>Result = ok | {error, Reason}</v>
- <v>Reason = term()</v>
- </type>
- <desc>
- <p>Changes configuration for all TFTP daemon processes. </p>
- </desc>
- </func>
-
- <func>
- <name>change_config(servers, Options) -> [{Pid, Result}]</name>
- <fsummary>Changes configuration for all servers.
- </fsummary>
- <type>
- <v>Options = [option()]</v>
- <v>Pid = pid()</v>
- <v>Result = ok | {error, Reason}</v>
- <v>Reason = term()</v>
- </type>
- <desc>
- <p>Changes configuration for all TFTP server processes.</p>
- </desc>
- </func>
-
- <func>
- <name>change_config(Pid, Options) -> Result</name>
- <fsummary>Changes configuration for a TFTP daemon, server,
- or client process.</fsummary>
- <type>
- <v>Pid = pid()</v>
- <v>Options = [option()]</v>
- <v>Result = ok | {error, Reason}</v>
- <v>Reason = term()</v>
- </type>
- <desc>
- <p>Changes configuration for a TFTP daemon, server, or client process.</p>
- </desc>
- </func>
-
- <func>
- <name>info(daemons) -> [{Pid, Options}]</name>
- <fsummary>Returns information about all daemons.</fsummary>
- <type>
- <v>Pid = [pid()()]</v>
- <v>Options = [option()]</v>
- <v>Reason = term()</v>
- </type>
- <desc>
- <p>Returns information about all TFTP daemon processes.</p>
- </desc>
- </func>
-
- <func>
- <name>info(servers) -> [{Pid, Options}]</name>
- <fsummary>Returns information about all servers.</fsummary>
- <type>
- <v>Pid = [pid()()]</v>
- <v>Options = [option()]</v>
- <v>Reason = term()</v>
- </type>
- <desc>
- <p>Returns information about all TFTP server processes. </p>
- </desc>
- </func>
-
- <func>
- <name>info(Pid) -> {ok, Options} | {error, Reason}</name>
- <fsummary>Returns information about a daemon, server, or client process.</fsummary>
- <type>
- <v>Options = [option()]</v>
- <v>Reason = term()</v>
- </type>
- <desc>
- <p>Returns information about a TFTP daemon, server, or client process.</p>
- </desc>
- </func>
-
- <func>
- <name>read_file(RemoteFilename, LocalFilename, Options) -> {ok, LastCallbackState} | {error, Reason}</name>
- <fsummary>Reads a (virtual) file from a TFTP server.</fsummary>
- <type>
- <v>RemoteFilename = string()</v>
- <v>LocalFilename = binary | string()</v>
- <v>Options = [option()]</v>
- <v>LastCallbackState = term()</v>
- <v>Reason = term()</v>
- </type>
- <desc>
- <p>Reads a (virtual) file <c>RemoteFilename</c> from a TFTP
- server.</p>
- <p>If <c>LocalFilename</c> is the atom <c>binary</c>,
- <c>tftp_binary</c> is used as callback module. It concatenates
- all transferred blocks and returns them as one single binary
- in <c>LastCallbackState</c>.</p>
- <p>If <c>LocalFilename</c> is a string and there are no
- registered callback modules, <c>tftp_file</c> is used as
- callback module. It writes each transferred block to the file
- named <c>LocalFilename</c> and returns the number of
- transferred bytes in <c>LastCallbackState</c>.</p>
- <p>If <c>LocalFilename</c> is a string and there are registered
- callback modules, <c>LocalFilename</c> is tested against
- the regexps of these and the callback module corresponding to
- the first match is used, or an error tuple is returned if no
- matching regexp is found.</p>
- </desc>
- </func>
-
- <func>
- <name>start(Options) -> {ok, Pid} | {error, Reason}</name>
- <fsummary>Starts a daemon process.</fsummary>
- <type>
- <v>Options = [option()]</v>
- <v>Pid = pid()</v>
- <v>Reason = term()</v>
- </type>
- <desc>
- <p>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.</p>
- </desc>
- </func>
-
- <func>
- <name>write_file(RemoteFilename, LocalFilename, Options) -> {ok, LastCallbackState} | {error, Reason}</name>
- <fsummary>Writes a (virtual) file to a TFTP server.</fsummary>
- <type>
- <v>RemoteFilename = string()</v>
- <v>LocalFilename = binary() | string()</v>
- <v>Options = [option()]</v>
- <v>LastCallbackState = term()</v>
- <v>Reason = term()</v>
- </type>
- <desc>
- <p>Writes a (virtual) file <c>RemoteFilename</c> to a TFTP
- server.</p>
- <p>If <c>LocalFilename</c> is a binary, <c>tftp_binary</c> is
- used as callback module. The binary is transferred block by
- block and the number of transferred bytes is returned in
- <c>LastCallbackState</c>.</p>
- <p>If <c>LocalFilename</c> is a string and there are no
- registered callback modules, <c>tftp_file</c> is used as
- callback module. It reads the file named <c>LocalFilename</c>
- block by block and returns the number of transferred bytes
- in <c>LastCallbackState</c>.</p>
- <p>If <c>LocalFilename</c> is a string and there are registered
- callback modules, <c>LocalFilename</c> is tested against
- the regexps of these and the callback module corresponding to
- the first match is used, or an error tuple is returned if no
- matching regexp is found.</p>
- </desc>
- </func>
- </funcs>
-
- <section>
- <marker id="tftp_callback"></marker>
- <title>CALLBACK FUNCTIONS</title>
- <p>A <c>tftp</c> callback module is to be implemented as a
- <c>tftp</c> behavior and export the functions listed
- in the following.</p>
- <p>On the server side, the callback interaction starts with a call to
- <c>open/5</c> with the registered initial callback state.
- <c>open/5</c> is expected to open the (virtual) file. Then either
- function <c>read/1</c> or <c>write/2</c> is invoked
- repeatedly, once per transferred block. At each function call,
- the state returned from the previous call is obtained. When
- the last block is encountered, function <c>read/1</c> or
- <c>write/2</c> is expected to close the (virtual) file
- and return its last state. Function <c>abort/3</c> is only
- used in error situations. Function <c>prepare/5</c> is not used on
- the server side.</p>
- <p>On the client side, the callback interaction is the same, but it
- starts and ends a bit differently. It starts with a call to
- <c>prepare/5</c> with the same arguments as <c>open/5</c> takes.
- <c>prepare/5</c> is expected to validate the TFTP options
- suggested by the user and to return the subset of them that it
- accepts. Then the options are sent to the server, which performs
- the same TFTP option negotiation procedure. The options that are
- accepted by the server are forwarded to function <c>open/5</c>
- on the client side. On the client side, function <c>open/5</c>
- must accept all option as-is or reject the transfer. Then
- the callback interaction follows the same pattern as described
- for the server side. When the last block is encountered in
- <c>read/1</c> or <c>write/2</c>, the returned state is forwarded to
- the user and returned from <c>read_file</c>/3 or
- <c>write_file/3</c>.</p>
-
- <p> 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.</p>
-
- <p>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.</p>
-
- <marker id="prepare"></marker>
- </section>
-
- <funcs>
- <func>
- <name>Module:abort(Code, Text, State) -> ok</name>
- <fsummary>Aborts the file transfer.</fsummary>
- <type>
- <v>Code = undef | enoent | eacces | enospc</v>
- <v>&nbsp;&nbsp;| badop | eexist | baduser | badopt</v>
- <v>&nbsp;&nbsp;| int()</v>
- <v>Text = string()</v>
- <v>State = term()</v>
- </type>
- <desc>
- <p>Invoked when the file transfer is aborted.</p>
- <p>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).</p>
- </desc>
- </func>
-
- <func>
- <name>Module:open(Peer, Access, Filename, Mode, SuggestedOptions, State) -> {ok, AcceptedOptions, NewState} | {error, {Code, Text}}</name>
- <fsummary>Opens a file for read or write access.</fsummary>
- <type>
- <v>Peer = {PeerType, PeerHost, PeerPort}</v>
- <v>PeerType = inet | inet6</v>
- <v>PeerHost = ip_address()</v>
- <v>PeerPort = integer()</v>
- <v>Access = read | write</v>
- <v>Filename = string()</v>
- <v>Mode = string()</v>
- <v>SuggestedOptions = AcceptedOptions = [{Key, Value}]</v>
- <v>&nbsp;Key = Value = string()</v>
- <v>State = InitialState | term()</v>
- <v>&nbsp;InitialState = [] | [{root_dir, string()}]</v>
- <v>NewState = term()</v>
- <v>Code = undef | enoent | eacces | enospc</v>
- <v>&nbsp;&nbsp;| badop | eexist | baduser | badopt</v>
- <v>&nbsp;&nbsp;| int()</v>
- <v>Text = string()</v>
- </type>
- <desc>
- <p>Opens a file for read or write access.</p>
- <p>On the client side, where the <c>open/5</c> call has been
- preceded by a call to <c>prepare/5</c>, all options must be
- accepted or rejected.</p>
- <p>On the server side, where there is no preceding
- <c>prepare/5</c> call, no new options can be added, but
- those present in <c>SuggestedOptions</c> can be
- omitted or replaced with new values in <c>AcceptedOptions</c>.</p>
-
- <marker id="read"></marker>
- </desc>
- </func>
-
- <func>
- <name>Module:prepare(Peer, Access, Filename, Mode, SuggestedOptions, InitialState) -> {ok, AcceptedOptions, NewState} | {error, {Code, Text}}</name>
- <fsummary>Prepares to open a file on the client side.</fsummary>
- <type>
- <v>Peer = {PeerType, PeerHost, PeerPort}</v>
- <v>PeerType = inet | inet6</v>
- <v>PeerHost = ip_address()</v>
- <v>PeerPort = integer()</v>
- <v>Access = read | write</v>
- <v>Filename = string()</v>
- <v>Mode = string()</v>
- <v>SuggestedOptions = AcceptedOptions = [{Key, Value}]</v>
- <v>&nbsp;Key = Value = string()</v>
- <v>InitialState = [] | [{root_dir, string()}]</v>
- <v>NewState = term()</v>
- <v>Code = undef | enoent | eacces | enospc</v>
- <v>&nbsp;&nbsp;| badop | eexist | baduser | badopt</v>
- <v>&nbsp;&nbsp;| int()</v>
- <v>Text = string()</v>
- </type>
- <desc>
- <p>Prepares to open a file on the client side.</p>
- <p>No new options can be added, but those present in
- <c>SuggestedOptions</c> can be omitted or replaced with new
- values in <c>AcceptedOptions</c>.</p>
- <p>This is followed by a call to <c>open/4</c> before any
- read/write access is performed. <c>AcceptedOptions</c> is
- sent to the server, which replies with the options that it
- accepts. These are then forwarded to <c>open/4</c> as
- <c>SuggestedOptions</c>.</p>
-
- <marker id="open"></marker>
- </desc>
- </func>
-
- <func>
- <name>Module:read(State) -> {more, Bin, NewState} | {last, Bin, FileSize} | {error, {Code, Text}}</name>
- <fsummary>Reads a chunk from the file.</fsummary>
- <type>
- <v>State = NewState = term()</v>
- <v>Bin = binary()</v>
- <v>FileSize = int()</v>
- <v>Code = undef | enoent | eacces | enospc</v>
- <v>&nbsp;&nbsp;| badop | eexist | baduser | badopt</v>
- <v>&nbsp;&nbsp;| int()</v>
- <v>Text = string()</v>
- </type>
- <desc>
- <p>Reads a chunk from the file.</p>
- <p>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.</p>
-
- <marker id="write"></marker>
- </desc>
- </func>
-
- <func>
- <name>Module:write(Bin, State) -> {more, NewState} | {last, FileSize} | {error, {Code, Text}}</name>
- <fsummary>Writes a chunk to the file.</fsummary>
- <type>
- <v>Bin = binary()</v>
- <v>State = NewState = term()</v>
- <v>FileSize = int()</v>
- <v>Code = undef | enoent | eacces | enospc</v>
- <v>&nbsp;&nbsp;| badop | eexist | baduser | badopt</v>
- <v>&nbsp;&nbsp;| int()</v>
- <v>Text = string()</v>
- </type>
- <desc>
- <p>Writes a chunk to the file.</p>
- <p>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.</p>
-
- <marker id="abort"></marker>
- </desc>
- </func>
- </funcs>
-
- <section>
- <marker id="tftp_logger"></marker>
- <title>LOGGER FUNCTIONS</title>
-
- <p>A <c>tftp_logger</c> callback module is to be implemented as a
- <c>tftp_logger</c> behavior and export the following functions:</p>
-
- <marker id="error_msg"></marker>
- </section>
-
- <funcs>
- <func>
- <name>Logger:error_msg(Format, Data) -> ok | exit(Reason)</name>
- <fsummary>Logs an error message.</fsummary>
- <type>
- <v>Format = string()</v>
- <v>Data = [term()]</v>
- <v>Reason = term()</v>
- </type>
- <desc>
- <p>Logs an error message.
- See <c>error_logger:error_msg/2</c> for details.</p>
-
- <marker id="warning_msg"></marker>
- </desc>
- </func>
-
- <func>
- <name>Logger:info_msg(Format, Data) -> ok | exit(Reason)</name>
- <fsummary>Logs an info message.</fsummary>
- <type>
- <v>Format = string()</v>
- <v>Data = [term()]</v>
- <v>Reason = term()</v>
- </type>
- <desc>
- <p>Logs an info message.
- See <c>error_logger:info_msg/2</c> for details.</p>
- </desc>
- </func>
-
- <func>
- <name>Logger:warning_msg(Format, Data) -> ok | exit(Reason)</name>
- <fsummary>Logs a warning message.</fsummary>
- <type>
- <v>Format = string()</v>
- <v>Data = [term()]</v>
- <v>Reason = term()</v>
- </type>
- <desc>
- <p>Logs a warning message.
- See <c>error_logger:warning_msg/2</c> for details.</p>
-
- <marker id="info_msg"></marker>
- </desc>
- </func>
- </funcs>
-</erlref>
-
-