Re: [Tarantool-patches] [PATCH 3/6] iproto: Add negotiation phase

[Alexander Turenko <alexander.turenko@tarantool.org>]

On Fri, Mar 27, 2020 at 12:13:43AM +0300, Alexander Turenko wrote:
> On Wed, Mar 25, 2020 at 10:35:41AM +0300, lvasiliev wrote:
> > 
> > 
> > On 24.03.2020 23:02, Konstantin Osipov wrote:
> > > * Leonid Vasiliev <lvasiliev@tarantool.org> [20/03/24 16:02]:
> > > > The negotiation phase has been added to IPROTO
> > > > 
> > > > For possibility to have a custom parameters of session the negotiation
> > > > phase has been added. This is necessary to enable the transmission of
> > > > an error in different formats(depending on the choice of the client).
> > > > 
> > > > @TarantoolBot document
> > > > Title: IPROTO: The negatiation phase
> > > > For backward compatibility of the data transmission format,
> > > > the negotiation phase has been added to IPROTO.
> > > > A new key (IPROTO_NEGOTIATION) has been added to IPROTO command codes.
> > > > NEGOTIATION BODY: CODE = 0x0E
> > > > +==========================+
> > > > |                          |
> > > > |  NEGOTIATION PARAMETERS  |
> > > > |                          |
> > > > +==========================+
> > > >             MP_MAP
> > > > Session negotiation parameters are a map with keys like ERROR_FORMAT_VERSION ...
> > > > The response is a map with all stated negotiation parameters.
> > > > So, for work with the new format of errors, it is necessary to perform the negotiation phase,
> > > > otherwise errors will be transmitted in the old format (by default).
> > > 
> > > Why not make it a key in IPROTO_AUTH, and require a separate
> > > round-trip?
> > Hi. Because it's not a part of AAA.
> 
> We discussed it a bit with Leonid and his main concern is naming. AUTH
> is not about session settings.
> 
> We can rename the packet identifier to, say, ALTER_SESSION within our
> code, but keep the code (a number) the same. (Alternative: introduce a
> new ALTER_SESSION packet, which able to authorize and set session
> parameters; don't sure what is better.)
> 
> (If we'll look into the variant with keeping the packet number.) This
> ALTER_SESSION packet should be backward compatible with AUTH by the
> request and response format (at least for responses for requests w/o
> newly introduced fields).
> 
> ALTER_SESSION should support:
> 
> * Request: acquiring a specific value for a session parameter (any of
>   supported session sessings, not only one).
> * Response: explicitly state that all requested settings were applied
>   (to distinguish old/new server responses, the old one will only do
>   authorization).
> * Should support altering of session settings w/o (re)auth.
> 
> Is it looks okay for you, Leonid?

(After more discussions with Leonid and Sergos.)

However it seems that this extended (or new) package is purely for
optimization. When a new session parameter is added it is available via
_vsession_settings system space and a client may update it just after
AUTH.

Designing of ALTER_SESSION (a kind of AUTH+UPDATE _vsession_settings)
can be excluded from the scope of this task: it is the common mechanism,
which is applicable for all session settings.

A client should take care to wait all in-fly requests before send UPDATE
to _vsession_settings. It is quite simple, however, after connect and
AUTH: there are no in-fly requests at this time.

Aren't I miss anything?

WBR, Alexander Turenko.