branch merge ns-3.6-RC4
authorCraig Dowell <craigdo@ee.washington.edu>
Mon, 19 Oct 2009 18:47:30 -0700
changeset 543639a82d7a0d66
parent 5435 5f1b13dda227
parent 5434 81a3858041a8
child 5437 90e842e24fc9
branch merge
     1.1 --- a/doc/manual/Makefile	Mon Oct 19 18:47:01 2009 -0700
     1.2 +++ b/doc/manual/Makefile	Mon Oct 19 18:47:30 2009 -0700
     1.3 @@ -72,6 +72,8 @@
     1.4  version:
     1.5  	echo -n "ns-" > VERSION-PREFIX; cat VERSION-PREFIX ../../VERSION > VERSION; rm -rf VERSION-PREFIX
     1.6  
     1.7 -clean: 	figures-clean
     1.8 +texi-clean: 	
     1.9  	rm -rf manual.aux manual.cp manual.cps manual.fn manual.ky manual.pg manual.tp
    1.10  	rm -rf manual.vr manual.toc manual.log manual.pdf manual.html manual/ VERSION 
    1.11 +
    1.12 +clean:	figures-clean texi-clean
     2.1 --- a/doc/manual/animation.texi	Mon Oct 19 18:47:01 2009 -0700
     2.2 +++ b/doc/manual/animation.texi	Mon Oct 19 18:47:30 2009 -0700
     2.3 @@ -4,3 +4,10 @@
     2.4  @cartouche
     2.5  Placeholder chapter
     2.6  @end cartouche
     2.7 +
     2.8 +This wiki page: @*
     2.9 +@uref{http://www.nsnam.org/wiki/index.php/NetAnim,,http://www.nsnam.org/wiki/index.php/NetAnim}
    2.10 +contains information about the animator support that has been added to ns-3.6.
    2.11 +
    2.12 +Another Python-based animator is available (ns-3-pyviz) but is not
    2.13 +documented.
     3.1 --- a/doc/manual/bridge.texi	Mon Oct 19 18:47:01 2009 -0700
     3.2 +++ b/doc/manual/bridge.texi	Mon Oct 19 18:47:30 2009 -0700
     3.3 @@ -4,3 +4,6 @@
     3.4  @cartouche
     3.5  Placeholder chapter
     3.6  @end cartouche
     3.7 +
     3.8 +Some examples of the use of Bridge NetDevice can be found in
     3.9 +@code{examples/csma/} directory. 
     4.1 --- a/doc/manual/emu.texi	Mon Oct 19 18:47:01 2009 -0700
     4.2 +++ b/doc/manual/emu.texi	Mon Oct 19 18:47:30 2009 -0700
     4.3 @@ -9,14 +9,7 @@
     4.4  We perform MAC spoofing to separate simulation network traffic from other 
     4.5  network traffic that may be flowing to and from the host.
     4.6  
     4.7 -Normally, the use case for emulated net devices is in collections of small 
     4.8 -simulations that connect to the outside world through specific interfaces.
     4.9 -For example, one could construct a number of virtual machines and connect them
    4.10 -via a host-only network.  To use the emulated net device, you would need to 
    4.11 -set all of the host-only interfaces in promiscuous mode and provide an 
    4.12 -appropriate device name, "eth1" for example.
    4.13 -
    4.14 -One could also use the @code{Emu} net device in a testbed situation where the 
    4.15 +One can use the @code{Emu} net device in a testbed situation where the 
    4.16  host on which the simulation is running has a specific interface of interest 
    4.17  which  drives the testbed hardware.  You would also need to set this specific 
    4.18  interface into promiscuous mode and provide an appropriate device name to the 
    4.19 @@ -48,7 +41,7 @@
    4.20  One unique aspect is that there is no channel associated with the underlying
    4.21  medium.  We really have no idea what this external medium is, and so have not
    4.22  made an effort to model it abstractly.  The primary thing to be aware of is the 
    4.23 -implication this has for static global routing.  The global router module
    4.24 +implication this has for IPv4 global routing.  The global router module
    4.25  attempts to walk the channels looking for adjacent networks.  Since there 
    4.26  is no channel, the global router will be unable to do this and you must then 
    4.27  use a dynamic routing protocol such as OLSR to include routing in 
    4.28 @@ -71,8 +64,10 @@
    4.29  that describe how to set up a virtual test network using VMware and how to run
    4.30  a set of example (client server) simulations that use @code{Emu} net devices.
    4.31  
    4.32 -@uref{http://www.nsnam.org/wiki/index.php/HOWTO_use_VMware_to_set_up_virtual_networks_(Windows)}
    4.33 -@uref{http://www.nsnam.org/wiki/index.php/HOWTO_use_ns-3_scripts_to_drive_real_hardware_(experimental)} 
    4.34 +@itemize @bullet
    4.35 +@item @uref{http://www.nsnam.org/wiki/index.php/HOWTO_use_VMware_to_set_up_virtual_networks_(Windows)}
    4.36 +@item @uref{http://www.nsnam.org/wiki/index.php/HOWTO_use_ns-3_scripts_to_drive_real_hardware_(experimental)} 
    4.37 +@end itemize
    4.38  
    4.39  Once you are over the configuration hurdle, the script changes required to use 
    4.40  an @code{Emu} device are trivial.  The main structural difference is that you
    4.41 @@ -102,7 +97,7 @@
    4.42    // We've got the devices in place.  Since we're using MAC address 
    4.43    // spoofing under the sheets, we need to make sure that the MAC addresses
    4.44    // we have assigned to our devices are unique.  Ns-3 will happily
    4.45 -  // automatically assign the same MAC addresses to the devices in both halves
    4.46 +  // automatically assign the same MAC address to the devices in both halves
    4.47    // of our two-script pair, so let's go ahead and just manually change them
    4.48    // to something we ensure is unique.
    4.49    //
     5.1 --- a/doc/manual/flow-monitor.texi	Mon Oct 19 18:47:01 2009 -0700
     5.2 +++ b/doc/manual/flow-monitor.texi	Mon Oct 19 18:47:30 2009 -0700
     5.3 @@ -4,3 +4,7 @@
     5.4  @cartouche
     5.5  Placeholder chapter
     5.6  @end cartouche
     5.7 +
     5.8 +This feature was added as contributed code (@code{src/contrib}) in ns-3.6.
     5.9 +A paper on this feature is published in the proceedings of NSTools: @*
    5.10 +@uref{http://www.nstools.org/techprog.shtml,,http://www.nstools.org/techprog.shtml}
     6.1 --- a/doc/manual/internet.texi	Mon Oct 19 18:47:01 2009 -0700
     6.2 +++ b/doc/manual/internet.texi	Mon Oct 19 18:47:30 2009 -0700
     6.3 @@ -3,19 +3,20 @@
     6.4  
     6.5  @section Internet stack aggregation
     6.6  
     6.7 -The above @code{class Node} is not very useful as-is; other objects
     6.8 +A bare @code{class Node} is not very useful as-is; other objects
     6.9  must be aggregated to it to provide useful node functionality.
    6.10  
    6.11  The ns-3 source code directory @code{src/internet-stack} provides
    6.12 -implementation of TCP/IPv4-related components.  These include IPv4,
    6.13 -ARP, UDP, TCP, and other related protocols.
    6.14 +implementation of TCP/IPv4- and IPv6-related components.  These include IPv4,
    6.15 +ARP, UDP, TCP, IPv6, Neighbor Discovery, and other related protocols.
    6.16  
    6.17  Internet Nodes are not subclasses of class Node; they are simply Nodes 
    6.18  that have had a bunch of IPv4-related
    6.19  objects aggregated to them.  They can be put together by hand, or
    6.20  via a helper function @code{InternetStackHelper::Install ()} which does the 
    6.21  following to all nodes passed in as arguments:
    6.22 -@verbatim
    6.23 +@smallformat
    6.24 +@example
    6.25  void
    6.26  InternetStackHelper::Install (Ptr<Node> node) const
    6.27  {
    6.28 @@ -38,9 +39,14 @@
    6.29    Ptr<Ipv4RoutingProtocol> ipv4Routing = m_routing->Create (node);
    6.30    ipv4->SetRoutingProtocol (ipv4Routing);
    6.31  }
    6.32 -@end verbatim
    6.33 +@end example
    6.34 +@end smallformat
    6.35  
    6.36 -Note that the Ipv4 routing protocol is configured and set outside this
    6.37 +Where multiple implementations exist in ns-3 (TCP, IP routing), these
    6.38 +objects are added by a factory object (TCP) or by a routing helper
    6.39 +(m_routing).
    6.40 +
    6.41 +Note that the routing protocol is configured and set outside this
    6.42  function.  By default, the following protocols are added to Ipv4:
    6.43  @verbatim
    6.44  InternetStackHelper::InternetStackHelper ()
    6.45 @@ -55,6 +61,8 @@
    6.46  }
    6.47  @end verbatim
    6.48  
    6.49 +By default, IPv4 and IPv6 are enabled.
    6.50 +
    6.51  @subsection Internet Node structure
    6.52  
    6.53  An IPv4-capable Node (an ns-3 Node augmented by aggregation to have one or more
    6.54 @@ -70,7 +78,8 @@
    6.55  src/internet-stack directory at present.
    6.56  
    6.57  In class Ipv4L3Protocol, one method described below is @code{Receive ()}:
    6.58 -@verbatim
    6.59 +@smallformat
    6.60 +@example
    6.61   /**
    6.62     * Lower layer calls this method after calling L3Demux::Lookup
    6.63     * The ARP subclass needs to know from which NetDevice this
    6.64 @@ -78,9 +87,10 @@
    6.65     *    - implement a per-NetDevice ARP cache
    6.66     *    - send back arp replies on the right device
    6.67     */
    6.68 -  void Receive( Ptr<NetDevice> device, Ptr<const Packet> p, uint16_t protocol, const Address &from,
    6.69 -                const Address &to, NetDevice::PacketType packetType);
    6.70 -@end verbatim
    6.71 +  void Receive( Ptr<NetDevice> device, Ptr<const Packet> p, uint16_t protocol, 
    6.72 +const Address &from, const Address &to, NetDevice::PacketType packetType);
    6.73 +@end example
    6.74 +@end smallformat
    6.75  
    6.76  First, note that the @code{Receive ()} function has a matching signature
    6.77  to the ReceiveCallback in the @code{class Node}.  This function pointer
    6.78 @@ -111,10 +121,12 @@
    6.79  Once IPv4 routing has determined that a packet is for the local node, it 
    6.80  forwards it up the stack.  This is done with the following function:
    6.81  
    6.82 -@verbatim
    6.83 +@smallformat
    6.84 +@example
    6.85  void
    6.86  Ipv4L3Protocol::LocalDeliver (Ptr<const Packet> packet, Ipv4Header const&ip, uint32_t iif)
    6.87 -@end verbatim
    6.88 +@end example
    6.89 +@end smallformat
    6.90  
    6.91  The first step is to find the right Ipv4L4Protocol object , based on IP protocol
    6.92  number.  For instance, TCP is registered in the demux as protocol number 6.
    6.93 @@ -127,6 +139,8 @@
    6.94  the @code{struct in_device}; the main purpose is to provide 
    6.95  address-family specific information (addresses) about an interface.
    6.96  
    6.97 +The IPv6 implementation follows a similar architecture.
    6.98 +
    6.99  @subsubsection Layer-4 protocols and sockets
   6.100  
   6.101  We next describe how the transport protocols, sockets, and applications
     7.1 --- a/doc/manual/ipv6.texi	Mon Oct 19 18:47:01 2009 -0700
     7.2 +++ b/doc/manual/ipv6.texi	Mon Oct 19 18:47:30 2009 -0700
     7.3 @@ -4,3 +4,7 @@
     7.4  @cartouche
     7.5  Placeholder chapter
     7.6  @end cartouche
     7.7 +IPv6 models are being added to ns-3.  A paper on the IPv6 models was
     7.8 +published in WNS2 2008: @*
     7.9 +@uref{http://lsiit.u-strasbg.fr/Publications/2008/VMM08/,,http://lsiit.u-strasbg.fr/Publications/2008/VMM08/}
    7.10 +
     8.1 --- a/doc/manual/manual.texi	Mon Oct 19 18:47:01 2009 -0700
     8.2 +++ b/doc/manual/manual.texi	Mon Oct 19 18:47:30 2009 -0700
     8.3 @@ -158,9 +158,9 @@
     8.4  @unnumbered Part 3:  Emulation
     8.5  @setchapternewpage off
     8.6  @include emulation.texi
     8.7 +@setchapternewpage odd
     8.8  @include emu.texi
     8.9  @include tap.texi
    8.10 -@setchapternewpage odd
    8.11  
    8.12  @unnumbered Part 4:  Internet Models
    8.13  @setchapternewpage off
     9.1 --- a/doc/manual/mesh.texi	Mon Oct 19 18:47:01 2009 -0700
     9.2 +++ b/doc/manual/mesh.texi	Mon Oct 19 18:47:30 2009 -0700
     9.3 @@ -4,3 +4,8 @@
     9.4  @cartouche
     9.5  Placeholder chapter
     9.6  @end cartouche
     9.7 +
     9.8 +The Mesh NetDevice based on 802.11s was added in ns-3.6.  
     9.9 +An overview presentation by Kirill Andreev was published at the wns-3 workshop
    9.10 +in 2009: @*
    9.11 +@uref{http://www.nsnam.org/wiki/index.php/Wns3-2009,,http://www.nsnam.org/wiki/index.php/Wns3-2009}
    10.1 --- a/doc/manual/new-models.texi	Mon Oct 19 18:47:01 2009 -0700
    10.2 +++ b/doc/manual/new-models.texi	Mon Oct 19 18:47:30 2009 -0700
    10.3 @@ -395,8 +395,10 @@
    10.4  @subsection how to include files from elsewhere
    10.5  @subsection log component 
    10.6  
    10.7 -Here, write a bit about adding ns-3 logging macros.  Note that
    10.8 +@cartouche
    10.9 +Here, write a bit about adding ns-3 logging macros.  Note that @* 
   10.10  LOG_COMPONENT_DEFINE is done outside the namespace ns3
   10.11 +@end cartouche
   10.12  
   10.13  @subsection constructor, empty function prototypes
   10.14  
   10.15 @@ -407,7 +409,8 @@
   10.16  
   10.17  
   10.18  @subsection Object Framework
   10.19 -@verbatim
   10.20 +@smallformat
   10.21 +@example
   10.22    static const ClassId cid;
   10.23  
   10.24  
   10.25 @@ -416,8 +419,8 @@
   10.26  
   10.27  const ClassId ErrorModel::cid =
   10.28    MakeClassId<ErrorModel> ("ErrorModel", ErrorModel::iid);
   10.29 -@end verbatim
   10.30 -
   10.31 +@end example
   10.32 +@end smallformat
   10.33  
   10.34  @node Adding-a-sample-script
   10.35  @section Adding a sample script
   10.36 @@ -431,7 +434,8 @@
   10.37  
   10.38  @subsection Add basic support in the class
   10.39  
   10.40 -@verbatim
   10.41 +@smallformat
   10.42 +@example
   10.43  point-to-point-net-device.h
   10.44    class ErrorModel;
   10.45    
   10.46 @@ -440,12 +444,13 @@
   10.47     */
   10.48    Ptr<ErrorModel> m_receiveErrorModel;
   10.49    
   10.50 -@end verbatim
   10.51 +@end example
   10.52 +@end smallformat
   10.53  
   10.54  @subsection Add Accessor
   10.55  
   10.56 -@verbatim
   10.57 -
   10.58 +@smallformat
   10.59 +@example
   10.60    void
   10.61  PointToPointNetDevice::SetReceiveErrorModel (Ptr<ErrorModel> em)
   10.62  {
   10.63 @@ -458,11 +463,13 @@
   10.64                     PointerValue (),
   10.65                     MakePointerAccessor (&PointToPointNetDevice::m_receiveErrorModel),
   10.66                     MakePointerChecker<ErrorModel> ())
   10.67 -@end verbatim
   10.68 +@end example
   10.69 +@end smallformat
   10.70  
   10.71  @subsection Plumb into the system
   10.72  
   10.73 -@verbatim
   10.74 +@smallformat
   10.75 +@example
   10.76  void PointToPointNetDevice::Receive (Ptr<Packet> packet)
   10.77  {
   10.78    NS_LOG_FUNCTION (this << packet);
   10.79 @@ -486,15 +493,18 @@
   10.80        ProcessHeader(packet, protocol);
   10.81        m_rxCallback (this, packet, protocol, GetRemote ());
   10.82        if (!m_promiscCallback.IsNull ())
   10.83 -        {           m_promiscCallback (this, packet, protocol, GetRemote (), GetAddress (), NetDevice::PACKET_HOST);
   10.84 +        {           m_promiscCallback (this, packet, protocol, GetRemote (), 
   10.85 +                      GetAddress (), NetDevice::PACKET_HOST);
   10.86          }
   10.87      }
   10.88  }
   10.89 -@end verbatim
   10.90 +@end example
   10.91 +@end smallformat
   10.92  
   10.93  @subsection Create null functional script
   10.94  
   10.95 -@verbatim
   10.96 +@smallformat
   10.97 +@example
   10.98  simple-error-model.cc
   10.99  
  10.100    // Error model
  10.101 @@ -514,7 +524,8 @@
  10.102    NS_LOG_UNCOND("Corrupt!");
  10.103    return false;
  10.104  }
  10.105 -@end verbatim
  10.106 +@end example
  10.107 +@end smallformat
  10.108  
  10.109  At this point, we can run the program with our trivial ErrorModel
  10.110  plumbed into the receive path of the PointToPointNetDevice.  It
  10.111 @@ -550,7 +561,8 @@
  10.112  
  10.113  We declare BasicErrorModel to be a subclass of ErrorModel as follows,
  10.114  
  10.115 -@verbatim
  10.116 +@smallformat
  10.117 +@example
  10.118  class BasicErrorModel : public ErrorModel
  10.119  {
  10.120  public:
  10.121 @@ -562,7 +574,8 @@
  10.122    virtual bool DoReset (void);
  10.123    ...
  10.124  }
  10.125 -@end verbatim
  10.126 +@end example
  10.127 +@end smallformat
  10.128  
  10.129  and configure the subclass GetTypeId function by setting a unique
  10.130  TypeId string and setting the Parent to ErrorModel:
    11.1 --- a/doc/manual/node.texi	Mon Oct 19 18:47:01 2009 -0700
    11.2 +++ b/doc/manual/node.texi	Mon Oct 19 18:47:30 2009 -0700
    11.3 @@ -20,8 +20,8 @@
    11.4  the protocols and applications.  @ref{fig:node} illustrates
    11.5  that Node objects contain a list of Applications (initially,
    11.6  the list is empty), a list of NetDevices (initially, the list
    11.7 -is empty), a unique integer ID, and a system ID (for
    11.8 -distributed simulation).
    11.9 +is empty), a list of ProtocolHandlers, a unique integer ID, and 
   11.10 +a system ID (for distributed simulation).
   11.11  
   11.12  The design tries to avoid putting too many dependencies on the
   11.13  base class Node, Application, or NetDevice for the following:
    12.1 --- a/doc/manual/python.texi	Mon Oct 19 18:47:01 2009 -0700
    12.2 +++ b/doc/manual/python.texi	Mon Oct 19 18:47:30 2009 -0700
    12.3 @@ -4,3 +4,6 @@
    12.4  @cartouche
    12.5  Placeholder chapter
    12.6  @end cartouche
    12.7 +
    12.8 +For now, please see the Python wiki page at @*
    12.9 +@uref{http://www.nsnam.org/wiki/index.php/NS-3_Python_Bindings,,http://www.nsnam.org/wiki/index.php/NS-3_Python_Bindings}.
    13.1 --- a/doc/manual/routing.texi	Mon Oct 19 18:47:01 2009 -0700
    13.2 +++ b/doc/manual/routing.texi	Mon Oct 19 18:47:30 2009 -0700
    13.3 @@ -25,7 +25,7 @@
    13.4  @image{figures/routing, 6in}
    13.5  @end float
    13.6  
    13.7 -Figure 11-1 shows the overall routing architecture for Ipv4.  The key objects
    13.8 +@ref{fig:routing} shows the overall routing architecture for Ipv4.  The key objects
    13.9  are Ipv4L3Protocol, Ipv4RoutingProtocol(s) (a class to which all 
   13.10  routing/forwarding has been delegated from Ipv4L3Protocol), and Ipv4Route(s).
   13.11  
   13.12 @@ -143,7 +143,8 @@
   13.13  For instance, this scheduling call will cause the tables to be rebuilt
   13.14  at time 5 seconds:
   13.15  @verbatim
   13.16 -  Simulator::Schedule (Seconds (5),&Ipv4GlobalRoutingHelper::RecomputeRoutingTables);
   13.17 +  Simulator::Schedule (Seconds (5),
   13.18 +    &Ipv4GlobalRoutingHelper::RecomputeRoutingTables);
   13.19  @end verbatim
   13.20  
   13.21  @subsection Global Routing Implementation
   13.22 @@ -199,15 +200,21 @@
   13.23  @node Unicast routing
   13.24  @section Unicast routing
   13.25  
   13.26 -There are presently four routing protocols defined:
   13.27 +There are presently five unicast routing protocols defined for IPv4 and
   13.28 +two for IPv6:
   13.29  @itemize @bullet
   13.30  @item class Ipv4StaticRouting (covering both unicast and multicast)
   13.31 -@item  Optimized Link State Routing (a MANET protocol defined in
   13.32 +@item  IPv4 Optimized Link State Routing (a MANET protocol defined in
   13.33  @uref{http://www.ietf.org/rfc/rfc3626.txt,,RFC 3626})
   13.34  @item class Ipv4ListRouting (used to store a prioritized list of routing
   13.35  protocols)
   13.36  @item class Ipv4GlobalRouting (used to store routes computed by the global
   13.37  route manager, if that is used)
   13.38 +@item class Ipv4NixVectorRouting (a more efficient version of global routing
   13.39 +that stores source routes in a packet header field)
   13.40 +@item class Ipv6ListRouting (used to store a prioritized list of routing
   13.41 +protocols)
   13.42 +@item class Ipv6StaticRouting 
   13.43  @end itemize
   13.44  
   13.45  In the future, this architecture should also allow someone to implement
    14.1 --- a/doc/manual/sockets.texi	Mon Oct 19 18:47:01 2009 -0700
    14.2 +++ b/doc/manual/sockets.texi	Mon Oct 19 18:47:30 2009 -0700
    14.3 @@ -42,8 +42,8 @@
    14.4  @item the API is not a complete sockets API, such as supporting
    14.5  all socket options or all function variants; 
    14.6  @item many calls use @code{ns3::Packet} class to transfer data
    14.7 -between application and socket.  This may seem a little funny to
    14.8 -people to pass ``Packets'' across a stream socket API, but think
    14.9 +between application and socket.  This may seem peculiar to
   14.10 +pass ``Packets'' across a stream socket API, but think
   14.11  of these packets as just fancy byte buffers at this level (more
   14.12  on this also below).
   14.13  @end itemize
   14.14 @@ -58,7 +58,7 @@
   14.15  @subsubsection Creating sockets
   14.16  
   14.17  An application that wants to use sockets must first create one.
   14.18 -On real systems, this is accomplished by calling socket():
   14.19 +On real systems using a C-based API, this is accomplished by calling socket():
   14.20  @verbatim
   14.21       int
   14.22       socket(int domain, int type, int protocol);
   14.23 @@ -79,11 +79,13 @@
   14.24  
   14.25  This method returns a smart pointer to a Socket object.  Here is an
   14.26  example:  
   14.27 -@verbatim
   14.28 +@smallformat
   14.29 +@example
   14.30    Ptr<Node> n0;
   14.31    // Do some stuff to build up the Node's internet stack
   14.32    Ptr<Socket> localSocket = Socket::CreateSocket (n0, TcpSocketFactory::GetTypeId ());
   14.33 -@end verbatim
   14.34 +@end example
   14.35 +@end smallformat
   14.36  
   14.37  In some ns-3 code, sockets will not be explicitly created by user's
   14.38  main programs, if an ns-3 application does it.  For instance, for
   14.39 @@ -149,7 +151,7 @@
   14.40    int Recv (uint8_t* buf, uint32_t size);
   14.41  @end verbatim
   14.42  
   14.43 -The non-Packet variants are left for legacy API reasons.  When calling
   14.44 +The non-Packet variants are provided for legacy API reasons.  When calling
   14.45  the raw buffer variant of @code{Send()}, the buffer is immediately
   14.46  written into a Packet and the @code{Send (Ptr<Packet> p)} is invoked.
   14.47  
   14.48 @@ -160,7 +162,7 @@
   14.49  
   14.50  @itemize @bullet
   14.51  @item Users can use the Tags facility of packets to, for example, encode
   14.52 -a flow ID or other helper data.
   14.53 +a flow ID or other helper data at the application layer.
   14.54  @item Users can exploit the copy-on-write implementation to avoid
   14.55  memory copies (on the receive side, the conversion back to a 
   14.56  @code{uint8_t* buf} may sometimes incur an additional copy).
   14.57 @@ -193,51 +195,6 @@
   14.58  
   14.59  @section POSIX-like sockets API 
   14.60  
   14.61 -@emph{this capability is under development and is scheduled for
   14.62 -inclusion in the ns-3.5 releasetimeframe; see the repository
   14.63 -http://code.nsnam.org/mathieu/ns-3-simu for details}
   14.64 -
   14.65 -The below is excerpted from Mathieu's post to ns-developers list
   14.66 -on April 4, 2008.
   14.67 -
   14.68 -"To summarize, the goal is that the full posix/socket API is defined in
   14.69 -src/process/simu.h: each posix type and function is re-defined there
   14.70 -with a simu_ or SIMU_ prefix to avoid ugly name clashes and collisions
   14.71 -(feel free to come up with a better prefix).
   14.72 -
   14.73 -Each process is created with a call to ProcessManager::Create and is
   14.74 -attached to that ProcessManager instance. So, if the ProcessManager
   14.75 -(which is aggregated to a Node in src/helper/process-helper.cc) is
   14.76 -killed when the simulation ends, the system will automatically reclaim
   14.77 -all the resources of each process associated to each manager. The same
   14.78 -happens when an application "exits" from its main function.
   14.79 -
   14.80 -The example application defines two posix "processes": the function
   14.81 -ClientProgram creates a udp socket on the localhost port 2000 and the
   14.82 -function ServerProgram creates a udp socket on the localhost port 2000.
   14.83 -The code does not work right now because I did not get the details of
   14.84 -simu_read right yet but, I do plan to make this work at some point.
   14.85 -
   14.86 -I really think that this approach is worthwhile for many reasons, a few
   14.87 -of which are outlined below:
   14.88 -@itemize @bullet
   14.89 -@item makes porting real world application code _much_ easier
   14.90 -
   14.91 -@item makes write applications for new users much easier because they can
   14.92 -read the bsd socket api reference and documentation and write code
   14.93 -directly.
   14.94 -
   14.95 -@item can be used to write applications which work in both simulation and
   14.96 -in the real world at the same time. To do this, all you have to do is
   14.97 -write your application to use the simu_ API, and, then, you can chose at
   14.98 -compile-time which implementation of that API you want to use: you can
   14.99 -pick one implementation which forwards all calls to the system BSD
  14.100 -socket API or another one which forwards all calls to the attached
  14.101 -ProcessManager. Arguably, I did not implement the version which forwards
  14.102 -to system BSD sockets but, that should be pretty trivial.
  14.103 -@end itemize
  14.104 -
  14.105 -So, anyway, comments about the overall API would be welcome. Students
  14.106 -interested in the gsoc project for real-world code integration should
  14.107 -consider looking at this also."
  14.108 -
  14.109 +@cartouche
  14.110 +Under development in the http://code.nsnam.org/mathieu/ns-3-simu repository.
  14.111 +@end cartouche
    15.1 --- a/doc/manual/statistics.texi	Mon Oct 19 18:47:01 2009 -0700
    15.2 +++ b/doc/manual/statistics.texi	Mon Oct 19 18:47:30 2009 -0700
    15.3 @@ -4,3 +4,7 @@
    15.4  @cartouche
    15.5  Placeholder chapter
    15.6  @end cartouche
    15.7 +This wiki page: @*
    15.8 +@uref{http://www.nsnam.org/wiki/index.php/Statistical_Framework_for_Network_Simulation,,http://www.nsnam.org/wiki/index.php/Statistical_Framework_for_Network_Simulation}
    15.9 +contains information about the proposed statistical framework that is 
   15.10 +located in @code{src/contrib} directory.
    16.1 --- a/doc/manual/tap.texi	Mon Oct 19 18:47:01 2009 -0700
    16.2 +++ b/doc/manual/tap.texi	Mon Oct 19 18:47:30 2009 -0700
    16.3 @@ -5,3 +5,7 @@
    16.4  Placeholder chapter
    16.5  @end cartouche
    16.6  
    16.7 +The Tap NetDevice can be used to allow a host system or virtual machines
    16.8 +to interact with a simulation.  See @*
    16.9 +@code{examples/tap/tap-wifi-dumbbell.cc} for an example. 
   16.10 +
    17.1 --- a/doc/manual/tcp.texi	Mon Oct 19 18:47:01 2009 -0700
    17.2 +++ b/doc/manual/tcp.texi	Mon Oct 19 18:47:30 2009 -0700
    17.3 @@ -105,10 +105,7 @@
    17.4  @subsection Current limitations
    17.5  @itemize @bullet
    17.6  @item Only Tahoe congestion control is presently supported.
    17.7 -@item Only IPv4 is supported (IPv6 support will start to be added in ns-3.3).
    17.8 -@item @uref{http://www.nsnam.org/bugzilla/show_bug.cgi?id=198,,Bug 198}:  TcpSocketImpl doesn't send acks with data packets in two-way transfers
    17.9 -@item @uref{http://www.nsnam.org/bugzilla/show_bug.cgi?id=250,,Bug 250}:  Tcp breaks if you set the DelAckCount parameter to be greater than 2
   17.10 -@item @uref{http://www.nsnam.org/bugzilla/show_bug.cgi?id=311,,Bug 311}:  Tcp socket close returns -1 but does not set errno.
   17.11 +@item Only IPv4 is supported (IPv6 support will start to be added after ns-3.6).
   17.12  @end itemize
   17.13  
   17.14  @section Network Simulation Cradle
   17.15 @@ -132,43 +129,17 @@
   17.16  @subsection Prerequisites
   17.17  
   17.18  Presently, NSC has been tested and shown to work on these platforms:
   17.19 -Linux i386 and Linux x86-64.  NSC does not support powerpc at the moment.
   17.20 +Linux i386 and Linux x86-64.  NSC does not support powerpc.
   17.21  
   17.22 -NSC requires the packages mercurial, flex, and bison.  
   17.23 +Building NSC requires the packages flex and bison.  
   17.24  
   17.25  @subsection Configuring and Downloading
   17.26  
   17.27 -NSC is disabled by default and must be explicitly configured in.  To try
   17.28 -this, type
   17.29 +Using the @code{build.py} script in ns-3-allinone directory, NSC will be
   17.30 +enabled by default unless the platform does not support it.  To disable
   17.31 +it when building ns-3, type:
   17.32  @verbatim
   17.33 -./waf configure --enable-nsc
   17.34 -@end verbatim
   17.35 -the output of the configuration will show something like:
   17.36 -@verbatim
   17.37 -Checking for NSC supported architecture x86_64                           : ok  
   17.38 -Pulling nsc updates from https://secure.wand.net.nz/mercurial/nsc
   17.39 -pulling from https://secure.wand.net.nz/mercurial/nsc
   17.40 -searching for changes
   17.41 -no changes found
   17.42 ----- Summary of optional NS-3 features:
   17.43 -...
   17.44 -Network Simulation Cradle     : enabled
   17.45 -...
   17.46 -@end verbatim 
   17.47 -if successful.  Note that the configure script pulls a recent copy of
   17.48 -NSC from a mercurial repository.  This download will not work if you are not
   17.49 -online.
   17.50 -
   17.51 -If everything went OK, you will see a directory called "nsc" in the top-level
   17.52 -directory, with contents like this:
   17.53 -@verbatim
   17.54 -audit.sh            linux-2.6/          openbsd3/           scons-time.py*
   17.55 -ChangeLog           linux-2.6.18/       README              SConstruct 
   17.56 -config.log          linux-2.6.26/       sconsign.py*        sim/
   17.57 -freebsd5/           lwip-1.3.0/         scons-LICENSE       test/
   17.58 -globaliser/         lwip-HEAD/          scons-local-1.0.1/  
   17.59 -INSTALL             ns/                 scons.py*           
   17.60 -LICENSE             omnetpp/            scons-README        
   17.61 +./waf configure --disable-nsc
   17.62  @end verbatim
   17.63  
   17.64  @subsection Building and validating
   17.65 @@ -233,12 +204,18 @@
   17.66  ns-3 @ref{Attributes} system, via a @uref{http://en.wikipedia.org/wiki/Sysctl,,
   17.67  sysctl}-like interface.  In the @code{examples/tcp-nsc-zoo} example, you
   17.68  can see the following configuration:
   17.69 -@verbatim
   17.70 -  // this disables TCP SACK, wscale and timestamps on node 1 (the attributes represent sysctl-values).
   17.71 -  Config::Set ("/NodeList/1/$ns3::Ns3NscStack<linux2.6.26>/net.ipv4.tcp_sack", StringValue ("0"));
   17.72 -  Config::Set ("/NodeList/1/$ns3::Ns3NscStack<linux2.6.26>/net.ipv4.tcp_timestamps", StringValue ("0"));
   17.73 -  Config::Set ("/NodeList/1/$ns3::Ns3NscStack<linux2.6.26>/net.ipv4.tcp_window_scaling", StringValue ("0"));
   17.74 -@end verbatim
   17.75 +@smallformat
   17.76 +@example
   17.77 +  // this disables TCP SACK, wscale and timestamps on node 1 (the attributes 
   17.78 +represent sysctl-values).
   17.79 +  Config::Set ("/NodeList/1/$ns3::Ns3NscStack<linux2.6.26>/net.ipv4.tcp_sack", 
   17.80 +StringValue ("0"));
   17.81 +  Config::Set ("/NodeList/1/$ns3::Ns3NscStack<linux2.6.26>/net.ipv4.tcp_timestamps", 
   17.82 +StringValue ("0"));
   17.83 +  Config::Set ("/NodeList/1/$ns3::Ns3NscStack<linux2.6.26>/net.ipv4.tcp_window_scaling", 
   17.84 +StringValue ("0"));
   17.85 +@end example
   17.86 +@end smallformat
   17.87  These additional configuration variables are not available to native ns-3
   17.88  TCP.
   17.89  
   17.90 @@ -331,11 +308,10 @@
   17.91  @itemize @bullet
   17.92  @item NSC only works on single-interface nodes; attempting to run it on
   17.93  a multi-interface node will cause a program error.  This limitation should
   17.94 -be fixed by ns-3.3.
   17.95 -@item Cygwin and OS X PPC are not presently supported
   17.96 -@item The non-Linux stacks of NSC are not supported
   17.97 -@item NSC's integration into the build system presently requires on-line
   17.98 -access and mercurial, and is a slow download.
   17.99 +be fixed by ns-3.7.
  17.100 +@item Cygwin and OS X PPC are not supported
  17.101 +@item The non-Linux stacks of NSC are not supported in ns-3
  17.102 +@item Not all socket API callbacks are supported
  17.103  @end itemize
  17.104  
  17.105  For more information, see
    18.1 --- a/doc/manual/troubleshoot.texi	Mon Oct 19 18:47:01 2009 -0700
    18.2 +++ b/doc/manual/troubleshoot.texi	Mon Oct 19 18:47:30 2009 -0700
    18.3 @@ -9,7 +9,9 @@
    18.4  * Run-time errors::
    18.5  @end menu
    18.6  
    18.7 -Please note that the wiki (@uref{http://www.nsnam.org/wiki/index.php/Troubleshooting}) may have contributed items.
    18.8 +Please note that the wiki @* 
    18.9 +(@uref{http://www.nsnam.org/wiki/index.php/Troubleshooting}) 
   18.10 +may have contributed items.
   18.11  
   18.12  @node Build errors
   18.13  @section Build errors
   18.14 @@ -23,18 +25,21 @@
   18.15  
   18.16  Here is an example of what might occur:
   18.17  
   18.18 -@verbatim
   18.19 +@smallformat
   18.20 +@example
   18.21  ns-old:~/ns-3-nsc$ ./waf --run tcp-point-to-point
   18.22  Entering directory `/home/tomh/ns-3-nsc/build'
   18.23  Compilation finished successfully 
   18.24  Command ['/home/tomh/ns-3-nsc/build/debug/examples/tcp-point-to-point'] exited with code -11 
   18.25 -@end verbatim 
   18.26 +@end example
   18.27 +@end smallformat
   18.28  
   18.29  The error message says that the program terminated unsuccessfully, but it is
   18.30  not clear from this information what might be wrong.  To examine more
   18.31  closely, try running it under the @uref{http://sources.redhat.com/gdb/,,gdb debugger}:
   18.32  
   18.33 -@verbatim
   18.34 +@smallformat
   18.35 +@example
   18.36  ns-old:~/ns-3-nsc$ ./waf --run tcp-point-to-point --command-template="gdb %s"
   18.37  Entering directory `/home/tomh/ns-3-nsc/build'
   18.38  Compilation finished successfully 
   18.39 @@ -44,7 +49,8 @@
   18.40  welcome to change it and/or distribute copies of it under certain conditions.
   18.41  Type "show copying" to see the conditions.
   18.42  There is absolutely no warranty for GDB.  Type "show warranty" for details.
   18.43 -This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".
   18.44 +This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db 
   18.45 +library "/lib/libthread_db.so.1".
   18.46  
   18.47  (gdb) run
   18.48  Starting program: /home/tomh/ns-3-nsc/build/debug/examples/tcp-point-to-point 
   18.49 @@ -61,7 +67,8 @@
   18.50  $2 = {m_ptr = 0x0}
   18.51  (gdb) quit
   18.52  The program is running.  Exit anyway? (y or n) y
   18.53 -@end verbatim
   18.54 +@end example
   18.55 +@end smallformat
   18.56  
   18.57  Note first the way the program was invoked-- pass the command to run as
   18.58  an argument to the command template "gdb %s".  
   18.59 @@ -70,11 +77,13 @@
   18.60  socketFactory.
   18.61  
   18.62  Let's look around line 136 of tcp-point-to-point, as gdb suggests:
   18.63 -@verbatim
   18.64 +@smallformat
   18.65 +@example
   18.66    Ptr<SocketFactory> socketFactory = n2->GetObject<SocketFactory> (Tcp::iid);
   18.67    Ptr<Socket> localSocket = socketFactory->CreateSocket ();
   18.68    localSocket->Bind ();
   18.69 -@end verbatim
   18.70 +@end example
   18.71 +@end smallformat
   18.72  
   18.73  The culprit here is that the return value of GetObject is not being
   18.74  checked and may be null.  
   18.75 @@ -82,6 +91,8 @@
   18.76  Sometimes you may need to use the @uref{http://valgrind.org,,valgrind memory
   18.77  checker} for more subtle errors.  Again, you invoke the use of valgrind
   18.78  similarly:
   18.79 -@verbatim
   18.80 +@smallformat
   18.81 +@example
   18.82  ns-old:~/ns-3-nsc$ ./waf --run tcp-point-to-point --command-template="valgrind %s"
   18.83 -@end verbatim
   18.84 +@end example
   18.85 +@end smallformat
    19.1 --- a/doc/manual/wifi.texi	Mon Oct 19 18:47:01 2009 -0700
    19.2 +++ b/doc/manual/wifi.texi	Mon Oct 19 18:47:30 2009 -0700
    19.3 @@ -28,9 +28,8 @@
    19.4  @item QoS-based EDCA and queueing extensions of @strong{802.11e}
    19.5  @item various propagation loss models including @strong{Nakagami, Rayleigh, Friis, LogDistance, FixedRss, Random} 
    19.6  @item two propagation delay models, a distance-based and random model
    19.7 -@item various rate control algorithms including @strong{Aarf, Arf, Cara, Onoe, Rraa, and ConstantRate} 
    19.8 -@item @emph{(under development)} 802.11s (mesh)
    19.9 -@item @emph{(under development)} Minstrel rate control
   19.10 +@item various rate control algorithms including @strong{Aarf, Arf, Cara, Onoe, Rraa, ConstantRate, and Minstrel} 
   19.11 +@item 802.11s (mesh), described in another chapter
   19.12  @end itemize
   19.13  
   19.14  The set of 802.11 models provided in ns-3 attempts to provide
   19.15 @@ -159,10 +158,12 @@
   19.16  loss of 46.6777 dB at reference distance of 1m.
   19.17  
   19.18  Users will typically type code such as:
   19.19 -@verbatim
   19.20 +@smallformat
   19.21 +@example
   19.22    YansWifiChannelHelper wifiChannelHelper = YansWifiChannelHelper::Default ();
   19.23    Ptr<WifiChannel> wifiChannel = wifiChannelHelper.Create ();
   19.24 -@end verbatim
   19.25 +@end example
   19.26 +@end smallformat
   19.27  to get the defaults.  Note the distinction above in creating a helper
   19.28  object vs. an actual simulation object.
   19.29  In ns-3, helper objects (used at the helper API only) are created on the
   19.30 @@ -203,35 +204,45 @@
   19.31  Setting up a non-QoS MAC layers the object we use is @code{ns3::NqosWifiMacHelper}.
   19.32  For example the following user code configures a non-QoS MAC sta and changes its default
   19.33  values for contention window and Aifsn:
   19.34 -@verbatim
   19.35 +@smallformat
   19.36 +@example
   19.37    NqosWifiMacHelper wifiMacHelper = NqosWifiMacHelper::Default ();
   19.38    Ssid ssid = Ssid ("ns-3-ssid");
   19.39 -  wifiMacHelper.SetType ("ns3::NqstaWifiMac", "Ssid", SsidValue (ssid), "ActiveProbing", BooleanValue (false));
   19.40 -  wifiMacHelper.SetDcaParameters ("MinCw", UintegerValue (20), "Aifsn", UintegerValue (3));
   19.41 -@end verbatim
   19.42 +  wifiMacHelper.SetType ("ns3::NqstaWifiMac", "Ssid", SsidValue (ssid), 
   19.43 +"ActiveProbing", BooleanValue (false));
   19.44 +  wifiMacHelper.SetDcaParameters ("MinCw", UintegerValue (20), "Aifsn", 
   19.45 +UintegerValue (3));
   19.46 +@end example
   19.47 +@end smallformat
   19.48  
   19.49  Setting up a QoS MACs we use a @code{ns3::QosWifiMacHelper} instead.
   19.50  This object could be also used to change default EDCA parameters, and to set a possible MSDU aggregator
   19.51  for a particular access class in order to use 802.11n MSDU aggregation feature.
   19.52  A possible user code:
   19.53 -@verbatim
   19.54 +@smallformat
   19.55 +@example
   19.56    QosWifiMacHelper wifiMacHelper = QosWifiMacHelper::Default ();
   19.57 -  wifiMacHelper.SetType ("ns3::QapWifiMac", "Ssid", SsidValue (ssid), "BeaconGeneration", BooleanValue (true),
   19.58 +  wifiMacHelper.SetType ("ns3::QapWifiMac", "Ssid", SsidValue (ssid), 
   19.59 +"BeaconGeneration", BooleanValue (true),
   19.60                           "BeaconInterval", TimeValue (Seconds (2.5)));
   19.61    wifiMacHelper.SetEdcaParametersForAc (AC_VO, "MinCw", UintegerValue (2));
   19.62 -  wifiMacHelper.SetMsduAggregatorForAc (AC_VO, "ns3::MsduStandardAggregator", "MaxAmsduSize", UintegerValue (3839));
   19.63 -@end verbatim
   19.64 +  wifiMacHelper.SetMsduAggregatorForAc (AC_VO, "ns3::MsduStandardAggregator", 
   19.65 +"MaxAmsduSize", UintegerValue (3839));
   19.66 +@end example
   19.67 +@end smallformat
   19.68  
   19.69  Call to QosWifiMacHelper::Default () is needed in order to set default EDCA parameters properly for all
   19.70  access classes. Otherwise we should set them one by one:
   19.71 -@verbatim
   19.72 +@smallformat
   19.73 +@example
   19.74    QosWifiMacHelper wifiMacHelper;
   19.75 -  wifiMacHelper.SetEdcaParametersForAc (AC_VO, "MinCw", UintegerValue (2), "MaxCw", UintegerValue (7),
   19.76 -                                               "Aifsn", UintegerValue (2));
   19.77 -  wifiMacHelper.SetEdcaParametersForAc (AC_VI, "MinCw", UintegerValue (7), "MaxCw", UintegerValue (15),
   19.78 -                                               "Aifsn", UintegerValue (2));
   19.79 +  wifiMacHelper.SetEdcaParametersForAc (AC_VO, "MinCw", UintegerValue (2), 
   19.80 +"MaxCw", UintegerValue (7), "Aifsn", UintegerValue (2));
   19.81 +  wifiMacHelper.SetEdcaParametersForAc (AC_VI, "MinCw", UintegerValue (7), 
   19.82 +"MaxCw", UintegerValue (15), "Aifsn", UintegerValue (2));
   19.83    ...
   19.84 -@end verbatim
   19.85 +@end example
   19.86 +@end smallformat
   19.87  
   19.88  @subsection WifiHelper
   19.89  
   19.90 @@ -244,9 +255,11 @@
   19.91  @code{ns3::ArfWifiManager}.
   19.92  Now, let's use the wifiPhyHelper and wifiMacHelper created above to install WifiNetDevices
   19.93  on a set of nodes in a NodeContainer "c":
   19.94 -@verbatim
   19.95 +@smallformat
   19.96 +@example
   19.97    NetDeviceContainer wifiContainer = WifiHelper::Install (wifiPhyHelper, wifiMacHelper, c);
   19.98 -@end verbatim
   19.99 +@end example
  19.100 +@end smallformat
  19.101  This creates the WifiNetDevice which includes also a WifiRemoteStationManager,
  19.102  a WifiMac, and a WifiPhy (connected to the matching WifiChannel).
  19.103  
  19.104 @@ -257,12 +270,16 @@
  19.105  @subsection AdHoc WifiNetDevice configuration 
  19.106  This is a typical example of how a user might configure an adhoc network.
  19.107  
  19.108 -@emph{Write me}
  19.109 +@cartouche
  19.110 +To be completed
  19.111 +@end cartouche
  19.112  
  19.113  @subsection Infrastructure (Access Point and clients) WifiNetDevice configuration 
  19.114  This is a typical example of how a user might configure an access point and a set of clients. 
  19.115  
  19.116 -@emph{Write me}
  19.117 +@cartouche
  19.118 +To be completed
  19.119 +@end cartouche
  19.120  
  19.121  @node The WifiChannel and WifiPhy models
  19.122  @section The WifiChannel and WifiPhy models