[Ns-developers] release update [feedback needed]

[Tom Henderson]

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 ?

This comment is related to what you addressed above-- the responsibility 
of the routing protocol to discover interfaces initially rather than 
rely on notify interface.

> 
>> 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.
> 

This question came up in another form on IRC today; maybe we could 
revisit Gustavo's ns-3-signals code?

Tom