Re: fds beyond 0/1/2

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> I had occasion to wish that ssh supported running remote commands
>> with fds other than 0, 1, and 2 connected to useful things.

>> Has anyone written up a spec for an extension to support this?  I
>> don't recall seeing any, but that doesn't prove anything.

> I haven't seen any.

Then I probably haven't just missed it.

> I guess one ought to use MSG_CHANNEL_EXTENDED_DATA for the actual
> data, but then you need some session handshaking to set up which fd:s
> should be opened and which ids they should use in
> MSG_CHANNEL_EXTENDED_DATA.

Right.  I spent most of my last train trip thinking about this and
blocking out roughly how I'd do it, and what I came up with totally
fits with what you sketch here.

> All fd:s of the channel would then use a single window (or rather,
> one in each direction) for flow control.

Right.

> I take it this could be useful for both directions, although with the
> client in chanrge of setting everything up.

Yes.  So far it seems your thoughts and mine are tracking pretty
closely, so I'm probably not totally off in the weeds.

Hm, this actually raises a potential issue: we really should have
separate back-pressure on each fd, so that failure to consume data from
a particular fd does not wedge the whole channel.

> Do you want to be able to setup bidirectional fd:s as well?

Yes, largely because I see no particular reason to forbid it, and it
can be useful for programmatic use if nothing else.  The protocol I
have blocked out even supports requesting forwarding with data transfer
in neither direction, though I would expect servers to reject such
attempts unless-and-until someone invents a way to make them useful.

>> If not, I've got some ideas I can write up and float for comment.
>> If nobody but me cares, I suppose I can just hack something together
>> and forget the issue. :)
> I'm somewhat interested, but I'm not going to put in any real work
> any time soon.

I'm not asking anyone to.  I'd be interested in any thoughts anyone has
on the subject, but I don't expect anyone but me to be doing any coding
on it.  Given that we've lasted this long without anyone caring enough
to say anything public about it, it's obviously not a high priority for
most people.

I'll send another note to the list in a few minutes with what I have so
far.  It actually includes two extensions which, while strictly
orthogonal to one another, synergize nicely: one for fd forwarding and
one for indicating EOF on a data stream without indicating EOF on the
whole channel.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B