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 7E635441841 for ; Wed, 25 Mar 2020 11:42:07 +0300 (MSK) Received: by mail-lj1-f194.google.com with SMTP id 19so1513523ljj.7 for ; Wed, 25 Mar 2020 01:42:07 -0700 (PDT) Date: Wed, 25 Mar 2020 11:42:05 +0300 From: Konstantin Osipov Message-ID: <20200325084205.GG18984@atlas> 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 Content-Transfer-Encoding: 8bit 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 * lvasiliev [20/03/25 10:36]: > > Why not make it a key in IPROTO_AUTH, and require a separate > > round-trip? > Hi. Because it's not a part of AAA. 1. Auth packet is a session control packet. Authentication is only one thing you may want to do with the session, you may want to simply switch between already authenticated users. 2. Adding an extra package adds an extra round-trip and slows down each handshake by at least 1 millisecond. 3. Auth package is synchronous by default. Any other package is not, it's executed in async mode. Meaning the semantics of the new package is broken, it is unclear what responses it affects - those that happen to be not sent yet when this package is handled, but not necessarily those that started processing after this package arrived. > > Why have it at all and not look at server version, which is part > > of the greeting already? > > > The cause is backward compatibility. > For example: a client application may expect an error as a string (IPROTO_OK > case) and instead of which it will receive an error as an “object”. A > greeting is sent only from the server side to the client, but the server > must know what format should be used to send errors (what format does the > client expect). A much simpler way to do it is to have a server switch to enable new features. It is less flexible, of course, because you can't have old and new clients, but do you really want to have old and new clients? -- Konstantin Osipov, Moscow, Russia