[Olsr-dev] Bug in edge detection

[Sven-Ola Tuecke]

Hey,

I was not aware, that messages can exceed a packet. I would consider this as 
a bug (is tc msg.size adapted accordingly?). While assembling packets, an 
oversized TC should be sent with a new packet as a first step.

Anyhow - if a node has more than 180 IPv4 (or 75 IPv6) neighbours, I would 
not expect to be able to send a single ping. Why? Because Beacons are sent 
by each node every 1/10 second at 1mbit. A beacon is ~ 100 Byte. So I expect 
the maximum beacon emitter count for a particular area in the range 
1,000,000 / 1,000 / 10 => around 100. Yes, you can enforce beaconless 
operation - but there are other management frame types too...

// Sven-Ola

"Hannes Gredler" <(spam-protected)> schrieb im Newsbeitrag 
news:(spam-protected)
> On Thu, Sep 06, 2007 at 05:25:07PM +0200, Bernd Petrovitsch wrote:
> | On Thu, 2007-09-06 at 17:08 +0200, Hannes Gredler wrote:
> | [...]
> | > i have recently stumbled on a interesting problem that causes
> | > quite some inefficiency wrt malloc churn() and SPF calculations.
> | >
> | > it happens is when a TC message gets striped over two (or more) IP 
> packets.
> | > this is typically for a TC message at the MTU boundary of a OLSR 
> packet.
> |
> | Hmm, what's in the RFC about this?
> |
> | [...]
> | > patchset producing the debug output above is at
> | > http://gredler.at/download/olsrd/inplace-spf-1.diff.gz
> | >
> | > any smart thoughts for a fix ? -
> |
> | Without time and without looking into code, only the generic ones:
> |
> | On the sender side: Don't send half TC packets.
>
> hmmm not really an option ... what to do if the neighbor set > 1500 bytes.
> just because of massive neighbors ?
>
> | On the receiver side (which shouldn't be necessary with the above):
> | Wait with the TC packet processing until we are sure that it is
> | complete, e.g.
> | if the next is already seen or some timeout.
>
> what about this:
>
> rather than deleting the edge we tweak T_time to an expired value 
> (now_times -1).
>
> if the neighbor set gets found when processing further packets then T_time
> gets overwritten, otherwise it will get deleted when prcessing eventloop
> next time.
>
> /hannes
>
> -- 
> Olsr-dev mailing list
> (spam-protected)
> http://lists.olsr.org/mailman/listinfo/olsr-dev