From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f194.google.com (mail-lj1-f194.google.com [209.85.208.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 0AE434696C3 for ; Tue, 24 Mar 2020 23:02:18 +0300 (MSK) Received: by mail-lj1-f194.google.com with SMTP id s13so48521ljm.1 for ; Tue, 24 Mar 2020 13:02:18 -0700 (PDT) Date: Tue, 24 Mar 2020 23:02:16 +0300 From: Konstantin Osipov Message-ID: <20200324200216.GA18984@atlas> References: <7982fc7b062b2424689a990de1f76ca2ff0e4f50.1585053743.git.lvasiliev@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7982fc7b062b2424689a990de1f76ca2ff0e4f50.1585053743.git.lvasiliev@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: Leonid Vasiliev Cc: tarantool-patches@dev.tarantool.org * 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? Why have it at all and not look at server version, which is part of the greeting already? -- Konstantin Osipov, Moscow, Russia