📄 example_srm.html
字号:
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1252">
<META NAME="Generator" CONTENT="Microsoft Word 97">
<TITLE>SRM using NS-2:</TITLE>
</HEAD>
<body background="Icons/parchment.gif" text="#000000" link="#0000FF"
vlink="#000080" alink="#FF0000">
<br>
<center><h2>SRM using NS-2</h2></center>
<br><br>
<P ALIGN="JUSTIFY">This section gives an overview of the implementation of SRM in NS. Running an SRM simulation requires </P>
<UL>
<P ALIGN="JUSTIFY"><LI>creating and configuring the agent,</LI></P>
<P ALIGN="JUSTIFY"><LI>attaching an application level data source (a traffic generator), and</LI></P>
<P ALIGN="JUSTIFY"><LI>starting the agent and the traffic generator.</LI></P></UL>
<P ALIGN="JUSTIFY">The key steps in configuring a virgin SRM agent are to assign its multicast group and attach it to a node. Other useful configuration parameters are to assign a separate flow id to traffic originating from this agent, to open log file for statistics, and a trace file for trace data. The agent does not generate any application data on its own; instead the simulation user can connect any traffic generation module to any SRM agent to generate data. The user can attach any traffic generator to n SRM agent. The SRM agent will add the SRM headers, set the destination address to the multicast group and deliver the packet to its target. SRM header contains the type of message, identity of the sender, the sequence number of the message, the round for which this message is being sent.Each data unit in SRM is identified as <I>< sender抯 id, message sequence number ></I>. The SRM agent does not generate its own data; it does not also keep track of the data sent except to record the sequence numbers of messages received in the event that it has to do error recovery. Since the agent has no actual record of the past data, it needs to know what packet size to use for each repair message. The agent and the traffic generator must be started separately using : <I>$srm start</I> and <I>$exp0 start</P>
</I><P ALIGN="JUSTIFY">At start, the agent joins the multicast group and starts generating the session messages. </P>
<P ALIGN="JUSTIFY">Each agent tracks two sets of statistics: statistics to measure the response to data loss and overall statistics for each request/repair. </P>
<B><I><P ALIGN="JUSTIFY">Data Loss:</P>
</B></I><P ALIGN="JUSTIFY">The statistics to measure the response to data losses track the duplicate request (and repair), and the average request (and repair) delay. Each new request (or repair) starts a new request (or repair) period. During the request (or repair) period, the agent measures the number of first round duplicate requests (or repair) until the round terminates either due to receiving a request (or repair) or due to the agent sending one. </P>
<B><I><P ALIGN="JUSTIFY">Overall Statistics:</P>
</B></I><P ALIGN="JUSTIFY">In addition, each loss recovery and session object keeps a track of times and statistics. In particular, each object records its <I>startTime. ServiceTime, distance,</I> are relevant to the object; startTime is the time that this object was created, serviceTime is the time for this object to complete its task, and the distance is the one-way time to reach the remote peer.</P>
<P ALIGN="JUSTIFY">For request objects, startTime is the time a packet loss is detected, serviceTime is the time to finally receive that packet and the distance is the distance to the original sender of the packet. For repair objects, startTime is the time that a request for retransmission is received, serviceTime is the time to send a repair and the distance is the distance to the original requester. For both types of objects, the serviceTime is normalized by distance. For the session object, startTime is the time that the agent joins the multicast group, serviceTime and distance are not relevant.</P>
<P ALIGN="JUSTIFY">Each object also maintains statistics particular to that type of object. Request objects track the number of duplicate requests and repairs received, the number of requests sent, and the number of times that this object had to backoff before finally receiving the data. Repair objects track the number of duplicate requests and repairs, as well as whether or not this object for this agent sent the repair. Session objects simply record the number of session messages sent.</P>
<P ALIGN="JUSTIFY">The values of timers and the statistics for each object are written to the log file every time an object completes the error recovery function it was tasked to do.</P>
<B><I><P ALIGN="JUSTIFY">Tracing :</P>
</B></I><P ALIGN="JUSTIFY">Each object writes out trace information that can be used to track the progress of the object in its error recovery. Each trace entry is of the form:</P><DIR>
<DIR>
<DIR>
<DIR>
<P ALIGN="JUSTIFY"><prefix> <tag> <type of entry> <values></P></DIR>
</DIR>
</DIR>
</DIR>
<P ALIGN="JUSTIFY">The prefix is as described in the previous section for statistics. The tag is Q for requets objects, P for repair objects, and S for session objects.</P>
<B><I><P ALIGN="JUSTIFY">Architecture and Internals:</P>
</B></I><P ALIGN="JUSTIFY">The SRM agent implementation splits the protocol functions into packet handling, loss recovery, and session message activity.</P>
<UL>
<P ALIGN="JUSTIFY"><LI>Packet handling consists of forwarding application data messages, sending and receipt of control messages. These activities are executed by C++ methods.</LI></P>
<P ALIGN="JUSTIFY"><LI>Error detection done in C++ due to receipt of error messages. However, loss recovery is entirely done through instance procedures in Otcl.</LI></P>
<P ALIGN="JUSTIFY"><LI>The sending and processing of messages is accomplished in C++; the policy about when these messages should be sent is decided by instance procedures in Otcl</LI></P></UL>
<B><I><P ALIGN="JUSTIFY">Packet Handling</B>: </I>Processing received messages.</P>
<P ALIGN="JUSTIFY">The recv() method can receive 4 types of messages: data, request, repair and session messages.</P>
<P ALIGN="JUSTIFY">Data Packets</P>
<P ALIGN="JUSTIFY">The agent does not generate any data messages. The user has to specify an external agent to generate traffic. The recv() method must distinguish between locally originated data, that must be sent to the multicast group, and the data received from the multicast group that must be processed. Therefore, the application agent must set the packet's destination address to zero.</P>
<P ALIGN="JUSTIFY">For locally originated data, the agent adds the appropriate SRM headers, sets the destination address to the multicast group and forwards the packet to its target.</P>
<P ALIGN="JUSTIFY">On receiving a data message from the group, the recv_data(sender, msgid) will update its state marking message <sender, msgid> received, and possibly trigger requests if it detects losses. In addition, if the message was an older message received out of order, then there must be a pending request or repair that must be cleared. In that case, the compiled object invokes the Otcl instance procedure, recv-data {sender,msgid}.</P>
<P ALIGN="JUSTIFY">Currently, there is no provision for receivers to actually receive any application data. The agent does not also store any of the user data. It only generates repair messages of the appropriate size, defined by instance variable packetSize_. However, the agent assumes that any application data is placed in the data portion of the packet, pointed to by </P>
<P ALIGN="JUSTIFY">packet->accessdata().</P>
<B><I><P ALIGN="JUSTIFY">Request Packets :</P>
</B></I><P ALIGN="JUSTIFY">On receiving a request, recv_rqst(sender, msgid) will check whether it needs to schedule requests for other missing data. If it has received this request before it was aware that the source had generated this data message(i.e the sequence no. of this message is higher than the last known sequence no. of data from this source), then the agent can infer that it is missing this, as well as data from the last known sequence no. onwards; it schedules requests for all of the missing data and returns. On the other hand, if the seuqence no. of the request is less than the last know sequence no. from the source, then the agent can be in one of the three states: a) it does not have this data, and has a requets pending for it, b) it has the data, and has seen an earlier request, upon which it has a repair pending for it, or c) it has the data, and it should instantiate a repair. All of these error recovery mechanisms are done in OTcl; recv_rqst() invokes the instance procedure recv-rqst{sender, msgid, requester} for futher processing.</P>
<B><I><P ALIGN="JUSTIFY">Repair Packets :</P>
</B></I><P ALIGN="JUSTIFY">On receiving a repair packet, recv_repr(sender, msgid) 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(i.e. the sequence no. of the repair is higher than the last known sequence no. from this source), then the agent can infer that it is missing all data between the last known sequence no. 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 no. of the request is lesser than the last known sequence no. from the source, then the agent can be in one of the 3 states; a) it does not have the data. and has a request pending for it, b) it has the data, and has seen an earlier request, upon which it has a repair pending for it, or c) it has the data, and probably scheduled a repair for it at some time; after recovery it holds down its 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 recv-repr{sender, msgid} to complete the loss recovery phase for the particular message.<I> </P>
<B><P ALIGN="JUSTIFY">Session Packets :</P>
</B></I><P ALIGN="JUSTIFY">On receiving a session message, the agent updates its sequence numbers for all the active sources, and computes its instantaneous distance to the sending agent if possible. This agent will ignore earlier session messages from a group member, if it has received a later one out of order.</P>
<P ALIGN="JUSTIFY">Session message processing is done in recv_sess(). The format of the session message is:<count of tuples in this message, list of tuples>, where each tuple indicates the <sender id, last sequence no. from the source, time the last session message was received from this sender, time that the message was sent>. The first tuple is the information about the local agent.</P>
<P ALIGN="JUSTIFY">It is possible to trivially obtain two flavors of SRM based on whether the agents use probabilistic or deterministic suppression. The default request and repair timer parameter for each SRM agent are </P>
<P ALIGN="JUSTIFY">Agent/ SRM set C1_	 2.0</P>
<P ALIGN="JUSTIFY">Agent/ SRM set C2_ 2.0</P>
<P ALIGN="JUSTIFY">Agent/ SRM set D!_	 1.0</P>
<P ALIGN="JUSTIFY">Agent/ SRM set D2_	 1.0</P>
<B><I><P ALIGN="JUSTIFY">Deterministic Suppressions</I>:</P>
</B><P ALIGN="JUSTIFY">Class Agent/ SRM/ Deterministic ⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -