transfer::receiver - Data source
This package pulls data destinations and connection setup together into a combined object for the reception of information coming in over a socket. These objects understand all the options from objects created by the packages transfer::data::destination and transfer::connect.
This command creates a new receiver object with an associated Tcl command whose name is objectName. This object command is explained in full detail in the sections Object command and Object methods. The set of supported options is explained in section Options.
The object command will be created under the current namespace if the objectName is not fully qualified, and in the specified namespace otherwise. The fully qualified name of the object command is returned as the result of the command.
This method creates a fire-and-forget transfer for the data coming from the source at host/port (details below) and writing to the channel chan, starting at the current seek location. The channel is configured to use binary translation and encoding for the transfer. The channel is not closed when the transfer has completed. This is left to the completion callback.
If both host and port are provided an active connection to the data source is made. If only a port is specified (with host the empty string) then a passive connection is made instead, i.e. the receiver then waits for a conneciton by the transmitter.
Any arguments after the port are treated as options and are used to configure the internal receiver object. See the section Options for a list of the supported options and their meaning. Note however that the signature of the command prefix specified for the -command callback differs from the signature for the same option of the receiver object. This callback is only given the number of bytes and transfered, and possibly an error message. No reference to the internally used receiver object is made.
The result returned by the command is the empty string if it was set to make an active connection, and the port the internal receiver object is listening on otherwise, i.e when it is configured to connect passively. See also the package transfer::connect and the description of the method connect for where this behaviour comes from.
This method is like stream channel, except that the received data is written to the file path, replacing any prior content.
All objects created by the ::transfer::receiver command have the following general form:
This method destroys the object. Doing so while a reception is on progress will cause errors later on, when the reception completes and tries to access the now missing data structures of the destroyed object.
This method initiates the data reception, setting up the connection first and then copying the received information into the destination. The method will throw an error if a reception is already/still in progress. I.e. it is not possible to run two receptions in parallel, only in sequence. Errors will also be thrown if the configuration of the data destination is invalid, or if no completion callback was specified.
The result returned by the method is the empty string for an object configured to make an active connection, and the port the object is listening on otherwise, i.e when it is configured to connect passively. See also the package transfer::connect and the description of the method connect for where this behaviour comes from.
This method returns a boolean value telling us whether a reception is in progress (True), or not (False).
One way to secure connections made by objects of this package is to require the package tls and then configure the option -socketcmd to force the use of command tls::socket to open the socket.
# Load and initialize tls package require tls tls::init -cafile /path/to/ca/cert -keyfile ... # Create a connector with secure socket setup, transfer::receiver R -socketcmd tls::socket ... ...
This package uses the TLS package to handle the security for https urls and other socket connections.
Policy decisions like the set of protocols to support and what ciphers to use are not the responsibility of TLS, nor of this package itself however. Such decisions are the responsibility of whichever application is using the package, and are likely influenced by the set of servers the application will talk to as well.
For example, in light of the recent POODLE attack discovered by Google many servers will disable support for the SSLv3 protocol. To handle this change the applications using TLS must be patched, and not this package, nor TLS itself. Such a patch may be as simple as generally activating tls1 support, as shown in the example below.
package require tls tls::init -tls1 1 ;# forcibly activate support for the TLS1 protocol ... your own application code ...
This document, and the package it describes, will undoubtedly contain bugs and other problems. Please report such in the category transfer of the Tcllib Trackers. Please also report any ideas for enhancements you may have for either package and/or documentation.