SCRIPTSOCK MODULE
This provides a means by which TCL scripters can manipulate sockets (DCC connections). To actually output to a socket, use the putdcc command provided in the core. To kill a socket, use killdcc.

TCL COMMANDS:
connect <host> <port> <script>
makes an outgoing connection attempt and creates a dcc entry for it. the dcc entry is immediately connected to the script (like the control command below)
returns: idx of the new connection

scriptport <port> <proc>
accepts connections which are immediately routed to a proc; the proc is called with three parameters: the idx of the new connection, "C" to signify a connect and the user@host of the connecter.
returns: port #

scriptport <port> off
stop listening at a port, so don't use off as a proc name :)
returns: nothing

control <idx> <command>
removes a user from the party line and sends all future input from them to the Tcl command given; the command will be called with three parameters: the idx of the user, 'D' or 'E' to indicate Data or End of file, and the input text; the command should return "0" to indicate success and "1" to indicate that it relinquishes control of the user back to the bot; the idx must be for a user in the party line area or the file area.
returns: nothing


MORE INFORMATION:
Controlling party line users:
Using the 'control' command you can put a DCC connection (or outgoing TCP connection) in control of a script. All text that comes in on the connection is sent to the proc you specify. All outgoing text should be sent with 'putdcc'.

The control procedure is called with these parameters:

procname <idx> D/E <input-text>
This allows you to use the same proc for several connections. The idx will stay the same until the connection is dropped -- after that, it will probably get reused for a later connection.

To indicate that the connection has closed, your control procedure will be called with the 2nd argument E, normally using D to indicate data.

If you want to hand control of your connection back to eggdrop, your proc should return 1. Otherwise, return 0 to retain control.

Outgoing connections:
Eggdrop allows you to make two types of TCP ("telnet") connections: outgoing and incoming. For an outgoing connection, you specify the remote host and port to connect to. For an incoming connection, you specify a port to listen at.

All of the connections are *event driven*. This means that the bot will trigger your procs when something happens on the connection, and your proc is expected to return as soon as possible. Waiting in a proc for more input is a no-no.

To initiate an outgoing connection, use:

set idx [connect "hostname.goes.here" 3333 handler_proc]
(as an example). $idx now contains a new DCC entry for the outgoing connection.

All connections use non-blocking (commonly called "asynchronous", which is a misnomer) I/O. Without going into a big song and dance about asynchronous I/O, what this means to you is:

  • assume the connection succeeded immediately
  • if the connection failed, an EOF will arrive for that idx
  • Once you have connected, the connection will act just like a normal DCC connection that has been put under the control of a script. If you ever return "1" from the control proc (indicating that you want control to return to eggdrop), the bot will just close the connection and dispose of it. Other commands that work on normal DCC connections, like 'killdcc' and 'putdcc', will work on this idx too.
    Listening port:
    To create a listening port, use:
    scriptport 6667 grabproc
    which will create a new listening port at 6667, and assign it to the script 'grabproc'.

    When a new connection arrives, eggdrop will connect it up and create a new idx for the connection. That idx is sent to 'grabproc' in the form 'grabproc idx C user@hostname' you can handle this as you will, grabproc is automatically the control proc of the socket too.

    Once your grabproc has been called, the idx behaves exactly like an outgoing connection would.

    The best way to learn how to use these commands is to find a script that uses them and follow it carefully. Hopefully this has given you a good start though.

    (c) 1997 Robey Pointer
    (c) 1998 Eggdrop Development Team