Where should this be set? For a server it's OK, set it on theSshServer. But for the client side?

• On theSshClient? That's not useful if one uses a singleSshClientfor multiple sessions; it would be advertised and might be activated forall sessions created through thatSshClient.
• On theClientSession? That's way too late; a client session starts immediately when instantiated, so if the user code want to set it on the session, there'd be a race condition. The initial KEX might be on-going or already over, and the client might already have passed the point where it would send its SSH_MSG_EXT_INFO message.

I don't like the mis-use of Boolean for a tri-state value, and I don't like the fact thatnull corresponds to's' (supported).

Introduce an enum for this with two values: SUPPORTED and PREFERRED, and letnull mean "do not advertiseno-flow-control at all".

Additionally: under what condition exactly would it make sense for aserver to ever send'p' (PREFERRED)? A general-purpose server should probably never do so and at most send's'(SUPPORTED).

For a server the default should benull (don't advertise it). Users who want to have a server that does implement this can set the property to SUPPORTED explicitly.

For a client sending 's' probably makes not much sense (unless there is a use case where having the server send 'p' would make sense). For a client it's either 'p' ("yes, I want this if you can do it, too"), or don't advertise it at all ("no, I don't want this, even if you can, because I might want to open multiple simultaneous channels").

Doesn't kill the client session; it closes the client channel (hard, at that). Why would the client do so? Wouldn't it be more natural to have the server close the channel (gracefully!) after it has sent the last data?

Where is that resource? Why use a resource at all?

This test simulates a download. There should also be a test showing a file upload.

Plus: this needs tests with slow consumers, and it needs tests involving port forwarding with slow consumers. I'm a bit worried thatno-flow-control may lead to a lot of data ending up being buffered somewhere. Especially if it's done like in this test: I suspect the "pending queue" will then get very large. That would be a no-go for a server, and might be a problem for a client.

If someone tunes a high latency connection by increasing send and receive buffer sizes, might we get into trouble? (Especially on a server. Consider a server with 1000 connections all havingno-flow-control enabled and streaming lots of data.)

Additionally,waitAndConsume() andwaitForSpace()should also do an early return. The should not wait for anything.expand must not do anything.

Additionally,release() must not do anything.

Below:

this.maxSize = this.noFlowControl ? Integer.MAX_VALUE : size;this.packetSize = packetSize;updateSize(this.maxSize);

Can we avoid this code duplication between client & server?

This must send something only if the server had announced ext-info-s. Otherwise the client must not send any extensions. See the logic in the DefaultServerKexExtensionHandler.