[Ns-developers] release update [feedback needed]

[Mathieu Lacage]

Ok, here is an updated patch which addresses your comments. I was not
able to test NotifyRemoveAddress because there is no Ipv4::RemoveAddress
method.

Mathieu

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
> methods.
> 
> > 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, 
> 
> No.
> 
> > 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.
> 
> Mathieu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: routing.patch
Type: text/x-patch
Size: 46764 bytes
Desc: not available
Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20090610/7fa5597e/routing-0001.bin