diff options
Diffstat (limited to 'lib/inets/doc/src/tftp.xml')
| -rw-r--r-- | lib/inets/doc/src/tftp.xml | 191 |
1 files changed, 116 insertions, 75 deletions
diff --git a/lib/inets/doc/src/tftp.xml b/lib/inets/doc/src/tftp.xml index 96d6ae0dd5..0b3e93a153 100644 --- a/lib/inets/doc/src/tftp.xml +++ b/lib/inets/doc/src/tftp.xml @@ -1,10 +1,10 @@ -<?xml version="1.0" encoding="latin1" ?> +<?xml version="1.0" encoding="iso-8859-1" ?> <!DOCTYPE erlref SYSTEM "erlref.dtd"> <erlref> <header> <copyright> - <year>2006</year><year>2009</year> + <year>2006</year><year>2012</year> <holder>Ericsson AB. All Rights Reserved.</holder> </copyright> <legalnotice> @@ -218,6 +218,8 @@ <c>5</c> times when the timeout expires.</p> </item> </taglist> + + <marker id="start1"></marker> </section> <funcs> @@ -231,11 +233,14 @@ </type> <desc> <p>Starts a daemon process which listens for udp packets on a - port. When it receives a request for read or write it spawns - a temporary server process which handles the actual transfer - of the (virtual) file.</p> + port. When it receives a request for read or write it spawns + a temporary server process which handles the actual transfer + of the (virtual) file.</p> + + <marker id="read_file"></marker> </desc> </func> + <func> <name>read_file(RemoteFilename, LocalFilename, Options) -> {ok, LastCallbackState} | {error, Reason}</name> <fsummary>Read a (virtual) file from a TFTP server</fsummary> @@ -248,23 +253,26 @@ </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> + 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> + + <marker id="write_file"></marker> </func> + <func> <name>write_file(RemoteFilename, LocalFilename, Options) -> {ok, LastCallbackState} | {error, Reason}</name> <fsummary>Write a (virtual) file to a TFTP server</fsummary> @@ -288,10 +296,12 @@ 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> + 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> + + <marker id="info_daemons"></marker> </desc> </func> @@ -304,8 +314,9 @@ <v>Reason = term()</v> </type> <desc> - <p>Returns info about all TFTP daemon processes. - </p> + <p>Returns info about all TFTP daemon processes. </p> + + <marker id="info_servers"></marker> </desc> </func> @@ -318,8 +329,9 @@ <v>Reason = term()</v> </type> <desc> - <p>Returns info about all TFTP server processes. - </p> + <p>Returns info about all TFTP server processes. </p> + + <marker id="info_pid"></marker> </desc> </func> @@ -332,6 +344,8 @@ </type> <desc> <p>Returns info about a TFTP daemon, server or client process.</p> + + <marker id="change_config_daemons"></marker> </desc> </func> @@ -346,8 +360,9 @@ <v>Reason = term()</v> </type> <desc> - <p>Changes config for all TFTP daemon processes - </p> + <p>Changes config for all TFTP daemon processes. </p> + + <marker id="change_config_servers"></marker> </desc> </func> @@ -362,8 +377,9 @@ <v>Reason = term()</v> </type> <desc> - <p>Changes config for all TFTP server processes - </p> + <p>Changes config for all TFTP server processes. </p> + + <marker id="change_config_pid"></marker> </desc> </func> @@ -378,8 +394,11 @@ </type> <desc> <p>Changes config for a TFTP daemon, server or client process</p> + + <marker id="start2"></marker> </desc> </func> + <func> <name>start() -> ok | {error, Reason}</name> <fsummary>Start the Inets application</fsummary> @@ -442,8 +461,9 @@ by the already ongoing connection on the server side. By not setting up yet another connection, in parallel with the ongoing one, the server will - consumer lesser resources. - </p> + consumer lesser resources. </p> + + <marker id="prepare"></marker> </section> <funcs> @@ -468,17 +488,20 @@ <v>Text = string()</v> </type> <desc> - <p>Prepares to open a file on the client side.</p> - <p>No new options may be added, but the ones that are present in - <c>SuggestedOptions</c> may be omitted or replaced with new - values in <c>AcceptedOptions</c>.</p> - <p>Will be 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 those options that it - accepts. These will be forwarded to <c>open/4</c> as - <c>SuggestedOptions</c>.</p> + <p>Prepares to open a file on the client side.</p> + <p>No new options may be added, but the ones that are present in + <c>SuggestedOptions</c> may be omitted or replaced with new + values in <c>AcceptedOptions</c>.</p> + <p>Will be 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 those options that it + accepts. These will be forwarded to <c>open/4</c> as + <c>SuggestedOptions</c>.</p> + + <marker id="open"></marker> </desc> </func> + <func> <name>open(Peer, Access, Filename, Mode, SuggestedOptions, State) -> {ok, AcceptedOptions, NewState} | {error, {Code, Text}}</name> <fsummary>Open a file for read or write access</fsummary> @@ -503,14 +526,17 @@ <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 may be added, but - the ones that are present in <c>SuggestedOptions</c> may be - omitted or replaced with new values in <c>AcceptedOptions</c>.</p> + 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 may be added, but + the ones that are present in <c>SuggestedOptions</c> may be + omitted or replaced with new values in <c>AcceptedOptions</c>.</p> + + <marker id="read"></marker> </desc> </func> + <func> <name>read(State) -> {more, Bin, NewState} | {last, Bin, FileSize} | {error, {Code, Text}}</name> <fsummary>Read a chunk from the file</fsummary> @@ -526,15 +552,18 @@ <desc> <p>Read 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 etc. In both - cases there will be no more calls to any of - the callback functions.</p> + 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 etc. In both + cases there will be no more calls to any of + the callback functions.</p> + + <marker id="write"></marker> </desc> </func> + <func> <name>write(Bin, State) -> {more, NewState} | {last, FileSize} | {error, {Code, Text}}</name> <fsummary>Write a chunk to the file</fsummary> @@ -550,15 +579,18 @@ <desc> <p>Write 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 etc. In both - cases there will be no more calls to any of - the callback functions.</p> + 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 etc. In both + cases there will be no more calls to any of + the callback functions.</p> + + <marker id="abort"></marker> </desc> </func> + <func> <name>abort(Code, Text, State) -> ok</name> <fsummary>Abort the file transfer</fsummary> @@ -572,14 +604,14 @@ <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 etc. The function will not be - invoked if any of the other callback - functions returns an error, as it is - expected that they already have cleaned up - the necessary resources. It will however be - invoked if the functions fails (crashes).</p> + up its used resources after the aborted file + transfer, such as closing open file + descriptors etc. The function will not be + invoked if any of the other callback + functions returns an error, as it is + expected that they already have cleaned up + the necessary resources. It will however be + invoked if the functions fails (crashes).</p> </desc> </func> </funcs> @@ -589,7 +621,9 @@ <title>LOGGER FUNCTIONS</title> <p>A <c>tftp_logger</c> callback module should be implemented as a - <c>tftp_logger</c> behavior and export the functions listed below.</p> + <c>tftp_logger</c> behavior and export the functions listed below.</p> + + <marker id="error_msg"></marker> </section> <funcs> @@ -602,7 +636,10 @@ <v>Reason = term()</v> </type> <desc> - <p>Log an error message. See <c>error_logger:error_msg/2 for details.</c> </p> + <p>Log an error message. + See <c>error_logger:error_msg/2 for details.</c> </p> + + <marker id="warning_msg"></marker> </desc> </func> @@ -615,7 +652,10 @@ <v>Reason = term()</v> </type> <desc> - <p>Log a warning message. See <c>error_logger:warning_msg/2 for details.</c> </p> + <p>Log a warning message. + See <c>error_logger:warning_msg/2 for details.</c> </p> + + <marker id="info_msg"></marker> </desc> </func> @@ -628,7 +668,8 @@ <v>Reason = term()</v> </type> <desc> - <p>Log an info message. See <c>error_logger:info_msg/2 for details.</c> </p> + <p>Log an info message. + See <c>error_logger:info_msg/2 for details.</c> </p> </desc> </func> </funcs> |