Connection (session) attributes

[unera]

We need a way to separate connected clients from each other according to their abilities.

For example, we need to know, who provides GFS feature and who doesn't. (See, for example, #5924)

So, we need a new client request IPROTO_SESSION. A client can send his own options or connection options in the request.

Notes:

• The request doesn't need any permissions to pass

Request format

Request code - IPROTO_SESSION (code ~ 0x54)

Body is a map with

• string as key
• any as value

There are some predefined keys:

• proto: INT - client protocol version.

Also, there are some exists predefined keys from file src/box/session_settings.h:

• error_marshaling_enabled
• sql_default_engine
• sql_defer_foreign_keys
• sql_full_column_names
• sql_full_metadata
• sql_parser_debug
• sql_recursive_triggers
• sql_reverse_unordered_selects
• sql_select_debug
• sql_vdbe_debug

Note: a client can send some additional keys in the map. All these keys have to be accessible from LUA.

A user should use an application's prefix for his options. For example myapp_option1: 123.

Response:

Returns all session options in the same format.

[Gerold103]

As I said in GFS design comments, the solution about storing your own case in the same map as the session settings is not scalable. It will for sure conflict when we will add a new session setting. I repeat here the design I think will work the best:

IPROTO_SESSION = MP_MAP {
    IPROTO_SESSION_VERSION = MP_UINT,
    // Settings are set into `box.session.settings`.
    IPROTO_SESSION_SETTINGS = MP_MAP {
        IPROTO_SESSION_SETTING_ERROR_MARSHALING = mp value,
        IPROTO_SESSION_SETTING_SQL_DEFAULT_ENGINE = mp value,
        ...
    },
    // Options are exposes as `box.session.options`.
    IPROTO_SESSION_OPTIONS = MP_MAP {
        MP_STR name = value of any mp_type
    }
}

This way you can store settings not by names but by unsigned ids, which is more compact. Also you can add new settings and not care about what options the existing users use. And finally - it is just easier to work with in the code. IPROTO_SESSION_SETTINGS will be parsed on the server by an independent function instead of a single function, which would need to separate the settings and options somehow.

[unera]

As I said in GFS design comments, the solution about storing your own case in the same map as the session settings is not scalable. It will for sure conflict when we will add a new session setting. I repeat here the design I think will work the best

We would want to add IPROTO_SESSION_SETTING_FEATURE[1-N], for example

IPROTO_SESSION_SETTING_GFS: true/false

to enable/disable features separately.

[Gerold103]

We have box.session.settings for that which will be possible to set via IPROTO_SESSION_SETTINGS inside of IPROTO_SESSION map. We need to decide whether we go with full dependency on IPROTO_SESSION_VERSION or we allow to turn on/off independent features via the session settings.