On Mon, Oct 04, 2004 at 02:30:11PM +0200, Harald Hoyer wrote: > Deron Meranda wrote: > >On Sat, 02 Oct 2004 07:49:01 -0400, Ted Kaczmarek <tedkaz@xxxxxxxxxxxxx> > >wrote: ... > >Thanks for the response, but my problem is for a normal application > >running in user-space, not in the kernel. .... > >The problem occurs when the interface is brought down and then back > >up. The kernel looses track of all of the multicast memberships that > >used to be associated with that interface. .... > >Or, as a less desirable workaround, provide a way for an application > >to be notified when an interface goes down or back up (yes, there are > >kernel-level notifications, but nothing available at user-space. that > >I know about). In my opinion tearing down the infrastructure for a network link should tear down and forget state. i.e. the kernel should forget about such things. One of the 'reasons' for cycling an interface down/up is to clear out such state. The point about notification is interesting. I would have to do some homework to convince myself what the correct actions should be. Is there some sort of timeout or heartbeat in the design that can be used by the application to notice that the connection has been torn down. One of the interesting about multicast is the action of routers. I think IPV6 is involved. There can be a handful of ways that that plays out... are you tunneling. If so does the tunnel collapse (as it should) and routing can no longer find you. One of the reasons that I believe that a lost link should tear down state has to do with security. If I was to pull your network link and insert my own from a 'bad boy system' I do not believe that we would want the 'bad boy system' to reconnect to all the network connections that your system established. switching a link or ifconfig linkN down/up should act the same in my mind. -- T o m M i t c h e l l Me, I would "Rather" Not.
