On Wed, 2005-03-30 at 07:23, Herbert Xu wrote:
> > Thinking ... thinking .. Good point.
> > I defineteley need at least:
> > a) case original message sent via netlink: pid of the original process
> > so when i multicast in netlink i dont echo back to it.
> I don't think you need to do that. RFC 2367 says that the kernel should
> send that message to all listening processes. It doesn't put an exception
> on the sending process.
> This makes sense also because the echoed message is really a new packet
> sent by the kernel. It's not necessarily equal to the original packet.
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.
The final response of success is unicast though if a ACK flag was set in
the original message. Actually an echo may happen in addition to the
success indicator if such an echo is requested for by NLM_F_ECHO.
I will go back and scan, but example:
netlink_broadcast(rtnl, skb, pid, RTMGRP_IPV4_ROUTE, GFP_KERNEL);
netlink_unicast(rtnl, skb, pid, MSG_DONTWAIT);
> In fact checking the socket pid is not enough to avoid sending the
> message back to the originator. For instance, if the originator
> used a different socket for receiving multicast messages then this
> wouldn't work anyway.
> 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
i could do is double check for the NLM_F_ECHO as well so we give the
user a choice to receive the message as well if they indicate they need
it. i.e something along:
broadcast to all
just send to all sans the originator
I am actually indifferent - if you think strongly about it then i could
be swayed (pending testing)