37.5.0.0.1 Request Mechanisms

SRM agents detect loss when they receive a message, and infer the loss based on the sequence number on the message received. Since packet reception is handled entirely by the compiled object, loss detection occurs in the C++ methods. Loss recovery, however, is handled entirely by instance procedures of the corresponding interpreted object in OTcl.

When any of the methods detects new losses, it invokes []Agent/SRM::request../ns-2/srm.tclAgent/SRM::request with a list of the message sequence numbers that are missing. []request will create a new requestFunction_ object for each message that is missing. The agent stores the object handle in its array of pending_ objects. The key to the array is the message identifier sender:msgid.

• The default requestFunction_ is SRM/request. The constructor for the class SRM/request calls the base class constructor to initialize the simulator instance (ns_), the SRM agent (agent_), trace file (trace_), and the times_ array. It then initializes its statistics_ array with the pertinent elements.

• A separate call to []set-params../ns-2/srm.tclSRM::set-params sets the sender_, msgid_, round_ instance variables for the request object. The object determines C1_ and C2_ by querying its agent_. It sets its distance to the sender (times_(distance)) and fixes other scheduling parameters: the backoff constant (backoff_), the current number of backoffs (backoffCtr_), and the limit (backoffLimit_) fixed by the agent. []set-params writes the trace entry ``Q DETECT''.

• The final step in []request is to schedule the timer to send the actual request at the appropriate moment. The instance procedure []SRM/request::schedule../ns-2/srm.tclSRM/request::schedule uses []compute-delay../ns-2/srm.tclSRM/request::compute-delay and its current backoff constant to determine the delay. The object schedules []send-request../ns-2/srm.tclSRM/request::send-request to be executed after delay_ seconds. The instance variable eventID_ stores a handle to the scheduled event. The default []compute-delay function returns a value uniformly distributed in the interval $[C_1 d_s, (C_1 + C_2) d_s]$, where $d_s$ is twice $times_(distance). The []schedule schedules an event to send a request after the computed delay. The routine writes a trace entry ``Q NTIMER at time''.

When the scheduled timer fires, the routine []send-request../ns-2/srm.tclSRM/request::send-request sends the appropriate message. It invokes ``$agent_ send request args'' to send the request. Note that []send is an instproc-like, executed by the []command method of the compiled object. However, it is possible to overload the instproc-like with a specific instance procedure []send for specific configurations. As an example, recall that the file tcl/mcast/srm-nam.tcl overloads the []send command to set the flowid based on type of message that is sent. []send-request updates the statistics, and writes the trace entry ``Q SENDNACK''.

When the agent receives a control message for a packet for which a pending object exists, the agent will hand the message off to the object for processing.

• When a request for a particular packet is received../ns-2/srm.tclSRM/request::recv-request, the request object can be in one of two states: it is ignoring requests, considering them to be duplicates, or it will cancel its send event and re-schedule another one, after having backed off its timer. If ignoring requests it will update its statistics, and write the trace entry ``Q NACK dup''. Otherwise, set a time based on its current estimate of the delay_, until which to ignore further requests. This interval is marked by the instance variable ignore_. If the object reschedules its timer, it will write the trace entry `` Q NACK IGNORE-BACKOFF ignore''. Note that this re-scheduling relies on the fact that the agent has joined the multicast group, and will therefore receive a copy of every message it sends out.

• When the request object receives a repair for the particular packet../ns-2/srm.tclSRM/request::recv-repair, it can be in one of two states: either it is still waiting for the repair, or it has already received an earlier repair. If it is the former, there will be an event pending to send a request, and eventID_ will point to that event. The object will compute its serviceTime, cancel that event, and set a hold-down period during which it will ignore other requests. At the end of the hold-down period, the object will ask its agent to clear it. It will write the trace entry ``Q REPAIR IGNORES ignore''. On the other hand, if this is a duplicate repair, the object will update its statistics, and write the trace entry ``Q REPAIR dup''.

When the loss recovery phase is completed by the object, []Agent/SRM::clear../ns-2/srm.tclAgent/SRM::clear will remove the object from its array of pending_ objects, and place it in its list of done_ objects. Periodically, the agent will cleanup and delete the done_ objects.