[Ns-bugs] [Bug 1049] Issues with OLSR HNA messages sent by multiple gateways

[code@nsnam.ece.gatech.edu]

http://www.nsnam.org/bugzilla/show_bug.cgi?id=1049


Julien Boite <juboite at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |juboite at gmail.com




--- Comment #3 from Julien Boite <juboite at gmail.com>  2011-02-02 18:22:12 EDT ---
(In reply to comment #2)
> I haven't tested your patch yet, but from my first glance through it, my main
> comment is that I'm not in favour of keeping SetRoutingTableAssociation() a one
> time call.
> 
> Instead, I would prefer a modification to GetAssociations() such that it
> returns the combined set of tuples from m_hnaRoutingTableAssociation and the
> local HNA entries. In short, move the duplicate entry check from
> RoutingProtocol::SendHna() into OlsrState::GetAssociations().


I understand your point... You're right, something must be done to update local
HNA entries if "OlsrRoutingProtocol::SetRoutingTableAssociation()" is called
more than once.
However, I think the "GetAssociations()" method in the OlsrState class can not
return the combined set of tuples like you suggest, because it is has no access
to the (private) attribute "m_routingTableAssociation" of the
OlsrRoutingProtocol class (this is conceptually good).

I think 2 solutions can be envisioned:

1. keep the 2 non-overlapping sets of local HNA entries (one for each
association method, i.e. "m_routingTableAssociation" in the OlsrRoutingProtocol
class and "m_associations" in the OlsrState class) and create a private method
"GetLocalHnaAssociations()" in the OlsrRoutingProtocol class to return a set
with all local HNA entries. This added method would perform the aggregation of
entries stored in each set. This is what you suggest. However, I strongly
believe that "m_associations" in class "OlsrState" should contain all local
associations. With this solution, it would not be the case.

2. use the "m_associations" attribute of the OlsrState class to store ALL local
HNA entries like I have proposed, but add a test in the
"OlsrRoutingProtocol::SetRoutingTableAssociation()" method to check whether a
routing table has already been associated. If not, add entries. If a routing
table has already been associated, delete entries from the old association and
add the new ones. This would be in accordance with the initial behavior: the
new routing table association was simply set.

Which solution sounds best for you? Personally, I have a preference for
solution 2...

-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.