Balazs Scheidler <[EMAIL PROTECTED]> writes:
> > (listen callback port)
> >
> > This function listens on PORT, returns an lsh_fd object (or NULL if
> > listen failed). When connections arrive, they are passed to the
> > CALLBACK function, as an instance of listen_value. Values returned
> > from the CALLBACK are discarded, i.e. it could be a continuation
> > instead of a command, but I think that would be less convenient.
>
> I see. Is this accomplished using the old "return a command" trick?
> e.g. (a b c) = ((a b) c) ?
Hmm, I don't think so, but I don't understand exactly what you mean.
> > (open-forwarded-tcp port peer)
> >
> > This prepares opening of a forwarded-tcp channel. Port is the port we
> > are forwarding, and peer is the originating port of the connection.
> > For simplicity, let peer be of type listen_value rather than
>
> rather than?
Ooops. Rather than an address_info.
> > This command returns a channel_open_command (i.e. a command accepting
> > an ssh_connection as argument).
> >
> > Then we can define the port-forwarding mechanism as
> >
> > (lambda (connection port)
> > (listen (lambda (peer) (open-forwarded-tcp port peer connection))
> > port))
>
> you wrote only two parameters for open-forwarded-tcp above, it quickly
> became 3..
This, however, is the old "return a command" trick. It's the same
thing as
((open-forwarded-tcp port peer) connection)
and the first call returns a command. An open_forwarded_tcp command,
which inherits channel_open_command, to be precise.
> I'll check your cvs tree.
I'm hacking on this right now. I'm also trying to improve the global
request mechanism; if several global requests are received, they must
be answered in the right order, even if the first one takes longer
time to complete than the second. The problem here is that the listen
command may have to perform dns lookups, which can take some time.
Currently, each dns-lookup locks the entire server, so all listen
commands will be be started and completed in order, but that is a bug
that has to be fixed sooner or later.
I'll check it in into the cvs as soon as I get it to compile, but I'm
not sure when that will happen; perhaps later tonight, perhaps in the
weekend. No, I'll check in tcpforward.c right now, so you can have a
look at it.
/Niels
