F5/unison
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

merge with HEAD

Browse Source
This commit is contained in:
Mathieu Lacage
2008-06-13 17:20:06 -07:00
parent 1aef4543cc 9ccd6dadcb
commit 9ed0f04944
22 changed files with 257 additions and 100 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
src/applications/onoff/onoff-application.h
View File

@@ -40,10 +40,25 @@ class RandomVariable;
class Socket;
/**
* \ingroup applications
* \defgroup onoff OnOffApplication
*
* This traffic generator follows an On/Off pattern: after
* Application::StartApplication
* is called, "On" and "Off" states alternate. The duration of each of
* these states is determined with the onTime and the offTime random
* variables. During the "Off" state, no traffic is generated.
* During the "On" state, cbr traffic is generated. This cbr traffic is
* characterized by the specified "data rate" and "packet size".
*/
/**
* \ingroup onoff
*
* \brief Generate traffic to a single destination according to an
* OnOff pattern.
*
* This traffic follows an On/Off pattern: after Application::StartApplication
* This traffic generator follows an On/Off pattern: after
* Application::StartApplication
* is called, "On" and "Off" states alternate. The duration of each of
* these states is determined with the onTime and the offTime random
* variables. During the "Off" state, no traffic is generated.

15
src/applications/packet-sink/packet-sink.h
View File

@@ -34,6 +34,21 @@ class Socket;
class Packet;
/**
* \ingroup applications
* \defgroup packetsink PacketSink
*
* This application was written to complement OnOffApplication, but it
* is more general so a PacketSink name was selected. Functionally it is
* important to use in multicast situations, so that reception of the layer-2
* multicast frames of interest are enabled, but it is also useful for
* unicast as an example of how you can write something simple to receive
* packets at the application layer. Also, if an IP stack generates
* ICMP Port Unreachable errors, receiving applications will be needed.
*/
/**
* \ingroup packetsink
*
* \brief Receive and consume traffic generated to an IP address and port
*
* This application was written to complement OnOffApplication, but it

1
src/applications/udp-echo/udp-echo-client.h
View File

@@ -30,6 +30,7 @@ class Socket;
class Packet;
/**
* \ingroup udpecho
* \brief A Udp Echo client
*
* Every packet sent should be returned by the server and received here.

6
src/applications/udp-echo/udp-echo-server.h
View File

@@ -30,6 +30,12 @@ class Socket;
class Packet;
/**
* \ingroup applications
* \defgroup udpecho UdpEcho
*/
/**
* \ingroup udpecho
* \brief A Udp Echo server
*
* Every packet received is sent back.

15
src/helper/olsr-helper.h
View File

@@ -26,11 +26,17 @@
namespace ns3 {
/**
* \brief Helper class that adds OLSR routing to nodes.
*/
class OlsrHelper
{
public:
OlsrHelper ();
/**
* \brief Set default OLSR routing agent parameters
*/
void SetAgent (std::string tid,
std::string n0 = "", const AttributeValue &v0 = EmptyAttributeValue (),
std::string n1 = "", const AttributeValue &v2 = EmptyAttributeValue (),
@@ -41,8 +47,17 @@ public:
std::string n6 = "", const AttributeValue &v6 = EmptyAttributeValue (),
std::string n7 = "", const AttributeValue &v7 = EmptyAttributeValue ());
/**
* \brief Enable OLSR routing for a set of nodes
*/
void Install (NodeContainer container);
/**
* \brief Enable OLSR routing for a single node
*/
void Install (Ptr<Node> node);
/**
* \brief Enable OLSR routing for all nodes
*/
void InstallAll (void);
private:
ObjectFactory m_agentFactory;

10
src/internet-stack/ipv4-end-point-demux.h
View File

@@ -30,6 +30,16 @@ namespace ns3 {
class Ipv4EndPoint;
/**
* \brief Demultiplexes packets to various transport layer endpoints
*
* This class serves as a lookup table to match partial or full information
* about a four-tuple to an ns3::Ipv4EndPoint. It internally contains a list
* of endpoints, and has APIs to add and find endpoints in this demux. This
* code is shared in common to TCP and UDP protocols in ns3. This demux
* sits between ns3's layer four and the socket layer
*/
class Ipv4EndPointDemux {
public:
typedef std::list<Ipv4EndPoint *> EndPoints;

11
src/internet-stack/ipv4-end-point.h
View File

@@ -30,6 +30,17 @@ namespace ns3 {
class Header;
class Packet;
/**
* \brief A representation of an internet endpoint/connection
*
* This class provides an internet four-tuple (source and destination ports
* and addresses). These are used in the ns3::Ipv4EndPointDemux as targets
* of lookups. The class also has a callback for notification to higher
* layers that a packet from a lower layer was received. In the ns3
* internet-stack, these notifications are automatically registered to be
* received by the corresponding socket.
*/
class Ipv4EndPoint {
public:
Ipv4EndPoint (Ipv4Address address, uint16_t port);

1
src/internet-stack/ipv4-interface.h
View File

@@ -58,6 +58,7 @@ class Packet;
*
* Subclasses must implement the two methods:
* - Ipv4Interface::SendTo
* - Ipv4Interface::GetDevice
*/
class Ipv4Interface : public Object
{

3
src/internet-stack/ipv4-l3-protocol.h
View File

@@ -43,6 +43,9 @@ class Node;
/**
* \brief Implement the Ipv4 layer.
*
* This is the actual implementation of IP. It contains APIs to send and
* receive packets at the IP layer, as well as APIs for IP routing.
*/
class Ipv4L3Protocol : public Object
{

3
src/internet-stack/ipv4-l4-demux.h
View File

@@ -35,6 +35,9 @@ class Node;
/**
* \brief L4 Ipv4 Demux
*
* This class demultiplexes IP datagrams to the correct layer four protocol
* object. This demux sits between IP and layer 4.
*/
class Ipv4L4Demux : public Object
{

6
src/internet-stack/ipv4-l4-protocol.h
View File

@@ -33,10 +33,10 @@ class Packet;
class Ipv4Address;
/**
* \brief L4 Protocol base class
* \brief L4 Protocol abstract base class
*
* If you want to implement a new L4 protocol, all you have to do is
* implement a subclass of this base class and add it to an L4Demux.
* This is an abstract base class for layer four protocols which use IPv4 as
* the network layer.
*/
class Ipv4L4Protocol : public Object
{

2
src/internet-stack/pending-data.h
View File

@@ -32,7 +32,7 @@
namespace ns3
{
class Packet;
//Doc:ClassXRef
class PendingData {
public:
PendingData ();

8
src/internet-stack/tcp-header.h
View File

@@ -30,6 +30,14 @@
namespace ns3 {
/**
* \brief Header for the Transmission Control Protocol
*
* This class has fields corresponding to those in a network TCP header
* (port numbers, sequence and acknowledgement numbers, flags, etc) as well
* as methods for serialization to and deserialization from a byte buffer.
*/
class TcpHeader : public Header
{
public:

11
src/internet-stack/tcp-l4-protocol.h
View File

@@ -39,9 +39,16 @@ namespace ns3 {
class Node;
class Socket;
class TcpHeader;
/**
* \brief Implementation of the TCP protocol
*/
* \brief A layer between the sockets interface and IP
*
* This class allocates "endpoint" objects (ns3::Ipv4EndPoint) for TCP,
* and SHOULD checksum packets its receives from the socket layer going down
* the stack , but currently checksumming is disabled. It also recieves
* packets from IP, and forwards them up to the endpoints.
*/
class TcpL4Protocol : public Ipv4L4Protocol {
public:
static TypeId GetTypeId (void);

6
src/internet-stack/tcp-socket-factory-impl.h
View File

@@ -35,11 +35,13 @@ class TcpL4Protocol;
* \ingroup Tcp
* \section Tcp Overview
*
* The TCP code in ns3::InternetNode is ported from the
* The TCP code in ns3's internet stack is ported from the
* <a href="http://www.ece.gatech.edu/research/labs/MANIACS/GTNetS/">
* Georgia Tech Network Simulator (GTNetS)</a>.
*
*
* Most of the logic is in class ns3::TcpSocketImpl.
* This class serves to create sockets of the TcpSocketImpl
* type. That is, it creates sockets which use the GTNetS Tahoe code.
*/
class TcpSocketFactoryImpl : public TcpSocketFactory
{

14
src/internet-stack/tcp-socket-impl.h
View File

@@ -42,6 +42,20 @@ class Packet;
class TcpL4Protocol;
class TcpHeader;
/**
* \ingroup socket
*
* \brief An implementation of a stream socket using TCP.
*
* This class contains an implementation of TCP Tahoe, as well as a sockets
* interface for talking to TCP. Features include connection orientation,
* reliability through cumulative acknowledgements, congestion and flow
* control. Finite send/receive buffer semantics are modeled.
*
* Asynchronous callbacks to provide notifications to higher layers that a
* protocol event has occured, such as space freeing up in the send buffer
* or new data arriving in the receive buffer.
*/
class TcpSocketImpl : public TcpSocket
{
public:

4
src/internet-stack/udp-header.h
View File

@@ -29,6 +29,10 @@
namespace ns3 {
/**
* \brief Packet header for UDP packets
*
* This class has fields corresponding to those in a network UDP header
* (port numbers, payload size, checksum) as well as methods for serialization
* to and deserialization from a byte buffer.
*/
class UdpHeader : public Header
{

7
src/internet-stack/udp-socket-impl.h
View File

@@ -36,6 +36,13 @@ class Node;
class Packet;
class UdpL4Protocol;
/**
* \brief A sockets interface to UDP
*
* This class subclasses ns3::UdpSocket, and provides a socket interface
* to ns3's implementation of UDP.
*/
class UdpSocketImpl : public UdpSocket
{
public:

24
src/node/application.h
View File

@@ -33,17 +33,13 @@ class Node;
class RandomVariable;
/**
* \ingroup node
* \defgroup application Application
*/
/**
* \ingroup application
* \brief The base class for all ns3 applications
* \addtogroup applications Applications
*
* Class ns3::Application can be used as a base class for ns3 applications.
* Applications are associated with individual nodes. Each node
* holds a list of references (smart pointers) to its applications.
*
* Class Application is the base class for all ns3 applications.
* Applications are associated with individual nodes.
*
* Conceptually, an application has zero or more Socket
* Conceptually, an application has zero or more ns3::Socket
* objects associated with it, that are created using the Socket
* creation API of the Kernel capability. The Socket object
* API is modeled after the
@@ -53,6 +49,14 @@ class RandomVariable;
* in ns3. A set of "upcalls" are defined that will be called when
* the previous blocking call would normally exit. THis is documented
* in more detail Socket class in socket.h.
*
* The main purpose of the base class application public API is to
* provide a uniform way to start and stop applications.
*/
/**
* \brief The base class for all ns3 applications
*
*/
class Application : public Object
{

79
src/routing/global-routing/global-routing.h Normal file
View File

@@ -0,0 +1,79 @@
/* -*- Mode:C++; c-file-style:"gnu"; indent-tabs-mode:nil; -*- */
/*
* Copyright 2008 University of Washington
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation;
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
*/
/**
* \ingroup routing
* \defgroup globalrouting Global Routing
*
* \section model Model
*
* ns-3 global routing performs pre-simulation static route computation
* on a layer-3 Ipv4 topology. The user API from the script level is
* fairly minimal; once a topology has been constructed and addresses
* assigned, the user may call ns3::GlobalRouteManager::PopulateRoutingTables()
* and the simulator will initialize the routing database and set up
* static unicast forwarding tables for each node.
*
* The model assumes that all nodes on an ns-3 channel are reachable to
* one another, regardless of whether the nodes can use the channel
* successfully (in the case of wireless). Therefore, this model
* should typically be used only on wired topologies. API does not
* yet exist to control the subset of a topology to which this global
* static routing is applied.
*
* This model also does not yet deal with the possible presence of
* layer-2 relays such as switches, bridges, and hubs, although ns-3 does
* not have such devices yet.
*
* \section api API and Usage
*
* Users must include ns3/global-route-manager.h header file. After the
* IPv4 topology has been built and addresses assigned, users call
* ns3::GlobalRouteManager::PopulateRoutingTables (), prior to the
* ns3::Simulator::Run() call. There are no other attributes or
* public methods that are typically called, or ways to parameterize
* the behavior.
*
* \section impl Implementation
*
* A singleton object, ns3::GlobalRouteManager, builds a global routing
* database of information about the topology, and executes a Dijkstra
* Shortest Path First (SPF) algorithm on the topology for each node, and
* stores the computed routes in each node's IPv4 forwarding table by
* making use of the routing API in class ns3::Ipv4.
*
* The nodes that export data are those that have had an ns3::GlobalRouter
* object aggregated to them. The ns3::GlobalRouter can be thought of
* as a per-node agent that exports topology information to the
* ns3::GlobalRouteManager. When it comes time to build the global
* routing database, the list of nodes is iterated and each node with
* an ns3::GlobalRouter object is asked to export routing information
* concerning the links to which it is attached.
*
* The format of the data exported conforms to the OSPFv2 standard
* (http://www.ietf.org/rfc/rfc2328.txt). In particular, the
* information is exported in the form of ns3::GlobalLSA objects that
* semantically match the Link State Advertisements of OSPF.
*
* By using a standard data format for reporting topology, existing
* OSPF route computation code can be reused, and that is what is done
* by the ns3::GlobalRouteManager. The main computation functions are
* ported from the quagga routing suite (http://www.quagga.net).
*
*/

41
src/routing/olsr/olsr.cc
View File

@@ -1,41 +0,0 @@
/* -*- Mode: C++; c-file-style: "gnu"; indent-tabs-mode:nil; -*- */
/*
* Copyright (c) 2007 INESC Porto
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation;
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
* Author: Gustavo J. A. M. Carneiro <gjc@inescporto.pt>
*/
#include "olsr-agent.h"
#include "olsr.h"
namespace ns3 { namespace olsr {
void
EnableAllNodes (void)
{
EnableNodes <NodeList::Iterator> (NodeList::Begin (), NodeList::End ());
}
void
EnableNode (Ptr<Node> node)
{
olsr::Agent::CreateDefault (node)->Start ();
}
}} // namespace ns3, olsr

73
src/routing/olsr/olsr.h
View File

@@ -21,46 +21,39 @@
#ifndef OLSR_H
#define OLSR_H
#include "ns3/node-list.h"
namespace ns3
{
/**
* \namespace ns3::olsr
* \brief Includes a set of utility functions to enable OLSR on
* certain nodes with default parameters. For finer grained control
* of OLSR parameters, see OlsrAgent.
*/
namespace olsr
{
/// \brief Start the OLSR routing agent on all nodes
void EnableAllNodes (void);
/// \brief Start the OLSR routing agent on a given list of nodes
template <typename InputIterator>
void EnableNodes (InputIterator begin, InputIterator end);
/// \brief Start the OLSR routing agent on the given node
void EnableNode (Ptr<Node> node);
}
}
// implementation
namespace ns3
{
namespace olsr
{
template <typename InputIterator>
void EnableNodes (InputIterator begin, InputIterator end)
{
for (InputIterator i = begin; i != end; i++)
{
EnableNode (*i);
}
}
}
}
/**
* \ingroup routing
* \defgroup olsr OLSR
*
* \section model Model
*
* This model implements the base specification of the Optimized
* Link State Routing (OLSR) protocol, which is a dynamic mobile ad hoc
* unicast routing protocol. It has been developed at the
* University of Murcia (Spain) by Francisco J. Ros for NS-2, and was
* ported to NS-3 by Gustavo Carneiro at INESC Porto (Portugal).
*
* 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
*
* A helper class for OLSR has been written. After an IPv4 topology
* has been created and unique IP addresses assigned to each node, the
* simulation script writer can call one of three overloaded functions
* with different scope to enable OLSR: ns3::OlsrHelper::Install
* (NodeContainer container); ns3::OlsrHelper::Install (Ptr<Node>
* node); or ns3::OlsrHelper::InstallAll (void);
*
* In addition, the behavior of OLSR can be modified by changing certain
* attributes. The method ns3::OlsrHelper::SetAgent () can be used
* to set OLSR attributes. These include HelloInterval, TcInterval,
* MidInterval, Willingness. Other parameters are defined as macros
* in olsr-agent-impl.cc.
*/
#endif /* OLSR_H */