[Top] [All Lists]

Re: RFC: IPSEC patch 0 for netlink events

To: jamal <hadi@xxxxxxxxxx>
Subject: Re: RFC: IPSEC patch 0 for netlink events
From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Date: Wed, 30 Mar 2005 23:14:22 +1000
Cc: Patrick McHardy <kaber@xxxxxxxxx>, Masahide NAKAMURA <nakam@xxxxxxxxxxxxxx>, "David S. Miller" <davem@xxxxxxxxxxxxx>, netdev <netdev@xxxxxxxxxxx>
In-reply-to: <1112187210.1090.140.camel@jzny.localdomain>
References: <1111864971.1092.904.camel@jzny.localdomain> <> <1111867875.1089.915.camel@jzny.localdomain> <> <1111950449.1089.938.camel@jzny.localdomain> <> <1112184572.1089.80.camel@jzny.localdomain> <> <1112187210.1090.140.camel@jzny.localdomain>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.6+20040907i
Hi Jamal:

On Wed, Mar 30, 2005 at 07:53:30AM -0500, jamal wrote:
> I may be influenced by some of the behaviors of rtnetlink users then.
> Typically (I may need to go back and double check), they dont echo back.

That's right.  However, this isn't really an echo.  It's a notification
from the kernel to a particular multicast group.  For example, in the
case of a delete request, the multicast message will presumably contain
full details about the state being deleted.

This is something that may be of interest to the sending process.
> > For netlink it is important to use a different socket for receiving
> > multicast messages since otherwise you run the risk of losing unicast
> > messages when it overruns.
> This may be the reason actually now that i think of it. Its not the user
> you are avoiding to echo back to, rather the overloading the user. What

Well the message itself shouldn't overload the user since its size can
be calculated before hand.  If anything is going to overload the netlink
socket it's going to be multicast messages caused by other processes.

Really, if you're going to listen to multicast messages via netlink,
you should do it in a socket where you don't expect to get unicast
> if (n->nlmsg_flags&NLM_F_ECHO)
>   broadcast to all
> else
>   just send to all sans the originator
> sounds reasonable?

Well since I don't think this is an echo request, no :)

Visit Openswan at
Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page:
PGP Key:

<Prev in Thread] Current Thread [Next in Thread>