Hypothetical: Support an extra connection per node, dedicated to stream requests

[gavin-norman-sociomantic]

The current approach of having stream requests sharing the same connection with all other requests has a limitation: it is not possible to use the trick that we used in the legacy client of suspending a stream by simply stopping reading from the socket.

Due to this limitation, we've had to mutate the stream requests into batch requests, where the processing of a batch in the client can be instantly suspended and there's the guarantee that no more batches will be received until processing of the current one has finished.

The batch approach, in turn, comes with its own limitations, though, the primary being that the bandwidth of the request is greatly reduced. (The node can only send in bursts, waiting for a "keep going" message from the client between them.)

An extra connection per node, dedicated to stream requests, might give us the best of both worlds.

[gavin-norman-sociomantic]

The extra connection would still be a proper, neo, full-duplex connection, so we'd still be able to cleanly stop requests by sending a "stop" message to the node.

[gavin-norman-sociomantic]

Tentatively put in v4.7.0. This would be a big help with the performance issues reported with neo DMQ Consume, and would at least be good to investigate a little bit more.

[gavin-norman-sociomantic]

Further investigation points to the Consume problems actually being a bug (a missing flush), rather than something fundamental. Moved back into Ideas/Future.