killdcc not working?

[egghead]

It appears killdcc not always functions as one might expext it to work.

To illustrate the problem a code snippet is provided at the bottom.

What it does is:
- setup a listen port
- when a telnet client connects it will send out a request to a webserver and the idx of the client is stored in a variable
- the webserver will provide data which is forwarded to the client
- when the webserver terminates the connection, the connection with the client should be terminated through a killdcc

It is this last step that fails with an "Tcl error [forward:server:status]: invalid idx"

For some reason the idx is not recognised as a valid idx, eventhough a connection with the client exists under that idx.

Performing a manual ".tcl killdcc clientidx" on the partyline terminates the client connection, however.

Anyone any idea?

Code: Select all

#---------------------------------------------------------------------
# set up listen port
#---------------------------------------------------------------------

listen 35000 script forward:onconnect

#---------------------------------------------------------------------
# When a client connects, make an outgoing connection to the server.
#---------------------------------------------------------------------

proc forward:onconnect { clientidx } {

   global forwardidx

   putlog "Client connection on IDX: $clientidx"

   set forwardidx $clientidx

   control $clientidx forward:client:ignore

   # connect to website and submit request

   set hostname "www.egghelp.org"

   set servidx [connect $hostname 80]

   control $servidx forward:server:status

   putdcc $servidx "GET / HTTP/0.9"
   putdcc $servidx ""

   putlog "Client ($clientidx) connected to server ($servidx)"

   return 0

}

#---------------------------------------------------------------------
# ignore client text
#---------------------------------------------------------------------

proc forward:client:ignore { clientidx text } {
   putlog "CLIENT ($clientidx): $text"
   if { $text == "" } { return 1 }
   return 0
}

#---------------------------------------------------------------------
# forward all data from server to client
# If the server closed the connection, close connection with client.
#---------------------------------------------------------------------

proc forward:server:status { servidx text } {

   global forwardidx

   set clientidx $forwardidx

   # Server closed connection? 

   if { $text == "" } { 

      putlog "Server ($servidx) closed connection."

      # The server closed the connection and now we want to close
      # the connection with the client.

      putlog "Killing Client ($clientidx)"

      # Here it fails! :(
      # Would assme that killdcc takes one argument (i.e. the idx)
      # and simply kills the connection.
      # But instead we get:
      # Tcl error [forward:server:status]: invalid idx

      killdcc $clientidx

      return 1

   }

   putdcc $clientidx "$text\r"

   return  0

}

[ppslim]

proc forward:client:ignore { clientidx text } {
putlog "CLIENT ($clientidx): $text"
if { $text == "" } { return 1 }
return 0
}

Havn't tested, but wouldn't this kill the connection when the client sends the double \n for end of headers?

[egghead]

proc forward:client:ignore { clientidx text } {
putlog "CLIENT ($clientidx): $text"
if { $text == "" } { return 1 }
return 0
}

Havn't tested, but wouldn't this kill the connection when the client sends the double \n for end of headers?

Actually that part returns control to eggdrop in case the client terminates the connection.
Remember the (odd) way eggdrop sends connection terminations as an empty string to the procs.
If a client sends an empty string it is simply not send to the procedures.

In any case, for the problem at hand it is not an issue because the connection between eggdrop and the client does not get terminated.

[ppslim]

My advice would be to do some debugging, and find out what is activate when.

You perform this in forward:server:status.

Each time it is called, putlog the incoming text. At the same time, perform a search for the IDX of the client from the output of dcclist (off the top of my head, however, there is a command).

You need to find out when and why it dies.

[egghead]

My advice would be to do some debugging, and find out what is activate when.

You perform this in forward:server:status.

Each time it is called, putlog the incoming text. At the same time, perform a search for the IDX of the client from the output of dcclist (off the top of my head, however, there is a command).

You need to find out when and why it dies.

Actually, that has been done and what happens is as follows:

(in the following, "#" represents the respective idx numbers)

1. We connect with a telnet client to port 35000
2. It reports: Client connection on IDX: #
3. Control for the client is handed over to the proc forward:client:ignore (which is fine and no problem)
4. A connection is made to the webserver at www.egghelp.org
5. It reports: Client (#) connected to server (#)
6. Control for the client is handed over to the proc forward:server:status (which is fine and no problem)
7. The webserver sends the contents of the webpage to eggdrop which in turn sends it to the client (which is exactly what we want)
8. After sending the webpage, the webserver closes the connection (as expected) and we see "Server (#) closed connection." followed by "Killing Client (#)" (also as expected).
9. At this point we want to close the client connection too. Therefore a "killdcc" on the idx of the clientidx is issued. And it is this killdcc that fails. Note that the idx exists in the [dcclist] and the connection between eggdrop and the client is still open.

It thus appears that "killdcc" cannot be issued at any place in the code. Which is odd, because the client idx definitely exists and the client is connected.

Thus the question is: why is it not possible to issue a "killdcc" at that point?

[strikelight]

Thus the question is: why is it not possible to issue a "killdcc" at that point?

You answered this yourself....

Remember the (odd) way eggdrop sends connection terminations as an empty string to the procs.
If a client sends an empty string it is simply not send to the procedures.

In this situation where 'killdcc' is called, it is inside a check for the empty string, thus indicating that the connection was already lost, so how can you kill a lost connection?

[egghead]

Thus the question is: why is it not possible to issue a "killdcc" at that point?

You answered this yourself....

Remember the (odd) way eggdrop sends connection terminations as an empty string to the procs.
If a client sends an empty string it is simply not send to the procedures.

In this situation where 'killdcc' is called, it is inside a check for the empty string, thus indicating that the connection was already lost, so how can you kill a lost connection?

The connection that got lost was the connection between the eggdrop and the webserver. The connection to be killed is between eggdrop and the client. This connection still exists.

What the script does is: client connects to eggdrop, eggdrop connects to webserver, webserver sends info, webserver closes connection with eggdrop and then eggdrop should close the connection with the client.

[strikelight]

Thus the question is: why is it not possible to issue a "killdcc" at that point?

You answered this yourself....

Remember the (odd) way eggdrop sends connection terminations as an empty string to the procs.
If a client sends an empty string it is simply not send to the procedures.

In this situation where 'killdcc' is called, it is inside a check for the empty string, thus indicating that the connection was already lost, so how can you kill a lost connection?

The connection that got lost was the connection between the eggdrop and the webserver. The connection to be killed is between eggdrop and the client. This connection still exists.

What the script does is: client connects to eggdrop, eggdrop connects to webserver, webserver sends info, webserver closes connection with eggdrop and then eggdrop should close the connection with the client.

Ahh I see...my bad..

From the tcl-commands.doc:

Description: removes an idx from the party line and sends all future input to the Tcl command given. The command will be called with two parameters: the idx 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. If the input text is blank (""), it indicates that the connection has been dropped. Also, if the input text is blank, never call killdcc on it, as it will fail with "invalid idx".

Now while it isn't the same idx that just lost connection, I still suspect this is where the bug is (as you probably suspect as well).

Even though you shouldn't have to, as a work around, I'd suggest invoking a utimer to kill the client index..

[egghead]

[snip]
Now while it isn't the same idx that just lost connection, I still suspect this is where the bug is (as you probably suspect as well).

Even though you shouldn't have to, as a work around, I'd suggest invoking a utimer to kill the client index..

Yeah, I suspected something like that too. It appears that in a procedure called by the closing of an idx, another idx cannot be killed.

Indeed I also tried using an [utimer 0] and that works fine. But will make me wonder what the hell I was doing when seeing the code again in a year or so

Thanks for the suggestions.