diff --git a/.hgtags b/.hgtags index d0737c2e5..101349fe4 100644 --- a/.hgtags +++ b/.hgtags @@ -42,3 +42,4 @@ c975274c9707b1f07d94cc51f205c351122131a5 ns-3.5 39a82d7a0d661febe42e75f26ada79424258e330 ns-3.6-RC4 d55c479666ac6be0575fac695ddf355c0530e0dd ns-3.6 892efc87a1518fb69b04628c779195aee139d33e ns-3.7-RC3 +17bf6ee332baaa6b6f9b8a26d29c98f4e715648f ns-3.7-RC4 diff --git a/bindings/python/ns3modulegen.py b/bindings/python/ns3modulegen.py index 6bbe41af7..3ab762be6 100755 --- a/bindings/python/ns3modulegen.py +++ b/bindings/python/ns3modulegen.py @@ -138,7 +138,8 @@ def main(): 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 >']: root_module.classes.remove(root_module['ns3::%s' % clsname]) if 'EmuNetDevice' not in enabled_features: diff --git a/doc/manual/animation.texi b/doc/manual/animation.texi index 7ffc82e3c..9b3349010 100644 --- a/doc/manual/animation.texi +++ b/doc/manual/animation.texi @@ -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 diff --git a/doc/manual/flow-monitor.texi b/doc/manual/flow-monitor.texi index b27c4a327..65825e1d3 100644 --- a/doc/manual/flow-monitor.texi +++ b/doc/manual/flow-monitor.texi @@ -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} diff --git a/doc/manual/routing.texi b/doc/manual/routing.texi index 8b03f1f7f..0888af350 100644 --- a/doc/manual/routing.texi +++ b/doc/manual/routing.texi @@ -270,22 +270,49 @@ and no further routing protocols will be searched. @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); // 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 diff --git a/src/common/error-model.h b/src/common/error-model.h index 69b04a9fa..6f8df9e03 100644 --- a/src/common/error-model.h +++ b/src/common/error-model.h @@ -45,7 +45,8 @@ class Packet; * 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 @@ public: 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 */ diff --git a/src/routing/olsr/olsr.h b/src/routing/olsr/olsr.h index 67cb988cc..39fb0d6af 100644 --- a/src/routing/olsr/olsr.h +++ b/src/routing/olsr/olsr.h @@ -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 + * + * */ diff --git a/src/simulator/simulator.h b/src/simulator/simulator.h index cb7e825f4..2873b0fb8 100644 --- a/src/simulator/simulator.h +++ b/src/simulator/simulator.h @@ -75,7 +75,7 @@ public: static Ptr 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