Re: Protocol ambiguity: want_reply vs CHANNEL_CLOSE

You don't have to avoid reusing ALL channel numbers, just recent ones.

What our implementation does is:

- Increment channel number up to 2^32, then wrap around.

- If the channel number we're trying to use is already in use, try next one.

You could also conceivably do something else, like:

- Reuse channel numbers, but

- Not channel numbers that were used within the last X minutes of operation.

denis


-----Original Message----- 
From: Simon Tatham
Sent: Friday, April 4, 2014 09:29
To: denis bider (Bitvise)
Cc: Matt Johnston ; [email protected]
Subject: Re: Protocol ambiguity: want_reply vs CHANNEL_CLOSE

"denis bider \(Bitvise\)" <[email protected]> wrote:

> The behavior that accommodates all request responders is as follows:
[...]
> - Do not reuse channel numbers, so that you can reliably ignore channel
> request responses received after CLOSE.

The trouble with that is that it's _horrible_! The intention of the
SSH protocol design was always that channel numbers should be
reusable, so that SSH sessions do not have a designed-in lifetime
limit.

2^32 channel opens and closes is certainly a lot, but it isn't beyond
the bounds of belief in situations of (for example) heavy WWW use over
SOCKS forwarding in a long-lived connection.

It may be necessary to use this as a kludgy workaround for some
particular server, if we really cannot determine from its version
string which policy it follows, but I cannot bring myself to believe
it's the sensible policy to apply in all situations.

Cheers,
Simon
-- 
Simon Tatham         What do we want?        ROT13!
<[email protected]>   When do we want it?     ABJ!