[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