request-response cycle does NxN work when it could do Nx1

[doodlesbykumbi]

I noticed that when a request for all sockets is issued every client gets the request (expected), and every client gets the response (hmmm?). The clients getting every response means we're consuming NxN resources for something that could be done with N.

socket.io-redis-adapter/lib/index.ts

Line 195 in 3242d8e

this.pubClient.publish(this.responseChannel, response);

This seems to be because the response channel is singular^. A path forward could be to have the request originator start listening on a channel associated with the request id then have the responses come through this temporary channel.

[doodlesbykumbi]

I've added a draft PR^ showing how the approach would work. It could certainly be made cleaner, especially around the finaliser stuff. It could be made backwards compatible by counting the number of subs on the response channel, if that value is non-zero then fall back to the old behaviour.

[doodlesbykumbi]

Ping @darrachequesne

[darrachequesne]

Implemented in f66de11.

[dr-js]

@darrachequesne should we change the default publishOnSpecificResponseChannel to true ?

Currently this config is still false in v8.3.0:
https://github.com/socketio/socket.io-redis-adapter/blob/8.3.0/lib/index.ts#L132-L133

[darrachequesne]

@dr-js yes, we totally could, though that would be a breaking change.

Since this would trigger a new major release, we could even make it the default and remove the publishOnSpecificResponseChannel option.

[dr-js]

I would suggest a new major release, as this should reduce response count massively when using fetchSockets().

And in release changelog we could tell existing user to enable the option and gain possible performance.

[dr-js]

@darrachequesne after some cluster mode testing with redis-cli monitor,
I found namespace.serverSideEmit() should also use publishOnSpecificResponseChannel to reduce response,
currently callback for serverSideEmit still broadcast to non-specific channel,
related pull request: #536