On receiving a repair,
[sender, msgid]recv_repr../ns-2/srm.ccSRMAgent::recv_repr
will check whether it needs to schedule requests for other missing data.
If it has received this repair
before it was aware that the source had generated this data message
(, the sequence number of the repair is higher than
the last known sequence number of data from this source),
then the agent can infer that it is missing all
data between the last known sequence number and that on the repair;
it schedules requests for all of this data,
marks this message as received, and returns.
On the other hand, if the sequence number of the request is less
than the last known sequence number from the source,
then the agent can be in one of three states:
(1) it does not have this data, and has a request pending for it,
(2) it has the data, and has seen an earlier request,
upon which it has a repair pending for it, or
(3) it has the data, and probably scheduled a repair for it at some time;
after error recovery, its hold down timer (equal to three times its
distance to some requester) expired, at which time the pending object
was cleared. In this last situation, the agent will simply ignore
the repair, for lack of being able to do anything meaningful.
All of these error recovery mechanisms are done in OTcl;
[]recv_repr invokes the instance procedure
[sender, msgid]recv-repr../ns-2/srm.tclAgent/SRM::recv-rqst
to complete the loss recovery phase for the particular message.
Tom Henderson
2014-12-17