[EMAIL PROTECTED] (Niels Möller) writes:
> Great. I have incorporated the previous patch into my code, but I
> haven't been able to check it in yet (network trouble). I hope to get
> the time to look at your new code this weekend.
Ok, now I have done some more work, and checked in my current code
into cvs. It's not in working shape though, even if it seems to
compile. There are two main issues to solve:
> I think the problem is that listen command needs to return two values; first
> the fd-object it is listening on (or NULL if listen failed); second,
> the fd-objects returned from accept. Currently, the first of these are
> difficult to get to.
>
> I'm considering changing the listen command and drop the idea that it
> _returns_ accepted connections, several times. Instead, you would
> invoke a listen-command like
>
> (listen port some-callback)
>
> This command could return the listen-fd (or NULL if unsuccessful). You
> could keep a pointer to the object and close it when the forwarding is
> cancelled. When a connection is accepted, listen will invoke the
> callback with the new fd as argument.
I think this is the way to go. But I have to think a little more about
to arrange the commands around that. In particular, some kind of
conditional expressions would be nice.
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.
BTW, I also changed some names in io.h and tcpforward.c, to avoid
things like foo->address->address->address. I think that a reasonable
rule of thumb, which I'll try to follow from now on, is to avoid
variable names that are also names of types. I.e. a variable name
should say something about what the variable _means_ or what it is
good for, not what type it is.
Best regards,
/Niels
