Re: fds beyond 0/1/2

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

Replying to multiple messages, here....

[Nicolas.Williams%oracle.com@localhost]
> The current channel design has two flows in each direction (data and
> "extended" data), with just one flow control window in each
> direction.

No, it has 4294967297 potential flows in each direction (data, and an
int32 worth of different extended data flows).  It has three
standardized data flows (one from the client to server and two from the
server to the client) and up to 67108864 nonstandardized flows
(33554432 each way), plus possible future standardization (or even past
standardization for all I know, though I would have expected any such
to go by on this list).  All this is per channel, of course.

And all the flows in a given direction for a given channel share the
same flow-control window.

Fine for some purposes.  Not a good fit to the generic Unixish model.
Tolerable in the input direction because so far there's only the one
flow.  Tolerable in the output direction largely because there are
few-to-no programs that depend on stderr getting through when stdout is
blocked by back-pressure (and even fewer that do the same with stderr
and stdout switched).

But add arbitrary fd forwarding and it all starts to fall apart.

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

Agreed.

> Do you really need the multiple fd thing?

Need?  Arguably not.  But then, I arguably don't really _need_ ssh at
all.  Or even computers - it all depends on where you draw the line
between "need" and "want".  Let me put it thus: arbitrary fd forwarding
is valuable enough to me for me to put nontrivial amounts of time into
designing a mechanism to support it and implementing it in moussh.

[anakin%pobox.com@localhost]
> I think a basically sensible approach would be to simply introduce a
> new class of channel, whose CHANNEL_OPEN message cites (alongside all
> the normal stuff) the remote id of a "session" channel [...]

[jhutz%cmu.edu@localhost]
> I can think of three ways to do this:

> 1) A channel request on the session channel that results in creation
>    of a new channel a la SSH_MSG_CHANNEL_OPEN.
> 2) A new "fd" channel type, [basically anakin@'s idea above]
> 3) A new generic "pipe" channel type, [generalization of (2)]

There's another way, which nobody seems to have mentioned yet.  I'm not
sure where it fits into my preference list with respect to the others.

It is simple to state: give each data flow within a channel its own
flow-control window.

I can think of some pros and cons, some of which depend on the details.
I'm sure most of you people can too.  I'd probably go with two
completely new window-adjust messages, one for CHANNEL_DATA data and
another, with a data_type_code, for CHANNEL_EXTENDED_DATA data.  I can
imagine various possible ways to handle using this mechanism instead of
the shared window; my inclination after only a few seconds of thinking
is to make it a global request, which, if accepted, causes all data on
the connection which carried the global request to use per-flow
windows (use of standard window adjustments after issuing or accepting
the global request would be a protocol error).

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