On 10/27/2016 04:35 PM, Jon Maloy wrote:
> TIPC multicast messages are currently distributed via L2 broadcast
> or IP multicast to all nodes in the cluster, irrespective of the
> number of real destinations of the message.
>
> In this series we introduce an option to transport messages via
> replication ("replicast") across a selected number of unicast links,
> instead of relying on the underlying media. This option is used when
> true broadcast/multicast is not supported by the media, or when the
> number of true destinations is much smaller than the cluster size.
>
> v2: -Fixed a counter bug when removing nodes from destination node list
>     - Moved definition of node destination list from to bcast.{h,c}
>
> Jon Maloy (4):
>   tipc: add function for checking broadcast support in bearer
>   tipc: add functionality to lookup multicast destination nodes
>   tipc: introduce replicast as transport option for multicast
>   tipc: make replicast a user selectable option
>
>  include/uapi/linux/tipc.h |   6 +-
>  net/tipc/bcast.c          | 245 
> +++++++++++++++++++++++++++++++++++++++++-----
>  net/tipc/bcast.h          |  40 +++++++-
>  net/tipc/bearer.c         |  15 ++-
>  net/tipc/bearer.h         |   6 ++
>  net/tipc/link.c           |  12 ++-
>  net/tipc/msg.c            |  17 ++++
>  net/tipc/msg.h            |   2 +
>  net/tipc/name_table.c     |  33 +++++++
>  net/tipc/name_table.h     |   4 +
>  net/tipc/node.c           |  27 +++--
>  net/tipc/node.h           |   4 +-
>  net/tipc/socket.c         |  89 ++++++++++-------
>  net/tipc/udp_media.c      |   8 +-
>  14 files changed, 424 insertions(+), 84 deletions(-)
>
[partha]
I have a general concern that this design might not work for 
non-blocking sockets or blocking socket which set MSG_DONTWAIT flag.

Consider that the user is using replicasting to 4 peers.
For ex, in tipc_rcast_xmit() we manage to xmit to the first two peers 
successfully but the next peer(3) fails due to link congestion. Since 
this is a non blocking call we return EAGAIN to user.
The subsequent retry from user will re-deliver the same message to the 
first two peers.

The checks for the congestion are now based on the limits on unicast 
links. We will get into the above situation easily as the traffic 
pattern on all links are not the same.

I think you will have a solution to this as always :-).
[/partha]


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion

Reply via email to