[EMAIL PROTECTED] (Niels M�ller) writes:
> > > The second issue is the open_tcpip_command. It doesnt quite fit in the
> > > channel_open_command framework. Perhaps that is not a big problem, but
> > > perhaps it can be made to fit better.
> >
> > [ ... ]
>
> Do you have any ideas about how to improve it? I think I'd need an
> hour or so to meditate about this... I think one approach is to first
> find out what the command-language expression for listening and
> forwarding connections should look like, and then implement the
> builtin functions, and possibly other extensions like exceptions,
> needed to make it work.
Now I think I know how to deal with this... I need a to massage the
existing builtin functions a little. I need
(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.
(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
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))
When invoking this command, we pass a continuation function which
checks the return value, sends a response back to the client, and, if
successful, updates the list of forwarded ports.
/Niels
