[Ns-developers] release update [feedback needed]
mathieu.lacage at sophia.inria.fr
Wed Jun 10 01:57:10 PDT 2009
Ok, here is an updated patch which addresses your comments. I was not
able to test NotifyRemoveAddress because there is no Ipv4::RemoveAddress
On Wed, 2009-06-10 at 08:12 +0200, Mathieu Lacage wrote:
> On Tue, 2009-06-09 at 22:38 -0700, Tom Henderson wrote:
> > + virtual void NotifyInterface (uint32_t i, bool isUp) = 0;
> > This is similar to what is found in RTM_NEWLINK and RTM_DELLINK for
> > rtnetlink in Linux (man rtnetlink), except that the boolean flag allows
> > both to be in a single method NotifyInterface. Since the routing
> > protocol consuming this message will presumably be able to acquire a
> > pointer to class Ipv4 to get whatever other information is needed, the
> > interface index is probably sufficient information to pass up.
> > The questions/concerns I have:
> > 1) implicit assumptions are made about the order in which these
> > operations occur:
> > - set an IP interface to up
> > - add an IP address to an interface
> > - set an IPv4RoutingProtocol to the Ipv4 object
> > - add an additional routing protocol to the Ipv4ListRouting protocol
> > There are certain combinations of operations that will cause this to
> > lose information; e.g.
> > - add the Ipv4ListRouting to the Ipv4, and subsequently add protocols
> > like OLSR (the protocols added later will not get the notifications)
> I believe that the above needs to be dealt with by asking routing
> protocols to discover existing interfaces and handle them when they are
> added to a node. The Notify methods then only notify about changes in
> the existing configuration. Initially, to avoid that complexity, I think
> that it would be reasonable to ask users to first setup routing
> protocols and, then, setup ip interfaces. We can improve the routing
> protocol implementations to make them able to handle any ordering of
> operations (add to node, then, add interfaces or add interfaces, then
> add to node) in a separate step. Faker and I have done some work towards
> that recently with the changes you merged to the InternetStackHelper to
> allow users to aggregate the different elements of a udp/tcp/ip/arp
> stack in any order.
> > - add an IP address to an interface (such as a second address) after the
> > first address was added and interface was SetUp()
> As you mention below, it's easy to deal with the above with extra Notify
> > so, it would help to add code to deal with users possibly rearranging
> > these operations. For instance, I think that probably these additions
> > are needed:
> > - NotifyAddAddress (uint32_t i, Ipv4InterfaceAddress addr)
> > - NotifyRemoveAddress (uint32_t i, Ipv4InterfaceAddress addr)
> ok, will do the above and split NotifyInterface in NotifyInterfaceUp and
> NotifyInterfaceDown. I was lazy :)
> > or, for symmetry with NotifyInterface(), it could be:
> > - NotifyAddress (uint32_t i, Ipv4InterfaceAddress addr, bool IsAdded);
> > and probably Ipv4ListRoutingImpl::AddRoutingProtocol () needs to notify
> > the new routing protocol added of the interfaces, in case it is added
> > after being hooked to Ipv4.
> What do you mean by this exactly ?
> > 2) implicit assumption about the user not repeating these methods or
> > calling them out of order-- e.g. can NotifyInterface (i, true); be
> > called multiple times (resulting in multiple redundant routes)? Should,
> > for instance, the current state of an interface be saved so that these
> > calls can be detected and avoided?
> It should be easy to invoke these methods only on real state changes.
> > 3) I had thought about putting in an rtnetlink-like framework for what
> > you posted, but that may be overkill for the moment. However, suppose
> It feels overkill for the moment.
> > someone wanted to add an rtnetlink notification framework to ns-3 in the
> > future. What kind of notification framework would you recommend?
> > Multicast messaging internally? Some kind of callback framework (could
> > you have multiple users register callbacks somewhere for the same event,
> > and where would they register (a Netlink object?)?
> I don't have any good idea about this.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 46764 bytes
Desc: not available
Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090610/7fa5597e/routing-0001.bin
More information about the Ns-developers