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

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

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?

WBR, Alexander Turenko.