Messaging

Datagram messaging

  • Unicast, anycast or multicast, depending on address type used, - socket address, service address or service range.
  • If there is more than one socket matching a given service address, the destination is selected on a round-robin basis.

  • Reliable transport node to node.
  • Receive socket buffer overload protection
  • No end-to-end flow control, so messages may still be rejected by receiving socket.
  • Rejected messages may be dropped or returned to sender, as configured by sending socket.
  • If returned, message is truncated and equipped with an error code.

    • Connections

    Connections are established by using either a service address or a socket address

    • One-way setup (a.k.a. “0-RTT”) using data-carrying messages
    • Or traditional TCP-style setup



  • Stream- or message oriented.
  • End-to-end flow control for socket receive buffer overflow protection.
  • No socket level sequence numbers, acknowledges or retransmissions, - link layer takes care of that.

    • Connection breaks immediately if peer becomes unavailable.

  • Leverages link level heartbeats and kernel/socket cleanup functionality.
  • No socket level “keepalive” heartbeats needed.


    • Communication Groups

    Communication groups can be described as brokerless message bus instances. Such instances are user created, - the first joining member socket implicitly creates the group. This feature is available from Linux 4.14.

    • A socket joins a group by indicating a service address, - the address type field serves as group identity, the address instance field serves as member identity.
    • Groups are closed, - members can only exchange messages with other sockets in the same group.
    • Each member socket has two addresses: a socket address bound by the system and a service address (group:member tuple) bound by the user. Both addresses are delivered to a message receiving user.
    • Member sockets may optionally provide the user with join/leave events for other group members, leveraging the service tracking capabilities of the binding table.
    • Member sockets may optionally receive loopback copies of their own anycast/multicast/broadcast messages.

    Within a group there are four different transmission modes available.

    • Unicast when the sender indicates a socket address as destination.
    • Anycast when the sender indicates a service address as destination. If there is more than one matching destination, one will be selected by round-robin, but also considering the destination's load, which can be inferred from the destination's advertised window.
    • Multicast when the sender indicates a service range as destination. If there is more than one matching destination, all of them will receive a copy of the sent message.
    • Broadcast when the sender uses the send() primitive with no destination address. All member sockets, irrespective of member instance number, receive a copy of the message.
    • Both broadcast and multicast leverage Ethernet broadcast/UDP multicast when possible and deemed favorable.

    Delivery and sequence order is guaranteed, even between different transmission modes. Among other things, this implies that all messages must be subject to end-to-end flow control.

    • Messages will never be dropped because of destination buffer overflow.
    • Same mechanism covers all tranmsmission modes.
    • Point-to-point and point-to-multipoint: - “sliding window” algorithm.
    • Multipoint-to-point: - “coordinated sliding window” algorithm, unique for TIPC.