[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The goal of the attribute system is to organize the access of internal member objects of a simulation. This goal arises because, typically in simulation, users will cut and paste/modify existing simulation scripts, or will use higher-level simulation constructs, but often will be interested in studying or tracing particular internal variables. For instance, use cases such as:
Similarly, users may want fine-grained access to internal variables in the simulation, or may want to broadly change the initial value used for a particular parameter in all subsequently created objects. Finally, users may wish to know what variables are settable and retrievable in a simulation configuration. This is not just for direct simulation interaction on the command line; consider also a (future) graphical user interface that would like to be able to provide a feature whereby a user might right-click on an node on the canvas and see a hierarchical, organized list of parameters that are settable on the node and its constituent member objects, and help text and default values for each parameter.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
We provide a way for users to access values deep in the system, without
having to plumb accessors (pointers) through the system and walk
pointer chains to get to them. Consider a class DropTailQueue that
has a member variable that is an unsigned integer m_maxPackets
;
this member variable controls the depth of the queue.
If we look at the declaration of DropTailQueue, we see the following:
class DropTailQueue : public Queue { public: static TypeId GetTypeId (void); ... private: std::queue<Ptr<Packet> > m_packets; uint32_t m_maxPackets; };
Let's consider things that a user may want to do with the value of m_maxPackets:
The above things typically require providing Set() and Get() functions, and some type of global default value.
In the ns-3 attribute system, these value definitions and accessor functions are moved into the TypeId class; e.g.:
NS_OBJECT_ENSURE_REGISTERED (DropTailQueue); TypeId DropTailQueue::GetTypeId (void) { static TypeId tid = TypeId ("ns3::DropTailQueue") .SetParent<Queue> () .AddConstructor<DropTailQueue> () .AddAttribute ("MaxPackets", "The maximum number of packets accepted by this DropTailQueue.", UintegerValue (100), MakeUintegerAccessor (&DropTailQueue::m_maxPackets), MakeUintegerChecker<uint32_t> ()) ; return tid; }
The AddAttribute() method is performing a number of things with this value:
The key point is that now the value of this variable and its default value are accessible in the attribute namespace, which is based on strings such as "MaxPackets" and TypeId strings. In the next section, we will provide an example script that shows how users may manipulate these values.
Note that initialization of the attribute relies on the macro NS_OBJECT_ENSURE_REGISTERED (DropTailQueue) being called; if you leave this out of your new class implementation, your attributes will not be initialized corretly.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Let's look at how a user script might access these values.
This is based on the script found at samples/main-attribute-value.cc
,
with some details stripped out.
// // This is a basic example of how to use the attribute system to // set and get a value in the underlying system; namely, an unsigned // integer of the maximum number of packets in a queue // int main (int argc, char *argv[]) { // By default, the MaxPackets attribute has a value of 100 packets // (this default can be observed in the function DropTailQueue::GetTypeId) // // Here, we set it to 80 packets. We could use one of two value types: // a string-based value or a Uinteger value Config::SetDefault ("ns3::DropTailQueue::MaxPackets", StringValue ("80")); // The below function call is redundant Config::SetDefault ("ns3::DropTailQueue::MaxPackets", UintegerValue (80)); // Allow the user to override any of the defaults and the above // SetDefaults() at run-time, via command-line arguments CommandLine cmd; cmd.Parse (argc, argv);
The main thing to notice in the above are the two calls to
Config::SetDefault
. This is how we set the default value
for all subsequently instantiated DropTailQueues. We illustrate
that two types of Value classes, a StringValue and a UintegerValue class,
can be used to assign the value to the attribute named by
"ns3::DropTailQueue::MaxPackets".
Now, we will create a few objects using the low-level API; here, our newly created queues will not have a m_maxPackets initialized to 100 packets but to 80 packets, because of what we did above with default values.
Ptr<Node> n0 = CreateObject<Node> (); Ptr<PointToPointNetDevice> net0 = CreateObject<PointToPointNetDevice> (); n0->AddDevice (net0); Ptr<Queue> q = CreateObject<DropTailQueue> (); net0->AddQueue(q);
At this point, we have created a single node (Node 0) and a single PointToPointNetDevice (NetDevice 0) and added a DropTailQueue to it.
Now, we can manipulate the MaxPackets value of the already instantiated DropTailQueue. Here are various ways to do that.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
We assume that a smart pointer (Ptr) to a relevant network device is in hand; here, it is the net0 pointer.
One way to change the value is to access a pointer to the underlying queue and modify its attribute.
First, we observe that we can get a pointer to the (base class) queue via the PointToPointNetDevice attributes, where it is called TxQueue
PointerValue tmp; net0->GetAttribute ("TxQueue", tmp); Ptr<Object> txQueue = tmp.GetObject ();
Using the GetObject function, we can perform a safe downcast to a DropTailQueue, where MaxPackets is a member
Ptr<DropTailQueue> dtq = txQueue->GetObject <DropTailQueue> (); NS_ASSERT (dtq != 0);
Next, we can get the value of an attribute on this queue. We have introduced wrapper "Value" classes for the underlying data types, similar to Java wrappers around these types, since the attribute system stores values and not disparate types. Here, the attribute value is assigned to a UintegerValue, and the Get() method on this value produces the (unwrapped) uint32_t.
UintegerValue limit; dtq->GetAttribute ("MaxPackets", limit); NS_LOG_INFO ("1. dtq limit: " << limit.Get () << " packets");
Note that the above downcast is not really needed; we could have done the same using the Ptr<Queue> even though the attribute is a member of the subclass
txQueue->GetAttribute ("MaxPackets", limit); NS_LOG_INFO ("2. txQueue limit: " << limit.Get () << " packets");
Now, let's set it to another value (60 packets)
txQueue->SetAttribute("MaxPackets", UintegerValue (60)); txQueue->GetAttribute ("MaxPackets", limit); NS_LOG_INFO ("3. txQueue limit changed: " << limit.Get () << " packets");
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
An alternative way to get at the attribute is to use the configuration namespace. Here, this attribute resides on a known path in this namespace; this approach is useful if one doesn't have access to the underlying pointers and would like to configure a specific attribute with a single statement.
Config::Set ("/NodeList/0/DeviceList/0/TxQueue/MaxPackets", UintegerValue (25)); txQueue->GetAttribute ("MaxPackets", limit); NS_LOG_INFO ("4. txQueue limit changed through namespace: " << limit.Get () << " packets");
We could have also used wildcards to set this value for all nodes and all net devices (which in this simple example has the same effect as the previous Set())
Config::Set ("/NodeList/*/DeviceList/*/TxQueue/MaxPackets", UintegerValue (15)); txQueue->GetAttribute ("MaxPackets", limit); NS_LOG_INFO ("5. txQueue limit changed through wildcarded namespace: " << limit.Get () << " packets");
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Another way to get at the attribute is to use the object name service facility. Here, this attribute is found using a name string. This approach is useful if one doesn't have access to the underlying pointers and it is difficult to determine the required concrete configuration namespaced path.
Names::Add ("server", serverNode); Names::Add ("server/eth0", serverDevice); ... Config::Set ("/Names/server/eth0/TxQueue/MaxPackets", UintegerValue (25));
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Arbitrary combinations of attributes can be set and fetched from the helper and low-level APIs; either from the constructors themselves:
Ptr<Object> p = CreateObject<MyNewObject> ("n1", v1, "n2", v2, ...);
or from the higher-level helper APIs, such as:
mobility.SetPositionAllocator ("GridPositionAllocator", "MinX", DoubleValue (-100.0), "MinY", DoubleValue (-100.0), "DeltaX", DoubleValue (5.0), "DeltaY", DoubleValue (20.0), "GridWidth", UintegerValue (20), "LayoutType", StringValue ("RowFirst"));
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Readers will note the new FooValue classes which are subclasses of the AttributeValue base class. These can be thought of as an intermediate class that can be used to convert from raw types to the Values that are used by the attribute system. Recall that this database is holding objects of many types with a single generic type. Conversions to this type can either be done using an intermediate class (IntegerValue, DoubleValue for "floating point") or via strings. Direct implicit conversion of types to Value is not really practical. So in the above, users have a choice of using strings or values:
p->Set ("cwnd", StringValue ("100")); // string-based setter p->Set ("cwnd", IntegerValue (100)); // integer-based setter
The system provides some macros that help users declare and define new AttributeValue subclasses for new types that they want to introduce into the attribute system:
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] |
This document was generated on July, 4 2009 using texi2html 1.78.