Difference between revisions of "HOWTO determine the path of an attribute or trace source"
(Added hint on logging Config-related messages) |
Nicolabaldo (Talk | contribs) |
||
Line 12: | Line 12: | ||
aggregated to the device. | aggregated to the device. | ||
+ | ==Objects of a specific type== | ||
+ | $-prefixed items in a path are also used to do a ''type cast'' to an object of a particular type. | ||
+ | |||
+ | For example: | ||
+ | <pre>/NodeList/*/DeviceList/*/$ns3::WifiNetDevice</pre> | ||
+ | will match only with devices of type WifiNetDevice. | ||
+ | |||
+ | Conversely, the following: | ||
+ | <pre>/NodeList/*/DeviceList/*</pre> | ||
+ | will match with any device, regardless of the type. | ||
==Objects referenced by attributes of other Objects== | ==Objects referenced by attributes of other Objects== |
Latest revision as of 14:12, 30 June 2011
Contents
Aggregated Objects
$-prefixed items in a path are used to perform an aggregation lookup using the TypeId of the Object you are looking for. Since almost all TypeIds have a ns3:: prefix, you will usually see the compound prefix $ns3::
Example:
/NodeList/*/$ns3::TcpL4Protocol
the above path works because ns3::TcpL4Protocol instances are aggregated to the node in which they exist. On the other hand see this one:
/NodeList/0/DeviceList/0/$ns3::WifiRemoteStationManager
the above path is getting device 0 in node 0, and, then, doing GetObject<WifiRemoteStationManager> on it but it gets null because the remote station manager is not aggregated to the device.
Objects of a specific type
$-prefixed items in a path are also used to do a type cast to an object of a particular type.
For example:
/NodeList/*/DeviceList/*/$ns3::WifiNetDevice
will match only with devices of type WifiNetDevice.
Conversely, the following:
/NodeList/*/DeviceList/*
will match with any device, regardless of the type.
Objects referenced by attributes of other Objects
2) non-$ prefixed non-terminating items in a path are used to perform an attribute lookup on an attribute of type Pointer. This is often used as an alternative to object aggregation.
As an example, when using a wifi device:
/NodeList/0/DeviceList/0/RemoteStationManager/MacTxDataFailed
the above path works, because devices with TypeId ns3::WifiNetDevice have a RemoteStationManager attribute which is of type Ptr<WifiRemoteStationManager>. On the other hand, see this one:
/NodeList/0/TcpL4Protocolthe above path doesn't work,
/NodeList/0gets you to a Node Object, and there is no Attribute named TcpL4Protocol. All this in spite of the fact that TcpL4Protocol is aggregated with Node -- remember that for querying aggregated objects you need the $ prefix.
Hints
- A nice way to figure out a path is to use the ConfigStore: if you use it to dump all attributes in a text file, you can see a valid path for each attribute (this, arguably, does not work for trace sources).
- Also, note that there is a 'Config' LogComponent: just activate it by stating
LogComponentEnable ("Config", LOG_LEVEL_ALL);
somewhere in your simulation script.