From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <alexander.turenko@tarantool.org>
Received: from smtp59.i.mail.ru (smtp59.i.mail.ru [217.69.128.39])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by dev.tarantool.org (Postfix) with ESMTPS id 7D419442BB4
 for <tarantool-patches@dev.tarantool.org>;
 Fri, 27 Mar 2020 00:53:04 +0300 (MSK)
Date: Fri, 27 Mar 2020 00:53:07 +0300
From: Alexander Turenko <alexander.turenko@tarantool.org>
Message-ID: <20200326215307.aczkbhqz2raf6bko@tkn_work_nb>
References: <cover.1585053742.git.lvasiliev@tarantool.org>
 <7982fc7b062b2424689a990de1f76ca2ff0e4f50.1585053743.git.lvasiliev@tarantool.org>
 <20200324200216.GA18984@atlas>
 <178dd6a0-cdee-532c-3d0a-af76062d5f6c@tarantool.org>
 <20200326211343.yx5zretcu6fwrlfr@tkn_work_nb>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20200326211343.yx5zretcu6fwrlfr@tkn_work_nb>
Subject: Re: [Tarantool-patches] [PATCH 3/6] iproto: Add negotiation phase
List-Id: Tarantool development patches <tarantool-patches.dev.tarantool.org>
List-Unsubscribe: <https://lists.tarantool.org/mailman/options/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=unsubscribe>
List-Archive: <https://lists.tarantool.org/pipermail/tarantool-patches/>
List-Post: <mailto:tarantool-patches@dev.tarantool.org>
List-Help: <mailto:tarantool-patches-request@dev.tarantool.org?subject=help>
List-Subscribe: <https://lists.tarantool.org/mailman/listinfo/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=subscribe>
To: lvasiliev <lvasiliev@tarantool.org>
Cc: tarantool-patches@dev.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.