Re: fds beyond 0/1/2

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

>> 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.
> I would say that this is the biggest issue of all, and should be
> carefully considered before even _starting_ to write the detailed
> spec and nail down things like the names and formats of new channel
> requests.

I am inclined to agree.  If I'd thought of the back-pressure issue
before I'd written up the rest of it, I would have - but I didn't think
of that until this conversation.

> What are the pros and cons of folding multiple (fd,direction) pairs
> into a single window?  Why did we ever invent CHANNEL_EXTENDED_DATA
> for stderr at all, instead of setting up two channels with separate
> windows and linking them together somehow?

Good question.  I don't recall hearing; I certainly wasn't the person
who made that choice. :-)

> As far as I can see, the key advantage of CHANNEL_EXTENDED_DATA is
> that it allows the recipient to preserve the same interleaving of the
> stdout and stderr data, in the case where this is perceptible
> (because the SSH client's stdout and stderr fds are duplicates of
> each other, i.e. target the _same_ terminal device or pipe or file).

After a fashion.  As you point out, this isn't really possible with the
currently-widespread interfaces between sshd and the process being run.

While, as I said, I wasn't around when the decision was made, I suspect
that what happened is something like "oh, we want something separate
for stderr; let's throw in an alternative data mechanism", with the
implications not really thought through - in particular, the effects on
the data window and channel EOF not being given much thought.  For that
matter, while I thought of the EOF issues, I didn't think of the window
issues until this conversation....

/~\ 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