From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id E83832C7DC for ; Thu, 25 Apr 2019 06:39:51 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lel8x3xXpv_Y for ; Thu, 25 Apr 2019 06:39:51 -0400 (EDT) Received: from smtp56.i.mail.ru (smtp56.i.mail.ru [217.69.128.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id A6C7C2C7D6 for ; Thu, 25 Apr 2019 06:39:51 -0400 (EDT) Date: Thu, 25 Apr 2019 13:39:49 +0300 From: Konstantin Osipov Subject: [tarantool-patches] Re: [PATCH 5/6] swim: introduce routing Message-ID: <20190425103949.GE29257@atlas> References: <6592ce57d8b6c7ef46202551f858a37ca2e18a2c.1556116199.git.v.shpilevoy@tarantool.org> <20190424164659.GE13687@atlas> <52489504-ffa3-abbc-eb5c-8919d2da8d33@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52489504-ffa3-abbc-eb5c-8919d2da8d33@tarantool.org> Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-Help: List-Unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-Subscribe: List-Owner: List-post: List-Archive: To: Vladislav Shpilevoy Cc: tarantool-patches@freelists.org * Vladislav Shpilevoy [19/04/25 00:46]: > > > On 24/04/2019 19:46, Konstantin Osipov wrote: > > * Vladislav Shpilevoy [19/04/24 18:50]: > > > > there is a couple of things I don't understand: > > > > - how do you make a decision that you need to use a proxy? is it > > random? is it if there are too many unacknowledged pings? > > First of all this patch does not use proxies at all. It just introduces > new section SWIM_META_ROUTING. > > Answering your question - the second option. The last patch, which > introduces suspicion, uses proxy when too many direct pings are > unacked. > > > > > - how do you make a decision which proxy to use? Do you choose a > > single peer or all available peers when you need to send a > > message via a proxy? > > I choose multiple random proxies as the SWIM paper says. > > > > > - how is the result returned to the sender? > > I send an answer via the same proxy. > > > As far as I can see > > from the route section, there is only source and destination > > addresses, but it doesn't contain entire routing path. > > In fact it does. Meta contains SWIM_META_ROUTING + > {SWIM_META_SRC_PORT, SWIM_META_SRC_ADDRESS}. It is 3 ip/port pairs. > > SWIM_META_SRC_PORT/ADDRESS is the message sender, always. > > SWIM_META_ROUING contains the message originator (it is not > always sender), and the destination. > > Let's consider an example. There are 3 nodes S1, S2, S3. S1 > sends a ping to S3 via S2. > > S1 -> S2 > { > route: {src: S1, dst: S3}, > src: S1 > } > > S2 -> S3 > { > route: {src: S1, dst: S3}, > src: S2 > } > > S3 -> S2 > { > route: {src: S3, dst: S1}, > src: S3 > } > > S2 -> S1 > { > route: {src: S3, dst: S1}, > src: S2 > } > > > As you can see, 'src' is set to real sender > on each hop. 'route' is unchanged until the > message reaches the end. > > 'src' is used by S3 to send the response back > via the same proxy. > > > Do you > > assume there is always only one intermediate hop in case of an > > indirect ping and always respond to the direct sender, assuming > > the sender has a direct connection to the originator? > > Yes, I send an indirect message only via one intermediate member, > as the SWIM paper says. And respond by the same route. > > > > > Please document answers to these questions in the code, it > > constitutes the mechanics of indirect pings. > > Most of your questions are answered in comments inside the > next commit. But you fairly noticed that it is worth > documenting that only one additional hop is possible. Arbitrary > routes of any length are not implemented. I thought about it, but > decided it would be ultra overkill for such a simple task. > > A new comment: This comment is good but could be even better if it contains answers to all of the questions, not just how routing is done: > > - how do you make a decision that you need to use a proxy? is it > > random? is it if there are too many unacknowledged pings? > > First of all this patch does not use proxies at all. It just introduces > new section SWIM_META_ROUTING. OK, but when I look at routing itself I want to know how it's used. Even if this patch does not use the routing, I want a patch with a comment about the usage. Please feel free to add to the current comment or submit separately. > > Answering your question - the second option. The last patch, which > introduces suspicion, uses proxy when too many direct pings are > unacked. > > > > > - how do you make a decision which proxy to use? Do you choose a > > single peer or all available peers when you need to send a > > message via a proxy? > > I choose multiple random proxies as the SWIM paper says. Please document this decision and the reasons for it as you stated above. > >> +void > >> +swim_task_proxy(struct swim_task *task, const struct sockaddr_in *proxy) > > > > Why not "swim_task_set_proxy_addr"? > > 1) Because the transport level operates on addresses only. It is excessive > to say everywhere '_addr' suffix. It is impossible to send to UUID or > anything else except inet address; > > 2) For consistency - 'swim_task_send()' is not named > 'swim_task_send_to_addr()'; > > 3) '_addr' suffix is too long. I tried it on the first SWIM version, > but it does not help at all, only pads the code out. Then swim_task_set_proxy(). A method should have a verb in its name, otherwise the name looks like a constructor. -- Konstantin Osipov, Moscow, Russia, +7 903 626 22 32 http://tarantool.io - www.twitter.com/kostja_osipov