[Ns-developers] node architecture: request for feedback
tomh at tomh.org
Fri Nov 3 14:31:03 PST 2006
Lee Begg wrote:
> My very first thought after reading that was "that seems fine".
> My next one was: "That is completely the wrong order to design it in".
> The "Node Architecture" feels very much of "Top down" thinking. As the node is
> a container of sorts, it's contents are more important that the node itself.
Mathieu already stated that it really captures a summary of the present
open design issue, rather than reflecting the thought process.
> The interface between layers (particularly phy<->mac<->network) is key and
> will probably be the driver behind any choice of node architecture. Most of
> the components that are in the node are mentioned, but not really how they
> fit together.
> So the first thing to define the properties of the layers and other components
> in the node. Between layers a stable API might be the way to link them,
> to/from other components the callbacks would work best.
By API, I assume you mean how layer N accesses layer N+1 in this
discussion, for example, to pass a packet upwards. There are a few
techniques for this:
- layer N can have explicit pointer to Layer N+1 and use N+1's public
- layer N can have a more base class pointer to Layer N+1 if both derive
from a base class such as ns-2 Connector (such as how "target" is used
- layer N can go through a node pointer to get to layer N+1
- layer N+1 can register a callback with layer N, when the simulation is
> Another few things on the Node Architecture document.
> Have a "wireless node" is asking for trouble. The fact it is wireless is a
> property of *one or more* of the (phy-)interfaces, not the node itself.
> Perhaps "BatteryPoweredNode" or "EnergyMonitoringNode" would have been a
> better name for an energy limited node. Otherwise it sounds like the limit of
> only one (phy-)interface and it's wireless, and the only way to change that
> is multiple inheritance.
I would like to see an InternetNode that might be subclassed into
something that has an EnergyModel and/or Location object, for a mobile
device. But I would prefer that architecturally the Wired and Wireless
node objects are otherwise similar (both have multiple interfaces,
etc.). this is in fact a strong requirement for me (to avoid ns-2
I think we want to avoid multiple inheritance.
I also think we want to allow users to construct their own Node classes
and put the plumbing together themselves; they may start from the base
Node or derive from something like InternetNode if it is useful.
> (De)Multiplexers often occur *inside* layers, or use info inside layers. Such
> as Ethernet's and ip's protocol type numbers, and transport layer protocol's
> port numbers.
I agree, although the implementation can be split out as George has done
> And sometimes higher layers need info from lower layers (such
> as Tcp using ip addresses in determining the application along with the port
> numbers. Just occurred to me that the tags in the packet could be used for
> that though.
Yes, it may be that layers have some common things they do (pass packets
up and down) and layer-specific things (e.g., which interface did this
packet arrive on?) could be put into a packet tag.
> I would like to point out that there will probably be different
> implementations of the same layer/protocol/channel model/whatever, with
> varying amounts of detail and accuracy depending on what the user is
Yes, agree strongly. What we want to avoid is having users encounter
problems like "TCP Cubic model doesn't work with a WirelessNode" etc.
To avoid this, we want to make our models more flexible to user whims
for interconnecting things, but of course there is a cost to the
flexibility and we need to decide where to put the costs or how much
flexibility to provide if it complicates the user experience.
This is not an obvious design decision, hence the request for more feedback.
> I hope this is the sort of feedback you were after.
Yes, thanks. It may be easier to provide more feedback once there are
better code samples.
More information about the Ns-developers