--- a/.hgtags Mon Jan 25 14:25:08 2010 -0800
+++ b/.hgtags Mon Jan 25 14:25:18 2010 -0800
@@ -42,3 +42,4 @@
39a82d7a0d661febe42e75f26ada79424258e330 ns-3.6-RC4
d55c479666ac6be0575fac695ddf355c0530e0dd ns-3.6
892efc87a1518fb69b04628c779195aee139d33e ns-3.7-RC3
+17bf6ee332baaa6b6f9b8a26d29c98f4e715648f ns-3.7-RC4
--- a/bindings/python/ns3modulegen.py Mon Jan 25 14:25:08 2010 -0800
+++ b/bindings/python/ns3modulegen.py Mon Jan 25 14:25:18 2010 -0800
@@ -138,7 +138,8 @@
pass
if 'Threading' not in enabled_features:
- for clsname in ['SystemThread', 'SystemMutex', 'SystemCondition', 'CriticalSection', 'SimpleRefCount< ns3::SystemThread, ns3::empty >']:
+ for clsname in ['SystemThread', 'SystemMutex', 'SystemCondition', 'CriticalSection',
+ 'SimpleRefCount< ns3::SystemThread, ns3::empty, ns3::DefaultDeleter<ns3::SystemThread> >']:
root_module.classes.remove(root_module['ns3::%s' % clsname])
if 'EmuNetDevice' not in enabled_features:
--- a/doc/manual/animation.texi Mon Jan 25 14:25:08 2010 -0800
+++ b/doc/manual/animation.texi Mon Jan 25 14:25:18 2010 -0800
@@ -8,23 +8,22 @@
@end menu
Animation is an important tool for network simulation. While ns-3 does
-not contain a graphical animation tool, it does provide an animation interface
-for use with stand-alone animators. Currently, the animation
-interface only supports point-to-point links; however, we hope
-to support other link types such as CSMA and wireless in the near future.
-The animation interface in ns-3 allows the generation of a custom trace
-file to be used by an animation program.
-
-An existing stand-alone program, NetAnim, uses these custom traces to
-graphically display the simulation. NetAnim depicts packets traveling
-on point-to-point links as they travel from node to node.
+not contain a default graphical animation tool, it does provide an
+animation interface for use with stand-alone animators. One such
+animator called NetAnim, presently supporting packet flow animation
+for point-to-point links, has been developed. Other animators and
+visualization tools are in development; they may make use of the
+existing animation interface or may develop new ones,
@node Animation interface
@section Animation interface
+The animation interface uses underlying ns-3 trace sources to construct
+a timestamped ASCII file that can be read by a standalone animator.
The animation interface in ns-3 currently only supports point-to-point
-links and can generate a custom trace file for use by an animation
-program. A snippet from a sample trace file is shown below.
+links; however, we hope
+to support other link types such as CSMA and wireless in the near future.
+A snippet from a sample trace file is shown below.
@verbatim
0.0 N 0 4 5.5
--- a/doc/manual/flow-monitor.texi Mon Jan 25 14:25:08 2010 -0800
+++ b/doc/manual/flow-monitor.texi Mon Jan 25 14:25:18 2010 -0800
@@ -5,6 +5,7 @@
Placeholder chapter
@end cartouche
-This feature was added as contributed code (@code{src/contrib}) in ns-3.6.
+This feature was added as contributed code (@code{src/contrib}) in ns-3.6 and
+to the main distribution for ns-3.7.
A paper on this feature is published in the proceedings of NSTools: @*
@uref{http://www.nstools.org/techprog.shtml,,http://www.nstools.org/techprog.shtml}
--- a/doc/manual/routing.texi Mon Jan 25 14:25:08 2010 -0800
+++ b/doc/manual/routing.texi Mon Jan 25 14:25:18 2010 -0800
@@ -270,22 +270,49 @@
@subsection Optimized Link State Routing (OLSR)
-This is the first dynamic routing protocol for @command{ns-3}. The implementation
+This IPv4 routing protocol was originally ported from the OLSR-UM
+implementation for ns-2. The implementation
is found in the src/routing/olsr directory, and an example script is in
examples/simple-point-to-point-olsr.cc.
-The following commands will enable OLSR in a simulation.
+Typically, OLSR is enabled in a main program by use of an OlsrHelper class
+that installs OLSR into an Ipv4ListRoutingProtocol object.
+The following sample commands will enable OLSR in a simulation using
+this helper class along with some other routing helper objects.
+The setting of priority value 10, ahead of
+the staticRouting priority of 0, means that OLSR will be consulted for
+a route before the node's static routing table.
@verbatim
- olsr::EnableAllNodes (); // Start OLSR on all nodes
- olsr::EnableNodes(InputIterator begin, InputIterator end); // Start on
- // a list of nodes
- olsr::EnableNode (Ptr<Node> node); // Start OLSR on "node" only
+ NodeContainer c:
+ ...
+ // Enable OLSR
+ NS_LOG_INFO ("Enabling OLSR Routing.");
+ OlsrHelper olsr;
+
+ Ipv4StaticRoutingHelper staticRouting;
+
+ Ipv4ListRoutingHelper list;
+ list.Add (staticRouting, 0);
+ list.Add (olsr, 10);
+
+ InternetStackHelper internet;
+ internet.SetRoutingHelper (list);
+ internet.Install (c);
@end verbatim
-Once instantiated, the agent can be started with the Start() command,
-and the OLSR "main interface" can be set with the SetMainInterface()
-command. A number of protocol constants are defined in olsr-agent-impl.cc.
+Once installed,the OLSR "main interface" can be set with the
+SetMainInterface() command. If the user does not specify a main address,
+the protocol will select the first primary IP address that it finds, starting
+first the loopback interface and then the next non-loopback interface
+found, in order of Ipv4 interface index. The loopback address of 127.0.0.1
+is not selected. In addition, a number of protocol constants are defined in
+olsr-routing-protocol.cc.
+
+Olsr is started at time zero of the simulation, based on a call to
+Object::Start() that eventually calls OlsrRoutingProtocol::DoStart().
+Note: a patch to allow the user to start and stop the protocol at other
+times would be welcome.
Presently, OLSR is limited to use with an Ipv4ListRouting object, and
does not respond to dynamic changes to a device's IP address or link up/down
--- a/src/common/error-model.h Mon Jan 25 14:25:08 2010 -0800
+++ b/src/common/error-model.h Mon Jan 25 14:25:18 2010 -0800
@@ -45,7 +45,8 @@
* the packet is to be corrupted according to the underlying model.
* Depending on the error model, the packet itself may have its packet
* data buffer errored or not, or side information may be returned to
- * the client in the form of a packet tag.
+ * the client in the form of a packet tag. (Note: No such error models
+ * that actually error the bits in a packet presently exist).
* The object can have state (resettable by Reset()).
* The object can also be enabled and disabled via two public member functions.
*
@@ -77,6 +78,9 @@
virtual ~ErrorModel ();
/**
+ * Note: Depending on the error model, this function may or may not
+ * alter the contents of the packet upon returning true.
+ *
* \returns true if the Packet is to be considered as errored/corrupted
* \param pkt Packet to apply error model to
*/
--- a/src/routing/olsr/olsr.h Mon Jan 25 14:25:08 2010 -0800
+++ b/src/routing/olsr/olsr.h Mon Jan 25 14:25:18 2010 -0800
@@ -36,8 +36,6 @@
* Here is a summary of software's main features:
* - Mostly compliant with OLSR as documented in RFC 3626 (http://www.ietf.org/rfc/rfc3626.txt), with the following differences:
* - The use of multiple interfaces was not supported by the NS-2 version, but is supported in NS-3;
- * - Unlike the NS-2 version, does not yet support MAC layer feedback as described in RFC 3626;
- * - HNA (Host/Network Association) messages are almost-but-not-quite supported in this version.
*
* \section api API and Usage
*
@@ -53,6 +51,21 @@
* to set OLSR attributes. These include HelloInterval, TcInterval,
* MidInterval, Willingness. Other parameters are defined as macros
* in olsr-routing-protocol.cc.
+ *
+ * \section list Open Issues
+ *
+ * - OLSR does not repond to the routing event notifications correspondingg
+ * to dynamic interface up and down (RoutingProtocol::NotifyInterfaceUp and
+ * RoutingProtocol::NotifyInterfaceDown) or address insertion/removal
+ * (RoutingProtocol::NotifyAddAddress and
+ * RoutingProtocol::NotifyRemoveAddress).
+ * - HNA (Host/Network Association) messages are almost-but-not-quite supported in this version.
+ * - Unlike the NS-2 version, does not yet support MAC layer feedback as described in RFC 3626;
+ * - If a user binds a socket to a particular output device, OLSR will not
+ * consider that constraint in its route selection for locally originated
+ * packets
+ *
+ *
*/
--- a/src/simulator/simulator.h Mon Jan 25 14:25:08 2010 -0800
+++ b/src/simulator/simulator.h Mon Jan 25 14:25:18 2010 -0800
@@ -75,7 +75,7 @@
static Ptr<SimulatorImpl> GetImplementation (void);
/**
- * \param scheduler a new event scheduler
+ * \param schedulerFactory a new event scheduler factory
*
* The event scheduler can be set at any time: the events scheduled
* in the previous scheduler will be transfered to the new scheduler