[Ns-bugs] [Bug 277] star topologies are painful to create

bugzilla-daemon@nsnam-www.ece.gatech.edu bugzilla-daemon at nsnam-www.ece.gatech.edu
Mon Aug 11 11:24:22 PDT 2008


http://www.nsnam.org/bugzilla/show_bug.cgi?id=277





------- Comment #9 from raj.b at gatech.edu  2008-08-11 14:24 -------
If any amount of code can be reused easily without copy/paste across multiple
source files, it should be done.  Way back at the Atlanta meeting, we discussed
eventually having topology "helpers"; right now seems like a natural time to
tackle them.

Since device helpers have common API, and now we have a use case to enforce
these APIs, I say +1 to Mathieu's suggestion of a device-helper base class.  It
is important to conceptually separate device-helpers from topology-helpers, so
StarTopology or StarTopologyHelper could enforce this distinction.  Our src
directory could additionally enforce the distinction with e.g. src/topology
seperate from src/helpers, or perhaps src/helpers/devices and
src/helpers/topolgy.  I lean towards an std::pair like custom container for the
output of StarHelper::Install instead of pass-by-reference output parameters. 
This gets rid of the ambiguity of what is "first" and what is "second".

struct StarDeviceContainer
{
  NetDeviceContainer center;
  NetDeviceContainer terminals;
}

class StarTopology
{
public:
  StarTopology (DeviceHelperBase helper) : m_helper(helper) {}
  StarDeviceContainer Install (Ptr<Node> center, NodeContainer periphery);
private:
  DeviceHelperBase m_helper;
};

The open question in my mind then becomes how do we handle when topology
helpers are being used with incompatible device/link types?


-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


More information about the Ns-bugs mailing list