From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-f66.google.com (mail-lf1-f66.google.com [209.85.167.66]) (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 EC27D441841 for ; Thu, 26 Mar 2020 15:16:55 +0300 (MSK) Received: by mail-lf1-f66.google.com with SMTP id j17so4595298lfe.7 for ; Thu, 26 Mar 2020 05:16:55 -0700 (PDT) Date: Thu, 26 Mar 2020 15:16:53 +0300 From: Konstantin Osipov Message-ID: <20200326121653.GA6796@atlas> References: <7982fc7b062b2424689a990de1f76ca2ff0e4f50.1585053743.git.lvasiliev@tarantool.org> <20200324200216.GA18984@atlas> <178dd6a0-cdee-532c-3d0a-af76062d5f6c@tarantool.org> <20200325084205.GG18984@atlas> <09a887d4-7459-683b-8a10-c3a0d27bc8c3@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <09a887d4-7459-683b-8a10-c3a0d27bc8c3@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/26 14:18]: > Now it does't look like a session control packet because auth packet will be > sent to server only if authentication is needed ("Authentication in > Tarantool is optional, if no authentication is performed, session user is > ‘guest’"). But, theoretically, it can be used. You can authenticate guest to guest, it will work. > In this case, the answer must be changed from ok/fail to the answer with > payload. > In my opinion the negotiation looks as: > - the client offers options for the session > - the server sends the resulting response with options (which may differ > from the requested) > - the client decides to work with such settings or disconnect > I think that negotiation phase can be used for flexible session setup in the > future (not only for errors) Cost of establishing a connection should be as low as possible. A sharded tarantool cluster has n^2 of them, and n can be very big - each cpu core is its own instance. 400 000 connections per cluster are not uncommon. -- Konstantin Osipov, Moscow, Russia