Repair Packets

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 2011-11-05