The ns Manual (formerly ns Notes and Documentation)1 - NM Lab at ...

The ns Manual (formerly ns Notes and Documentation)1 - NM Lab at ... The ns Manual (formerly ns Notes and Documentation)1 - NM Lab at ...

nmlab.korea.ac.kr
from nmlab.korea.ac.kr More from this publisher
12.07.2015 Views

Other useful configuration parameters are to assign a separate flow id to traffic originating from this agent, to open a log filefor statistics, and a trace file for trace data 1 .The file tcl/mcast/srm-nam.tcl contains definitions that overload the agent’s send methods; this separates controltraffic originating from the agent by type. Each type is allocated a separate flowID. The traffic is separated into sessionmessages (flowid = 40), requests (flowid = 41), and repair messages (flowid = 42). The base flowid can be changed by settingglobal variable ctrlFid to one less than the desired flowid before sourcing srm-nam.tcl. To do this, the simulation scriptmust source srm-nam.tcl before creating any SRM agents. This is useful for analysis of traffic traces, or for visualizationin nam.Application Data Handling The agent does not generate any application data on its own; instead, the simulation user canconnect any traffic generation module to any SRM agent to generate data. The following code demonstrates how a trafficgeneration agent can be attached to an SRM agent:set packetSize 210set exp0 [new Application/Traffic/Exponential]$exp0 set packetSize_ $packetSize$exp0 set burst_time_ 500ms$exp0 set idle_time_ 500ms$exp0 set rate_ 100k;# configure traffic generator$exp0 attach-agent $srm0$srm0 set packetSize_ $packetSize$srm0 set tg_ $exp0$srm0 set app_fid_ 0;# attach application to SRM agent;# to generate repair packets of appropriate size;# pointer to traffic generator object;# fid value for packets generated by traffic generatorThe user can attach any traffic generator to an SRM agent. The SRM agent will add the SRM headers, set the destinationaddress to the multicast group, and deliver the packet to its target. The SRM header contains the type of the message, theidentity of the sender, the sequence number of the message, and (for control messages), the round for which this message isbeing sent. Each data unit in SRM is identified as 〈sender’s id, message sequence number〉.The SRM agent does not generate its own data; it does not also keep track of the data sent, except to record the sequencenumbers of messages received in the event that it has to do error recovery. Since the agent has no actual record of past data,it needs to know what packet size to use for each repair message. Hence, the instance variable packetSize_ specifies thesize of repair messages generated by the agent.Starting the Agent and Traffic GeneratorThe agent and the traffic generator must be started separately.$srm start$exp0 startAlternatively, the traffic generator can be started from the SRM Agent:$srm0 start-sourceAt start, the agent joins the multicast group, and starts generating session messages. The start-source triggers thetraffic generator to start sending data.1 Note that the trace data can also be used to gather certain kinds of trace data. We will illustrate this later.309

36.1.2 Other Configuration ParametersIn addition to the above parameters, the SRM agent supports additional configuration variables. Each of the variables describedin this section is both an OTcl class variable and an OTcl object’s instance variable. Changing the class variablechanges the default value for all agents that are created subsequently. Changing the instance variable of a particular agentonly affects the values used by that agent. For example,Agent/SRM set D1_ 2.0$srm set D1_ 2.0;# Changes the class variable;# Changes D1_ for the particular $srm object onlyThe default request and repair timer parameters [11] for each SRM agent are:Agent/SRM set C1_ 2.0 ;# request parametersAgent/SRM set C2_ 2.0Agent/SRM set D1_ 1.0 ;# repair parametersAgent/SRM set D2_ 1.0It is thus possible to trivially obtain two flavors of SRM agents based on whether the agents use probabilistic or deterministicsuppression by using the following definitions:Class Agent/SRM/Deterministic -superclass Agent/SRMAgent/SRM/Deterministic set C2_ 0.0Agent/SRM/Deterministic set D2_ 0.0Class Agent/SRM/Probabilistic -superclass Agent/SRMAgent/SRM/Probabilistic set C1_ 0.0Agent/SRM/Probabilistic set D1_ 0.0In a later section (Section 36.7), we will discuss other ways of extending the SRM agent.Timer related functions are handled by separate objects belonging to the class SRM. Timers are required for loss recovery andsending periodic session messages. There are loss recovery objects to send request and repair messages. The agent creates aseparate request or repair object to handle each loss. In contrast, the agent only creates one session object to send periodicsession messages. The default classes the express each of these functions are:Agent/SRM set requestFunction_Agent/SRM set repairFunction_Agent/SRM set sessionFunction_"SRM/request""SRM/repair""SRM/session"Agent/SRM set requestBackoffLimit_ 5 ;# parameter to requestFunction_Agent/SRM set sessionDelay_ 1.0 ;# parameter to sessionFunction_The instance procedures requestFunction{}, repairFunction{}, and sessionFunction{} can be used tochange the default function for individual agents. The last two lines are specific parameters used by the request and sessionobjects. The following section (Section 36.2) describes the implementation of theses objects in greater detail.310

