Publisher needs to terminate lagging subscriptions

[magnusfeuer]

A publisher tracks packet acknowledgement for each subscriber through rmc_pub_context:subscribers[].inflight and
If a subscriber fails to acknowledge an inflight packet sent out via multicast within RMC_DEFAULT_PACKET_TIMEOUT microseconds, the packet will be resent by the publisher via the dedicated tcp control channel to the lagging subscriber.
However, the tcp resend can also be stalled due to the subscriber failing to read it in a timely manner, leading to full queues and resource hogging.

In these cases the publisher must terminate the tcp connection to the subscriber, effectively ending the subscription, to free up the resources.

The metric to see if a subscriber should be terminated is the delta between the oldest packet (lower packed id) in the subscriber's inflight list with the oldest packet in all other subscriber's inflight list.

The greatest delta found tells us how far ahead (in packets) the fastest subscriber is in comparison with the slowest. At some TBD distance threshold the subscription shall be terminated.