9 Aug 10:54
OLSRD HNA/MID/TCs - Problems?!
A mail from Henning (via OLSRd-DEV-list):
Hello,
I had a huge cleanup session for the OLSRd development code yesterday and
discovered something BAD... something that might go back to the original OLSRd
code from the diploma thesis of Andreas Toennesen (I tracked it back to the
initial checkin in the olsr-ng mercurial repository in September 2004).
OLSRd has the timing configuration for HNA/MID/TCs for each interface, which
does not make really sense because this messages are flooded, so interfaces
"configured slow" will still get messages from faster interfaces through
flooding.
The really bad thing is that each of the messages send out through the
multiple interfaces has it's own message sequence number !
So OLSRd is NOT sending a common flooded information through all of it's
interfaces, it's sending different messages, sometimes with slightly different
content through the interfaces. This means that a node with 4 interfaces
produce FOUR TIMES as much TCs/MIDs/HNAs per timeslot than anyone thought,
which are a horror for duplicate detection and network load.
The sollution in the development branch is to pull the timing parameters into
the global section (out of the interfaces) and have one global timer for TCs,
one for HNAs and one for MIDs which send messages through ALL of the nodes
interfaces.
Do we want this change backported into the stable branch ? I think yes. But
how shall we do it without breaking too much stuff ? Do you think it's enough
to have a "sane" TC/MID/HNA timing default and just ignore the settings in the
interfaces ? All webinterfaces and olsrd.conf are just designed for the
interface parameters, so the configuration change is not trivial.
What do you say ?
Henning Rogge
I had a huge cleanup session for the OLSRd development code yesterday and
discovered something BAD... something that might go back to the original OLSRd
code from the diploma thesis of Andreas Toennesen (I tracked it back to the
initial checkin in the olsr-ng mercurial repository in September 2004).
OLSRd has the timing configuration for HNA/MID/TCs for each interface, which
does not make really sense because this messages are flooded, so interfaces
"configured slow" will still get messages from faster interfaces through
flooding.
The really bad thing is that each of the messages send out through the
multiple interfaces has it's own message sequence number !
So OLSRd is NOT sending a common flooded information through all of it's
interfaces, it's sending different messages, sometimes with slightly different
content through the interfaces. This means that a node with 4 interfaces
produce FOUR TIMES as much TCs/MIDs/HNAs per timeslot than anyone thought,
which are a horror for duplicate detection and network load.
The sollution in the development branch is to pull the timing parameters into
the global section (out of the interfaces) and have one global timer for TCs,
one for HNAs and one for MIDs which send messages through ALL of the nodes
interfaces.
Do we want this change backported into the stable branch ? I think yes. But
how shall we do it without breaking too much stuff ? Do you think it's enough
to have a "sane" TC/MID/HNA timing default and just ignore the settings in the
interfaces ? All webinterfaces and olsrd.conf are just designed for the
interface parameters, so the configuration change is not trivial.
What do you say ?
Henning Rogge
_______________________________________________ WLANnews mailing list WLANnews@... Abonnement abbestellen? -> https://freifunk.net/mailman/listinfo/wlannews Weitere Infos zu den freifunk.net Mailinglisten und zur An- und Abmeldung unter http://freifunk.net/mailinglisten
RSS Feed