SFC does not control unicast messages. This makes it unsuitable for UDP-based channels that will handle a lot of unicast, e.g. a channel used by a buddy replication-enabled JBoss Cache. Also makes it unsuitable for use as a shared multiplexed channel when one of the services might use a lot of unicast.

Proposed solution is to refactor the core locking and credit accounting behavior of SFC into an inner class. SFC would then maintain an instance of that inner class to track credits for group (i.e. multipoint) messages. A separate instance of the inner class would be maintained to track unicast traffic to each peer. So, in a 4 node cluster, SFC would maintain 5 instances of the inner class. (Maintaining an instance for unicast messages to oneself is probably unnecessary, but its a lightweight object and not maintaining it would add complexity.)

Will add a "control_unicast" config flag with default value of true. Allows simple disabling of unicast flow control in TCP-based configurations.