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
* 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. i
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 f
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
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,
* 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 ho
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 o
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 sens
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 mor
* 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
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 t
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 eve
12 matches
Mail list logo
