From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 ; Fri, 27 Mar 2020 00:53:04 +0300 (MSK) Date: Fri, 27 Mar 2020 00:53:07 +0300 From: Alexander Turenko Message-ID: <20200326215307.aczkbhqz2raf6bko@tkn_work_nb> References: <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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: lvasiliev 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 [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.