Make command HELLO optional

[AndreyAlifanov]

Please, make command HELLO optional.

Some servers implementing RESP3 don't implement command HELLO.
And it's impossible to use boost.redis with such servers.

But other client libraries and even redis-cli work with these servers just fine.

Examples of such servers: Tarantool DB and Picodata Radix. Both have modules for RESP3.

I think, library should give possibility to use this command, but should not call it itself by default.

[anarthal]

AFAIK the main point of HELLO is enforcing the usage of RESP3, vs RESP2, which is the old protocol version used by Redis. At the moment, Boost.Redis only supports RESP3 (Redis v6+). redis-cli supports both protocols.

Do these databases speak RESP2 or RESP3? Is there any place where I can access these databases (preferably as a Docker image) so I can run the library's test suite against them and diagnose problems?

[AndreyAlifanov]

As I wrote earlier, these servers speak RESP3, and only RESP3.

It's commercial software, so it's not trivial to get copy for testing.
You can order a demo for Tarantool DB (https://www.tarantool.io/en/tarantooldb/).
About Radix I can't say almost nothing - it's quite difficult to get demo-copy.

I did some tests already. When I dropped out hello_op, I succesfully connected to these servers. And commands like "INFO SERVER", "INCR", "SET", "GET", "DEL" and so on were also successful.
With hello I've got errors at the start and connection cancel.

So I think, it will be useful to have flag in config: to use hello or not for connection.

[anarthal]

Great. I've already spoken with @mzimbres and he's open to have this done. I'll implement it when I have the time.

[AndreyAlifanov]

Thanks in advance!

[anarthal]

Our HELLO also performs authentication (equivalent to the AUTH command) and sets the client name (equivalent to CLIENT SETNAME). @AndreyAlifanov does your system support these commands? Do you have interest in automatic authentication/SETNAME on connection establishment?

[AndreyAlifanov]

Yes, we have interest in automatic authentication (for Redis or its clones). But Tarantool/Radix don't support such scenario.
So we call explicit AUTH command when needed.
CLIENT SETNAME we don't use at all.

[mzimbres]

So we call explicit AUTH command when needed

For automatic reconnection and failover the connection would have to send AUTH automatically..

At the moment it is also not possible to do manual reconnection properly when AUTH is.needed, because the priority field is not exposed to the user. This field is needed because AUTH has to be sent before any other command that might have been in the queue before thedisconnection.

[AndreyAlifanov]

Therefore I ask for optional flag, not mandatory.
It will be my problem if I turn it off.

But maybe it will be better solution to communicate with vendors. To fix their problems with RESP3 implementation.
Of cause, it's not your question. It's mine.

[anarthal]

Yes, we have interest in automatic authentication (for Redis or its clones). But Tarantool/Radix don't support such scenario.
So we call explicit AUTH command when needed.
CLIENT SETNAME we don't use at all.

I'm confused by this. Do you mean that these systems don't support authenticating with HELLO? What I was proposing is having the connection automatically sending an AUTH command (vs a HELLO with an AUTH parameter) on startup when send_hello=false. But I need to know whether these systems support the AUTH command and tge syntax they use.

[AndreyAlifanov]

These systems don't support HELLO at all.
Command AUTH is supported in standard form, as far as I see from redis-cli and documentation.

After sending commands ACL SETUSER ... I successfully perform command AUTH username password

[anarthal]

That's the piece of information I needed, thanks.

[anarthal]

@mzimbres I propose the following:

struct config {
    // ...
    enum class setup_request_mode {
        append, // the passed request is appended to the HELLO pipeline generated by the library
        replace, // the passed request replaces any HELLO pipeline that the library might generate
    };
    setup_request_mode setup_mode { setup_request_mode::append };
    request setup_request;
};

So the user might:

• Do nothing, and everything works as it's today.
• Add some commands to setup_request, and they will be appended to what we send today. This can be used to issue SELECT commands (so we can deprecate database_index), subscribe to channels... And it should be fine even with sentinel.
• Set setup_mode to setup_request_mode::replace, and the library wouldn't send anything during the connection phase.
• Set setup_mode to setup_request_mode::replace and add some commands to setup_request. These commands would be sent instead of what's sent today. This allows sending things like AUTH and SELECT in systems that don't support HELLO.

@mzimbres what do you think of this?
@AndreyAlifanov would this scheme suit you?

[AndreyAlifanov]

@anarthal I think, this scheme is good.