# dcc.send

Sends a file

Syntax

    dcc.send [-s] [-n] [-c] [-u] [-b] [-g[=<file size>]] [-t] [-m[=<boolean>]] [-i=<interface>] [-p=<port>] [-a=<fake address>] [-f=<fake port>] <nickname> [filename]

Description

Attempts to send the file <filename> to <nickname>.
If [filename] is specified it must be an absolute file path, otherwise a file selection dialog is opened.
The simplest case "dcc.send <nickname> <filename>" will work just as in all the other IRC clients, but this command is really more powerful...
Before attempting to understand the possibilities of this command, be sure to know how a DCC negotiation and connection works.
The file will be sent as a sequence of packets which must be acknowledged one by one by the active client.
There is a special option (see $option()) called "fast send" (also known as "send ahead") that makes KVirc avoid to wait for the acknowledge of the last packet before sending the next one.
Anyway, the connection is declared as succesfull only when the whole file (all the packets) has been acknowledged.
The command supports the following switches:
-b
Assume that no acknowledges are sent. Assume that the transfer was succesfull when the whole file has been sent, then close the socket.
This is called "blind dcc send".
-t
Emulate the TDCC protocol: use the TDCC CTCP message (DCC TSEND) for requesting the connection and assume that no acknowledges are sent. Wait for the remote end to close the connection.
-s
Use a Secure Sockets Layer for the transfer: the whole communication will be encrypted with a private key algorithm after a public key handshake.
This option will work only if the KVIrc executable has been compiled with SSL support and the remote end supports the SSL protocol too.
Please note that this will may down the transfer somewhat.
-s can be combined with -t.
The CTCP negotiation will use SSEND as parameter (or eventually TSSEND).
When requesting a SSL based dcc send to someone you probably will need a certificate. If you don't have one , create it (for example with CA.pl -newcert) and set it in the options dialog. -i=<interface>
Bind the local listening socket to the specified <interface> (which is an IP address: IPV4 or IPV6). If this switch is NOT specified , the socket is bound to the interface of the current irc connection (if any) or to "127.0.0.1".
You can also specify a local interface name to get the address from (this works only for IPV4 interfaces since IPV6 ones seems to be unsupported by the system ioctl() calls at the moment (for linux at least)).
Here go some examples:
-i=215.243.12.12: this will bind to the IPV4 interface with the specified address.
-i=3ffe:1001::1: this will bind to the IPV6 interface with the specified address.
-i=ppp0: this will bind to the IPV4 address of the interface ppp0 (if supported by the underlying system).
The -i switch parameter may serve also as a target address when the -c switch is used.
-p=<port>
Bind the local listening socket to the specified <port>. If this switch is NOT specified, the port will be a "random" one choosen by the kernel.
-a=<fake address>
Send the <fake address> as target for the remote client in the requesting CTCP message. If this switch is not given , the CTCP will contain the real IP address of the listening interface.
-f=<fake port>
Send the <fake port> as target port for the remote client in the requesting CTCP message. If this switch is not given , the CTCP will contain the real port of the listening socket.
All these switches are meant to allow maximum felxibility of the dcc negotiation: older KVIrc releases had serious problems with firewalled and/or masqueraded machines. With the -a and -f switches you can workaround it.
-n
Do NOT send the CTCP request to the target user: you will have to do it manually, or the remote user will have to connect manually (for example by using dcc.recv -c).
-c
Attempt to CONNECT to the remote host specified as <interface> and <port>, instead of listening (active connection instead of a passive one). In this case the -i and -p switches are mandatory.
The 'c' switch takes precedence over 'n' (In fact both should be mutually exclusive).
If the 'c' and 'n' switches are missing, this commands needs to be executed in a window that is bound to a connected irc context (you need a third entity to accomplish the negotiation).
-u
If the 'u' switch is given , the connection attempt will never time out; this might be useful if you want to leave a listening socket for a friend of yours while you are sleeping and have the CTCP processing disabled. The 'u' switch works either in active and passive mode.
-m
If the -m switch is passed, the default boolCreateMinimizedDccSend option is overridden with the <boolean> parameter passed. So actually by passing -m=1 will create a minimized dcc send even if the $option(boolCreateMinimizedDccSend) returns false.
In the same way, by passing -m=0 you will create a non minimized dcc send. If no <boolean> value is specified , it defaults to 1.
-g
This switch is a dirty trick: you can use it to receive files from people behind a firewall with masquerading enabled.
It causes the transfer direction to be inverted: this client will receive the file from the remote host instead of sending it.
<file size> is the expected file size in bytes: this parameter can be omitted, and in this case the dcc will "blindly" trush the remote end and assume that the file has been transferred correctly when the remote end will close the connection.
If you don't pass the -n option , the remote end will receive an informational DCC RECV request, specifying the IP address and the port to connect to.
-t can be used to prevent sending acknowledges to the remote end , and -u can be used to avoid the listening socket to timeout.
-a and -f can be used as well, but I see no real reason for that...
here goes an example of usage of this option:
BAfH can't accept connections (is behind a firewall with masquerading or some other reason...), to his machine.
BAfH wants to send the file important.jpg to Pragma.
BAfH tells to Pragma that he wants to send him the file and Pragma sets up a connection in the following way:
dcc.send -g BAfH important.png
BAfH will see the informational DCC RECV request with the IP address and port that Pragma is listening on. Assume that the address was 212.212.231.220 and the port 32344.
BAfH will then use the following command:
dcc.send -c -i=212.212.231.220 -p=32344 Pragma /home/bafh/important.jpg
Et voila!..the file is transferring.
Pragma will see no file progress indication , since the file size is unknown on Pragma's side.
If BAfH had specified the file size, Pragma could use -g=<file size> while setting up the connection, to be able to see the progress indications.
If Pragma used the the -n option , the DCC RECV indication wouldn't have been sent: in this case Pragma would need to communicate the Ip address and the port "manually" to BAfH.

