1. 15 10月, 2017 39 次提交
  2. 13 10月, 2017 1 次提交
    • D
      Merge branch 'tipc-comm-groups' · a00344bd
      David S. Miller 提交于
      Jon Maloy says:
      
      ====================
      tipc: Introduce Communcation Group feature
      
      With this commit series we introduce a 'Group Communication' feature in
      order to resolve the datagram and multicast flow control problem. This
      new feature makes it possible for a user to instantiate multiple private
      virtual brokerless message buses by just creating and joining member
      sockets.
      
      The main features are as follows:
      ---------------------------------
      - Sockets can join a group via a new setsockopt() call TIPC_GROUP_JOIN.
        If it is the first socket of the group this implies creation of the
        group. This call takes four parameters: 'type' serves as group
        identifier, 'instance' serves as member identifier, and 'scope'
        indicates the visibility of the group (node/cluster/zone). Finally,
        'flags' indicates different options for the socket joining the group.
        For the time being, there are only two such flags: 1) 'LOOPBACK'
        indicates if the creator of the socket wants to receive a copy of
        broadcast or multicast messages it sends to the group, 2) EVENTS
        indicates if it wants to receive membership (JOINED/LEFT) events for
        the other members of the group.
      
      - Groups are closed, i.e., sockets which have not joined a group will
        not be able to send messages to or receive messages from members of
        the group, and vice versa. A socket can only be member of one group
        at a time.
      
      - There are four transmission modes.
        1: Unicast. The sender transmits a message using the port identity
           (node:port tuple) of the receiving socket.
        2: Anycast. The sender transmits a message using a port name (type:
           instance:scope) of one of the receiving sockets. If more than
           one member socket matches the given address a destination is
           selected according to a round-robin algorithm, but also considering
           the destination load (advertised window size) as an additional
           criteria.
        3: Multicast. The sender transmits a message using a port name
           (type:instance:scope) of one or more of the receiving sockets.
           All sockets in the group matching the given address will receive
           a copy of the message.
        4: Broadcast. The sender transmits a message using the primtive
           send(). All members of the group, irrespective of their member
           identity (instance) number receive a copy of the message.
      
      - TIPC broadcast is used for carrying messages in mode 3 or 4 when
        this is deemed more efficient, i.e., depending on number of actual
        destinations.
      
      - All transmission modes are flow controlled, so that messages never
        are dropped or rejected, just like we are used to from connection
        oriented communication. A special algorithm guarantees that this is
        true even for multipoint-to-point communication, i.e., at occasions
        where many source sockets may decide to send simultaneously towards
        the same  destination socket.
      
      - Sequence order is always guaranteed, even between the different
        transmission modes.
      
      - Member join/leave events are received in all other member sockets
        in guaranteed order. I.e., a 'JOINED' (an empty message with the OOB
        bit set) will always be received before the first data message from
        a new member, and a 'LEAVE' (like 'JOINED', but with EOR bit set) will
        always arrive after the last data message from a leaving member.
      
      -----
      v2: Reordered variable declarations in descending length order, as per
          feedback from David Miller. This was done as far as permitted by the
          the initialization order.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a00344bd