Re: [tarantool-patches] Re: [PATCH v3 5/6] [RAW] swim: send one UDP packet per EV_WRITE event

[Vladislav Shpilevoy <v.shpilevoy@tarantool.org>]

On 09/01/2019 16:53, Konstantin Osipov wrote:
> * Vladislav Shpilevoy <v.shpilevoy@tarantool.org> [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.