Hello!
So we do something like this:
Yes, exactly.
Actually, there was a function with similar functionality: rtnetlink_send().
net/sched/* used it, older net/ipv4/ still did this directly.
Alexey
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to
Hello!
Makes sense, especially for auto generated handles. I've been listening
to the notifications on a separate socket for this purpose.
That's... complicated. But cool. :-)
It does make sense, the way it has been implemented if at all is
creepy. Even worse, IPv6 is using current-pid,
Hello!
Actually I think the only safe solution is to allocate a separate
socket for multicast messages. In other words, if you want reliable
unicast reception on a socket, don't bind it to a multicast group.
Yes, it was the point of my advocacy of NLM_F_ECHO. :-)
Alexey
-
To unsubscribe
* Alexey Kuznetsov [EMAIL PROTECTED] 2006-08-12 15:03
Actually, it was the idea. If requestor asked NLM_F_ECHO and subscribed
to muticasts, it suppresses double notifications. If it did not ask
NLM_F_ECHO, he is not interested in results, he knows what's going on
without this.
F.e. it was
Hello!
I get your point and I see the value. Unfortunately, probably due to
lack of documentation, this feature isn't used by any applications I
know of.
Well, tc was supposed to use it, but this did not happen and
it remained deficient.
We even put in the hacks to make identification of
* Alexey Kuznetsov [EMAIL PROTECTED] 2006-08-11 19:35
Well, tc was supposed to use it, but this did not happen and
it remained deficient.
Makes sense, especially for auto generated handles. I've been listening
to the notifications on a separate socket for this purpose. It would
make sense
Alexey Kuznetsov [EMAIL PROTECTED] wrote:
Probably, unicasts sent due to NLM_F_ECHO should somehow override
rcvbuf limits.
Actually I think the only safe solution is to allocate a separate
socket for multicast messages. In other words, if you want reliable
unicast reception on a socket,
Hello!
This patch handles NLM_F_ECHO in netlink_rcv_skb() to
handle it in a central point. Most subsystems currently
interpret NLM_F_ECHO as to just unicast events to the
originator of the change while the real meaning of the
flag is to echo the request.
Do not you think it is useless to
* Alexey Kuznetsov [EMAIL PROTECTED] 2006-08-10 19:51
This patch handles NLM_F_ECHO in netlink_rcv_skb() to
handle it in a central point. Most subsystems currently
interpret NLM_F_ECHO as to just unicast events to the
originator of the change while the real meaning of the
flag is to echo
Hello!
What's wrong with listening to the notification for that purpose?
Nothing! NLM_F_ECHO _is_ listening for notifications without subscription
to multicast groups and need to figure out what messages are yours.
But beyond this NLM_F_ECHO is totally subset of this.
Which still makes much
Hello
* Alexey Kuznetsov [EMAIL PROTECTED] 2006-08-11 00:32
Nothing! NLM_F_ECHO _is_ listening for notifications without subscription
to multicast groups and need to figure out what messages are yours.
But beyond this NLM_F_ECHO is totally subset of this.
Which still makes much more sense
The current behaviour around NLM_F_ECHO is inconsistent
and spread all around in various subsystems and doesn't
represent what it was meant for.
This patch handles NLM_F_ECHO in netlink_rcv_skb() to
handle it in a central point. Most subsystems currently
interpret NLM_F_ECHO as to just unicast
12 matches
Mail list logo
