[jboss-jira] [JBoss JIRA] Resolved: (JGRP-1154) FC: separate implementations for multicast and unicast messages

[Bela Ban (JIRA)]

     [ https://jira.jboss.org/browse/JGRP-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1154.
----------------------------

    Resolution: Done


Created MFC and UFC; FC has to be replaced by them, e.g. instead of

<FC ... />

use

<UFC ... />
<MFC ... />

Perf tests show that the MFC/UFC combo is as fast (or slightly faster in certain scenarios) as FC. See my email to jg-dev/jg-users for details

> FC: separate implementations for multicast and unicast messages
> ---------------------------------------------------------------
>
>                 Key: JGRP-1154
>                 URL: https://jira.jboss.org/browse/JGRP-1154
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.11
>
>
> Currently, FC handles both multicast (=group) and unicast messages. This has a few disadvantages:
> - Complexity
> - Unicast messages are not dependent on multicast messages (and vice versa), so why should this be different for flow control ? E.g. why 
>    should a multicast message block waiting for credits from X because a recent unicast message was sent to X ?
> - If we have separate flow control protocols for multicasts and unicasts, we can selectively remove one or the other. This is currently
>    not possible
> Design (see separate documents in ./doc/design):
> FC_MCAST:
> -----------------
> (see whether some concepts can be borrowed from SFC)
> Sender:
> - Every sender has a credits AtomicLong variable
> - When sending a  message and the message length exceeds credits, the sender blocks (until it gets credits from all current group members)
> - Else credits is decremented by the message length and the message is sent
> - When credits are received from all current group members, credits is reset to the initial value and all blocked senders are unblocked
> - When a new member joins, credits is also reset and all blocked senders are unblocked
> Receiver:
> - Maintains a hashmap of senders and credits (Map<Address,AtomicLong>)
> - When a message is received from S, the credits for S are decremented by the message length
> - If the remaining length is less than the threshold, new credits are sent to S and S's credits are reset to their initial value
> - When a new member joins, all credits (including the newly joined member) are reset to the initial value
> FC_UNICAST:
> --------------------
> Sender:
> - A hashmap of addresses and credits is maintained: every receiver has associated credits
> - When a message is sent to P, if P's credits minus the message length is less than 0, the sender blocks until it gets new credits from the receiver
> - Else P's credits are decremented by the message length and the message is sent
> Receiver:
> -Same as for FC_MCAST

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira