From: Jan Huwald <jh@sotun.de>
To: The list for a Better Approach To Mobile Ad-hoc Networking
<b.a.t.m.a.n@lists.open-mesh.org>
Subject: Re: [B.A.T.M.A.N.] Mangling broadcast packets
Date: Sat, 27 Jul 2013 14:14:12 +0200 [thread overview]
Message-ID: <51F3B994.8030804@sotun.de> (raw)
In-Reply-To: <20130726121608.GA16248@pandem0nium>
[-- Attachment #1: Type: text/plain, Size: 1339 bytes --]
Hi Simon,
thanks for your advice.
On 07/26/2013 02:16 PM, Simon Wunderlich wrote:
> * send unicast to each neighbor instead of sending broadcast (find
> out who is a neighbor by reading originator tables) --> using unicast
> might be faster than using broadcast too, which is usually fixed to a
> lower mcast rate.
I had not considered the mcast rate issue. Given the typical low degree
topology that is probably the most efficient way to go. Even more so
given that bcast-packets are send several times. (I just discovered this
in the batman srcs.)
> alfred, which servers a similar purpose (at least i think so) does
> the same.
We had a look at alfred, but unfortunately it is no replacement for us.
But hopefully I can copy your neighbourhood discovery code :-)
Nitpicking part:
>> * using NFQUEUE on all enslaved interfaces to mangle packets
>> before they are seen by batman; requires out-of-kernel parsing of
>> batman-adv packets and watching enslaved interfaces
>
> out-of-kernel parsing of batman-adv packets will kill you
> performance completely.
By filtering with U32 and friends only packets that are scheduled for
local delievery anyway would be processed in userspace. That _should_
have only a minor performance impact. (And only be ugly^10.)
With best regards,
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
prev parent reply other threads:[~2013-07-27 12:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-25 21:12 [B.A.T.M.A.N.] Mangling broadcast packets Jan Huwald
2013-07-26 12:16 ` Simon Wunderlich
2013-07-27 12:14 ` Jan Huwald [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51F3B994.8030804@sotun.de \
--to=jh@sotun.de \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.