netdev - Re: [net-next v3 3/3] tipc: smooth change between replicast and broadcast

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 19 Mar 2019 13:56:42 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     hoang.h.le@...tech.com.au
Cc:     tipc-discussion@...ts.sourceforge.net, jon.maloy@...csson.com,
        maloy@...jonn.com, ying.xue@...driver.com, netdev@...r.kernel.org
Subject: Re: [net-next v3 3/3] tipc: smooth change between replicast and
 broadcast

From: Hoang Le <hoang.h.le@...tech.com.au>
Date: Tue, 19 Mar 2019 18:49:50 +0700

> Currently, a multicast stream may start out using replicast, because
> there are few destinations, and then it should ideally switch to
> L2/broadcast IGMP/multicast when the number of destinations grows beyond
> a certain limit. The opposite should happen when the number decreases
> below the limit.
> 
> To eliminate the risk of message reordering caused by method change,
> a sending socket must stick to a previously selected method until it
> enters an idle period of 5 seconds. Means there is a 5 seconds pause
> in the traffic from the sender socket.
> 
> If the sender never makes such a pause, the method will never change,
> and transmission may become very inefficient as the cluster grows.
> 
> With this commit, we allow such a switch between replicast and
> broadcast without any need for a traffic pause.
> 
> Solution is to send a dummy message with only the header, also with
> the SYN bit set, via broadcast or replicast. For the data message,
> the SYN bit is set and sending via replicast or broadcast (inverse
> method with dummy).
> 
> Then, at receiving side any messages follow first SYN bit message
> (data or dummy message), they will be held in deferred queue until
> another pair (dummy or data message) arrived in other link.
> 
> v2: reverse christmas tree declaration
> 
> Acked-by: Jon Maloy <jon.maloy@...csson.com>
> Signed-off-by: Hoang Le <hoang.h.le@...tech.com.au>

Applied.