dcc.recv
Sets up a file receiving connection
Usage
dcc.recv [-s] [-t] [-u] [-b] [-n] [-c] [-i=<interface>] [-p=<port>] [-m[=<boolean>]] <nickname> <filename> <remote file size>
Description
Sets up a connection ready to receive a file.
In most 'common' cases you will not need this command, you might want to use dcc.get instead.
This works like dcc.send but has two main differences: The file is INCOMING, and the CTCP sent to the other side is a CTCP RECV.
This command is the counterpart of dcc.send and its parameters are exactly the same, so please refer to that help page for the full discussion. This help page contains only a brief resume of these parameters.
The dcc documentation explains the DCC RECV sub-protocol in detail.
Switches
-b | --blind
Assume that no acknowledges are sent. Assume that the transfer was successful when the whole file has been sent, then close the socket.
This is called a blind DCC SEND.
-t | -tdcc
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.
-m[=<boolean>] | --minimize[=<boolean>]
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.
-n | --no-ctcp
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).
-i=<interface> | --ip=<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> | --port=<port>
Bind the local listening socket to the specified <port>. If this switch is not specified, the port will be a random one chosen by the kernel.
-a=<fake address> | --fake-address=<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> | --fake-port=<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 flexibility of the DCC negotiation, earlier KVIrc releases had serious problems with firewalled and/or masqueraded machines. With the -a and -f switches you can work around it.

-u | --unlimited
If the 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.
-s | --ssl
Use a Secure Socket 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.
-c | --connect
Accepted for compatibility: don't use it!

Index, Commands