Re: [tipc-discussion] Enhancement to SOCK_RDM

[Erik H. <eri...@er...>]

> But, who are we if we don't try to achieve the impossible
> for our users ;-)
> 
> I like Erik's idea (it is not new) to attach a load level indicator
> to the publication items. The thoughts I had about this
> was to reserve two bits and use those to indicate load level.
> E.g., 00 = < 70%, 01=70-85%, 10= 85-95%, 11 = >95%
> (and full stop).
Do we need this level of detail? i thought it would be enough with a
flag indicating 'full stop'.

> I assume that the load levels (when > 70%) are broadcast
> out in a new NAME_DISTR message type, since there is no more
> space in the current publication items (yes, I have checked),
> and the NAME_DISTR message header cannot be used for this.
> This would be fully backwards compatible.
> 
> We could then extend the name lookup algorithm to find
> an instance with acceptable laod, and if there is none
> we either block the sender until the overload abates (as we
> do with link congestion now), or we return EAGAIN.
This raises a question for me, maybe we should make it possible
for the sending side to control the send() behavior if one or more
receiving ports are congested with a socket option?
TIPC_ALLOW_PARTIAL_MCAST (boolean 1/0), default 0.
If this is set, and one or more of the recipient ports are 
currently overloaded, we send the message only to the ports 
that are not (could potentially be zero if all ports are overloaded).

> 
> This would, as Erik said, not guarantee against buffer
> overflow, but it should reduce the risk significantly.
Yes, and most importantly, the sending side can know exactly 
which messages have been delivered to the receiver 
(based on the rejected messages).
> 
> There is a risk with this, however. What happens in a heavy
> overloaded system, if a lot of destinations start to broadcast
> overload messages at a massive scale? We may end up with
> worsening the situation, instead of improving it.
Maybe if we limit the amount of broadcast messages indicating 
that the port overload have ceased to 1 per port every link 
timeout period.. but that would require that we keep track of 
all congested ports in a separate list, or iterate through the 
nametable to find congested ports every timeout interval.. 
Not very good.

> It is possible that we should make this feature an opt-in
> service, set via a socket option at the server side. But I would
> prefer to make it default and transparent, if possible.
What if we keep it on by default, but make it opt-out with a socket
option?

> 
> I think only some prototyping and experimenting during
> high load can give the answer here.