On 3 April 2012 03:37, Nick Wagner <ne...@wingedbeast.org> wrote: > I'm afraid I don't have the expertise to critique your three workarounds. > Does anyone else on the list care to comment? My typical approach to these > sorts of problems is usually to a) patch the application to handle network > changes, b) have something on the system detect the network changes and do > the appropriate application restarts, or c) make sure everything starts late > enough that there's an address and let the user restart the app if they > change the machine's address. Big thanks for the feedback!
I think I have somewhat wrapped my head around the problem. The delayed started is not really the issue. I think it was my misunderstanding of the IGMP join stuff. 0.0.0.0 in the multicast context means default route. So, each of the interfaces need to be enumerated and used. Our implementation uses the b), and will suffice. However, what have been the proposed solutions to dynamically loading the changed interfaces? I made a quick hack with the code, but it wasn't an hour job to just call the functions terminate signal invokes. Where there any discussion regarding some type of SLPGetInterfaces() SLPScanInterfaces() etc. over the socket interface? Or where they more on the lines of signal handlers? I would be nice for any application to know which interfaces the daemon is registered on. /Ryan > > --Nick > > > On Mon, Apr 2, 2012 at 7:01 AM, Ryan Raasch <ryan.raa...@gmail.com> wrote: >> >> On 1 April 2012 19:48, Nick Wagner <ne...@wingedbeast.org> wrote: >> >> >> >> Yea, you are kinda' right. I want the daemon to listen on any and all >> >> interfaces >> >> ie. 0.0.0.0. But it seems that when the slp daemon starts up, and there >> >> is >> >> not >> >> default gw, the multicast setup fails. This is probably a fundamental >> >> misunderstanding >> >> on my part. If multicast needs a default route when any interface is >> >> used, that means >> >> that only one interface sends out the IGMP group join stuff. That >> >> would mean only >> >> one interface sends the service multicast packets (our is only a SA). >> >> What am i doing >> >> wrong, or do I just misunderstand the problem? >> >> >> > >> > Sockets that want to send multicast over a particular network interface >> > must >> > set a socket option to send over that interface. Otherwise, the stack >> > will >> > only send it out whatever network interface it considers the >> > primary/default. And the socket option (IP_MULTICAST_IF) takes an ip >> > address, although I have no idea if that preference "sticks" if the >> > interface changes its address subsequent to the setsockopt. I've never >> > tried to do any of this with 0.0.0.0, it could be that it just fails. >> > >> Ok. I think i have an understanding of the startup. The daemon starts up, >> and >> must send out IGMP join requests on the interfaces. If the 0.0.0.0 is >> given, then >> the kernel just chooses the default route, and sends it. That is why when >> our >> system does not yet have the default route setup, the mulicast setup >> fails. >> >> BTW, our concerns are about restarting the slp daemon. In an small system, >> there are always ewww responses, when a daemon needs to be restarted. >> I know most don't see an issue with this, but there could be blocking >> issues with restarting the damon (using system()). >> >> > I don't know anything about your device/product, but is there a point in >> > your device that you know it has the necessary ip addresses? Either via >> > moving the daemon startup in rc.d, or using whatever watchdogs your >> > device >> > may have? And is slpd the only program on your device that has this >> > sort of >> > ip address issue? >> >> The difference would be that most daemons only listen, where the slp needs >> to >> register itself, ie. send data to a multicast address. >> >> I have guessed 3 "possible" work-arounds to this. >> >> 1. Is there a way to setup a routing rule with iptables or equivalent, >> to forward >> multicast addresses from the loopback interface? >> >> 2. Some type of simple userspace daemon which listens to loopback >> multicast >> and then forwards the traffic to the interfaces. Of course, this is a >> thought without >> reading the slp protocol in depth :-P >> >> 3. Allow SIG_HUP to call re-initialize network also (opposite to >> HandleSigTerm()) >> without exiting daemon. >> >> /Ryan >> >> > >> > --Nick > > ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Openslp-users mailing list Openslp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openslp-users
