Re: fds beyond 0/1/2

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

On Wed, Aug 25, 2010 at 10:03:50PM -0400, der Mouse wrote:
> 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
> ...

Sure, sure.  A funny nit :)

> Fine for some purposes.  Not a good fit to the generic Unixish model.

Indeed.

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

If you implement, then that's good enough for me.  Write up an I-D.

> [jhutz%cmu.edu@localhost]
> > I can think of three ways to do this:
> 
> 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).

That will do too.  In retrospect I wish the connection protocol had
always just had linkable uni-directional channels (with a way to create
channel pairs in one go, for things like port forwarding).  I suspect
the channel state machines would have been much simpler that way!  But,
it's too late :(

Nico
--