From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Subject: Re: [tarantool-patches] Re: [PATCH v3 5/6] [RAW] swim: send one UDP packet per EV_WRITE event References: <606bb0e206b7f6a4a45a92e9d200e35d58e815f1.1546077015.git.v.shpilevoy@tarantool.org> <20190109135344.GF20509@chai> From: Vladislav Shpilevoy Message-ID: <7ec57f09-997d-c0bd-929f-72307a0ea136@tarantool.org> Date: Tue, 15 Jan 2019 17:42:11 +0300 MIME-Version: 1.0 In-Reply-To: <20190109135344.GF20509@chai> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit To: tarantool-patches@freelists.org, Konstantin Osipov Cc: vdavydov.dev@gmail.com List-ID: On 09/01/2019 16:53, Konstantin Osipov wrote: > * Vladislav Shpilevoy [18/12/29 15:07]: >> Since the first commit of #3234, where anti-entropy component was >> introduced, a single SWIM message could be split into multiple >> UDP packets. But so far these packets were being sent in mere >> 'for' loop on a single EV_WRITE event. It is not proper way of >> using event loop, but the simplest, because does not require any >> externally stored positions in packet lists. >> >> The previous commit introduced such global list of UDP packets to >> send, and now it is much simpler to send each packet on separate >> EV_WRITE event. This commit does it. >> > > Looks like this commit breaks encapsulation of the transport > layer. It does not. In fact, this commit does not change protocol code at all and affects only swim_io.c/.h. I think, this is a prove that it does not break encapsulation, doesn't it? > > One thing, is that we should not have tasks which require sending > multiple packets. Multipacket is required since it is hard to fit many events, failure detection and anti-entropy components, especially with payloads, into a single 1.5Kb packet. > > Another is that the packet concept is part of the transport and > should not leak into the protocol itself. > > As I understood from our verbal conversation, you mistakenly think that packets are dependent on each other, and multi-packet here works like a weird TCP, with splitting message into packets and concatenating them back on receiver side, but it is wrong. Each packet is self-sufficient piece of data, which is processed independently from other packets. Each packet carries all necessary headers and a chunk of events, anti-entropy records etc. Multi-packet here is in fact multi-message already. Loss of some packets does not affect processing of other ones. struct swim_msg encapsulates multi-packet UDP encoding, while struct swim_task encapsulates multi-packet sending. This is why this commit so easily changes multi-packet sending from one EV_WRITE to multiple EV_WRITE - one per each packet. For protocol, swim.c, struct swim_msg looks like a one big packet, while swim_io.c is able to send swim_msg in multiple independent packets which should not be concatenated on receiver side. Receiver reads packets, struct swim_packet. Not the entire struct swim_msg. And processes the packets one by one.