From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp14.mail.ru (smtp14.mail.ru [94.100.181.95]) (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 9B7FC4696C3 for ; Fri, 27 Mar 2020 00:13:40 +0300 (MSK) Date: Fri, 27 Mar 2020 00:13:43 +0300 From: Alexander Turenko Message-ID: <20200326211343.yx5zretcu6fwrlfr@tkn_work_nb> References: <7982fc7b062b2424689a990de1f76ca2ff0e4f50.1585053743.git.lvasiliev@tarantool.org> <20200324200216.GA18984@atlas> <178dd6a0-cdee-532c-3d0a-af76062d5f6c@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <178dd6a0-cdee-532c-3d0a-af76062d5f6c@tarantool.org> 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 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? WBR, Alexander Turenko.