36.1.2 Other Configur<strong>at</strong>ion ParametersIn addition to the above parameters, the SRM agent supports additional configur<strong>at</strong>ion variables. Each of the variables describedin this section is both an OTcl class variable <strong>and</strong> an OTcl object’s i<strong>ns</strong>tance variable. Changing the class variablechanges the default value for all agents th<strong>at</strong> are cre<strong>at</strong>ed subsequently. Changing the i<strong>ns</strong>tance variable of a particular agentonly affects the values used by th<strong>at</strong> agent. For example,Agent/SRM set D1_ 2.0$srm set D1_ 2.0;# Changes the class variable;# Changes D1_ for the particular $srm object only<strong>The</strong> default request <strong>and</strong> repair timer parameters [11] for each SRM agent are:Agent/SRM set C1_ 2.0 ;# request parametersAgent/SRM set C2_ 2.0Agent/SRM set D1_ 1.0 ;# repair parametersAgent/SRM set D2_ 1.0It is thus possible to trivially obtain two flavors of SRM agents based on whether the agents use probabilistic or deterministicsuppression by using the following definitio<strong>ns</strong>:Class Agent/SRM/Deterministic -superclass Agent/SRMAgent/SRM/Deterministic set C2_ 0.0Agent/SRM/Deterministic set D2_ 0.0Class Agent/SRM/Probabilistic -superclass Agent/SRMAgent/SRM/Probabilistic set C1_ 0.0Agent/SRM/Probabilistic set D1_ 0.0In a l<strong>at</strong>er section (Section 36.7), we will discuss other ways of extending the SRM agent.Timer rel<strong>at</strong>ed functio<strong>ns</strong> are h<strong>and</strong>led by separ<strong>at</strong>e objects belonging to the class SRM. Timers are required for loss recovery <strong>and</strong>sending periodic session messages. <strong>The</strong>re are loss recovery objects to send request <strong>and</strong> repair messages. <strong>The</strong> agent cre<strong>at</strong>es asepar<strong>at</strong>e request or repair object to h<strong>and</strong>le each loss. In contrast, the agent only cre<strong>at</strong>es one session object to send periodicsession messages. <strong>The</strong> default classes the express each of these functio<strong>ns</strong> are:Agent/SRM set requestFunction_Agent/SRM set repairFunction_Agent/SRM set sessionFunction_"SRM/request""SRM/repair""SRM/session"Agent/SRM set requestBackoffLimit_ 5 ;# parameter to requestFunction_Agent/SRM set sessionDelay_ 1.0 ;# parameter to sessionFunction_<strong>The</strong> i<strong>ns</strong>tance procedures requestFunction{}, repairFunction{}, <strong>and</strong> sessionFunction{} can be used tochange the default function for individual agents. <strong>The</strong> last two lines are specific parameters used by the request <strong>and</strong> sessionobjects. <strong>The</strong> following section (Section 36.2) describes the implement<strong>at</strong>ion of theses objects in gre<strong>at</strong>er detail.310

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!