Examples

Simple examples:

        # Simple dcc chat to Pragma
        dcc.chat Pragma
        # Dcc chat to pragma , listen on address 127.0.0.1
        dcc.chat -i=127.0.0.1 Pragma
        # Dcc chat to pragma , listen on address 168.0.0.1 and port 1025
        dcc.chat -i=168.0.0.1 -p=1025 Pragma

More tricky ones:

        # Dcc chat to pragma , listen on address 127.0.0.1 and port 1080
        # but tell him to connect to address 212.134.22.11 port 1080
        dcc.chat -i=127.0.0.1 -p=1080 -a=212.134.22.11 Pragma
        # Dcc chat to pragma , listen on address 127.0.0.1 and port 1080
        # but tell him to connect to address 212.134.22.11 port 1090
        dcc.chat -i=127.0.0.1 -p=1080 -a=212.134.22.11 -f=1090 Pragma

Now run completly out of bounds. Use dcc.chat connections to do various things:

        # Tricky : simulate a HTTP server
        dcc.chat -n -i=127.0.0.1 -p=80 Netscape
        # Now open http://127.0.0.1 with netscape
        # and type "<html><body>Hello!</body></html>" :)
        #
        # Tricky 2: simulate the ident daemon (if you have none)
        dcc.chat -n -i=127.0.0.1 -p=113 Client
        #
        # Now a self-DCC connection without the IRC negotiation
        # Src: Setup a listening socket awaiting the "Destination" user connection
        dcc.chat -n -i=127.0.0.1 -p=1080 Dst
        # Dst: Connect to the listening socket at addr 127.0.0.1 and port 1080
        dcc.chat -c -i=127.0.0.1 -p=1080 Src
        # The above example will mess you a bit...
        # Try to guess why in both windows YOU have the same nickname
        # that is probably not Dst nor Src... :)

Using the shell ftp proggie is too easy: we're real hackers and want to do complicated things...

        # Connect to the local ftp server and get the list of contents
        /dcc.chat -c -i=127.0.0.1 -p=21 FtpServer
        # Now login: type in the new window (the following lines are NOT commands):
        USER youruser
        PASS yourpass
        # Now enter passive mode
        PASV
        # And watch the line that you have received...sth like
        # 227 Entering passive mode (127,0,0,1,210,195)
        /dcc.chat -c -i=127.0.0.1 -p=$((210 * 256) + 195) FtpList
        # (Change the port numbers accordingly)
        # And then type in the FtpServer window (this is NOT a kvirc command):
        LIST
        # Then watch the ls output in the FtpList window. :)
        # In this way you can also read ascii files by ftp:
        # Assume that in the previous ls output you have seen
        # a README file.
        # In the FtpServer window type:
        PASV
        # Watch the message
        # 227 Entering passive mode (127,0,0,1,22,227)
        /dcc.chat -c -i=127.0.0.1 -p=$((22 * 256) + 227) README
        # In the FtpServer window type:
        RETR README
        # And read the file in the README window :)

Main index, Command index

KVirc 3.0.0 documentation
Generated by root at Thu Apr 29 12:41:05 2004