Update group member status basing on packet type

[ethouris]

This provides two fixes:

1. When a data packet is coming in, the link turns IDLE -> RUNNING. Even if the packet is going to be effectively rejected. This is important because RUNNING links will not get updated the reception sequence when the buffer is empty. Updating this sequence while data packets were received was causing the "runaway train" effect, that is, while every incoming packet would come with increasing sequence, the synchronization was pushing the sequence forward in the meantime, which caused that incoming packets were seen as belated virtually forever.

2. Turning link to IDLE on sender state in case when keepalive has come and the link is outside the "temporary activation" state. The second condition prevents the link from being treated as IDLE in case when it was just activated and still tries to transmit old packets that are not surely acknowledged, but have been actually received over a broken link. This "initial burst" that happens after the link switch might effectively delay the ACK report and make the receiver side generate a KEEPALIVE message.

[gou4shi1]

Hi @ethouris , can you help to explain that why need_notify_loss would be introduced here?

[ethouris]

@gou4shi1 This is to prevent checking for loss for a freshly turned-to-running link. If this isn't done then the sequence distance between the last reception - which in this case, as a group member, is artificially updated to be in synch with other links in the group - and the current packet reception would be treated as loss and loss-reported. This actually isn't a loss because the "previous" sequence is not really a received packet sequence. After turning to RUNNING state though since this moment this range should be treated as a loss.

[gou4shi1]

@ethouris Thanks for you explanation, but it may introduce unrecoverable packet loss (#2236), which is unacceptable for message mode.
I found that sender would just ignore loss-report behind m_iSndLastAck and send a corresponding drop-request, maybe it's harmless to send a possible-fake-loss-report?

[ethouris]

You mean, if there are initial packets lost before the one that has been sent?

Likely I may have missed something, that was a long time ago. Not sure how the synchronization works with the statement of the ACK-ed packets. Maybe an additional check should be made within this loop and the range between the last ACK-ed, maybe shifted by the last received within the group, should be treated as loss. If it's not empty.

[gou4shi1]

You mean, if there are initial packets lost before the one that has been sent?

I mean there are initial packets lost before the first one that has been received.