Re: fds beyond 0/1/2

[Nicolas Williams <Nicolas.Williams%oracle.com@localhost>]

On Wed, Aug 25, 2010 at 02:54:43PM -0400, der Mouse wrote:
> On Wed, 25 Aug 2010 17:27:22 +0100, Simon Tatham wrote:
> >> 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.

I think each FD should have its own flow-control.  Just as it works in
any Unix/POSIX OS.

The current channel design has two flows in each direction (data and
"extended" data), with just one flow control window in each direction.

That's... weird.  It works, I guess, but it strikes me as a poor design.

> > 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. :-)

I've always wondered myself.  Heck, we could have had a channel for each
direction, such that we'd have needed _three_ linked channels for a
shell session.

My guess is that SSHv1 design and simplicity informed the v2 channel
design.  Or, as der Mouse thinks, maybe it was an [ill] afterthought.

The more "extended" data flows we add, the more likely it is that we'll
have a problem with the single window for all flows in one direction
issue, though I'm not sure how severe any problems will be.

> > 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).

That's true in the pty case (because the stdout/stderr distinction is
lost before the writes even happen as the two fildes will both refer to
the same pty).

It's not necessarily true in the no-pty case.  If the server uses two
distinct pipes for stdout and stderr then the relative ordering of
stdout/stderr writes will be lost.

It's the no-pty case where the distinction between stdout and stderr
becomes useful!  (Because the client can do redirection of the two
separately on the client side.)

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

Right.

> 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....

Yeah, it seems like an afterthought.

Do you really need the multiple fd thing?  Sounds like you might need to
do some violence to the connection protocol...  Well, maybe not so much
violence, just a way to link channels.

Nico
--