From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f195.google.com (mail-lj1-f195.google.com [209.85.208.195]) (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 BD57A4696C3 for ; Thu, 26 Mar 2020 16:19:56 +0300 (MSK) Received: by mail-lj1-f195.google.com with SMTP id g12so6382268ljj.3 for ; Thu, 26 Mar 2020 06:19:56 -0700 (PDT) Date: Thu, 26 Mar 2020 16:19:54 +0300 From: Konstantin Osipov Message-ID: <20200326131954.GC8031@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> <20200326121653.GA6796@atlas> <20200326125419.os5yywcjxylpncdc@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200326125419.os5yywcjxylpncdc@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: Kirill Yukhin Cc: tarantool-patches@dev.tarantool.org * Kirill Yukhin [20/03/26 15:58]: > > > 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. > > I think this is pretty much fable. A vshard based cluster with 20 router nodes and 20 storage nodes, 32 core each, will have 20*32*32*16 connections. A 20-40 node cluster is not big by any means. -- Konstantin Osipov, Moscow, Russia