[Spread-users] Broadcast UDP messages will flood network and decrease performance

[John Schultz]

> The fact is that ALL payload messages to private [or public] group send
> to ALL daemons. I traced it via wireshark. Is it true?
> Is anybody repeated my tests?

Yes, as I said before, Spread currently sends all traffic to all daemons. 
There *might* be an optimzation already implemented for private messages 
within a single daemon.

> If it is true, it means that WHOLE "local" traffic goes to external daemons.
> No any filtering by segment... or by group members....
>
> Parasite traffic
>    1) loads network.
>    2) all daemons have to filter traffic. It leads to decrease performance for daemons [and users].

Correct.

> If it is true, which variants are available?
> 1 variant) it is key of spread concept. Multicast cannot change.
> 2 variant) It seems that we (spread developers) haven't any free resources to implement it. May in future... or is someone wanted to help us?

I wouldn't say it *can't* be changed.  On the other hand, I have thought 
about it and it is quite difficult to do.  The general idea would be to 
have the sender send the full message only to those segments that have 
participating group members and to send small meta-messages to the other 
segments, indicating that they don't need the full message.  The most 
difficult changes would be in recovering holes for receivers and handling 
group membership changes that happen around the time of the send.

On the first issue, when a daemon requests a hole to be filled, a 
responding daemon would need to know whether or not the requestor(s) needs 
the full message or the meta-message.  So, both versions of the message 
would need to include, at least, the group names to which the messages 
were sent.  The responder would then need to differentiate resend requests 
based on the requestor, and for example, not respond if the requestor 
needs the whole message and the responder only has the meta-message. 
(Someone with the whole message can derive the meta-message from it and 
respond to either type of request).  This differentiation might require 
changes in the way resend requests are put onto and taken off the token 
(i.e. - the logical byte layout of the token itself).

A trickier problem occurs when the membership of the group changes around 
the time of a send.  If the sender has a hole(s) when it goes to send, 
then the message that hole(s) represents could actually be changing the 
group membership(s) for the groups to which it is sending.  Imagine the 
following scenario:  Daemon #1 sends a join message adding a new member to 
group X and it is the first member for group X on daemon #1.  Daemon #2 
doesn't get that message before it is his turn to send.  According to #2's 
view of the world, Daemon #1 doesn't need the messages A he is sending to 
group X and so it should (incorrectly) only get the meta-message.  This 
problem would require every daemon to check every message to ensure that 
it got the correct version, and to request the full version if it got the 
meta-message.  A similar problem is that daemons trying to recover message 
A for daemon #1 may also have the incorrect view of him and will answer 
his requests with the wrong version.  So, maybe once Daemon #1 incorrectly 
gets the meta version he will have to re-request the full version 
explicitly somehow.

There might be other considerations / problems that Yair or Jonathan can 
point out.

Cheers!

---
John Schultz
Spread Concepts
Phn: 443 838 2200