Hi Matt, Thanks for your answer!
I can see your point; it affects a problem I had some days ago: The problem of choosing the appropriate local IP address to publish (provided no hostnames should be used). I decided to solve this problem at application level. Every SA publishes its service several times, once for every local IP address (my software keeps track of its service registrations and periodcally checks if there are new local addresses to publish or if a service needs to be deregistered). The UA then checks which of the published endpoints are actually reachable. By using a unique identifier for every SA as URLpath I make sure that every SA is presented to the user only once, even if several endpoints were reachable. I'v already implemented this solution on both the SA and UA side and it would work perfectly fine if only slpd rechecked the available interfaces from time to time. Your workaround with the reg file is not an option for me since it would require some manual configuration on every node. Best regards Robert Am 09.08.2011 17:10, schrieb Matthew Pendlebury: > Robert, > > I believe your understanding of the workings of slpd is correct, namely it > scans exactly once at startup. I've recently investigated just this > behaviour because this sort of functionality would be useful to us too. > > There may be slightly more complexity to the issue than just polling > interfaces for new/changed addresses that SLP should listen on. In that the > advertisements that SLP makes embed details of how to contact the service in > the returned service URL. Your advertised service then has a requirement to > ensure that it too is available via the new address and is resolvable. > > A partial workaround if your service registrations are long lived might be to > put your registrations in a static reg file and have slpd be restarted > periodically (to rescan the interfaces). It's really not great but might > achieve what you want to do in the short term. > > Cheers > > --Matt > > > > > > -----Original Message----- > From: Robert Hegner [mailto:rheg...@hsr.ch] > Sent: 09 August 2011 07:57 > To: openslp-users@lists.sourceforge.net > Subject: [Openslp-users] Force slpd to periodically rescan interfaces > > slpd seems to scan the available network interfaces only once at > startup. So service discovery does not work in situations like the > following: > > - The SA has not yet received its IP address from a DHCP server when > slpd is starting. > > - The user powers up the SA before connecting it to the network. > > - The user decides to plug in the network cable to another port when the > SA is already running. > > So my question is: Is it possible to force slpd to periodically rescan > the available network interfaces and connect to them? > > I think this feature is necessary to give the user a real plug'n'play > (or plug and discover...) feeling. My goal is still to avoid any manual > configuration on the SAs (like setting fixed IP addresses in some > configuration file). It should be possible for the user to just attach a > new node (SA) to the power and to the network (in any order...). The > node should then get its IP address from a DHCP server and publish its > service via SLP. > > Best regards > Robert > > > ------------------------------------------------------------------------------ > uberSVN's rich system and user administration capabilities and model > configuration take the hassle out of deploying and managing Subversion and > the tools developers use with it. Learn more about uberSVN and get a free > download at: http://p.sf.net/sfu/wandisco-dev2dev > _______________________________________________ > Openslp-users mailing list > Openslp-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openslp-users > > Consider the environment before printing this mail. > > Thales e-Security Limited is incorporated in England and Wales with company > registration number 2518805. Its registered office is located at 2 Dashwood > Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15 > 2NX. > > The information contained in this e-mail is confidential. It may also be > privileged. It is intended only for the stated addressee(s) and access to it > by any other person is unauthorised. If you are not an addressee or the > intended addressee, you must not disclose, copy, circulate or in any other > way use or rely on the information contained in this e-mail. Such > unauthorised use may be unlawful. If you have received this e-mail in error, > please inform us immediately on +44 (0)1223 723600 and delete it and all > copies from your system. Commercial matters detailed or referred to in this > e-mail are subject to a written contract signed for and on behalf of Thales > e-Security Limited. > > ------------------------------------------------------------------------------ > uberSVN's rich system and user administration capabilities and model > configuration take the hassle out of deploying and managing Subversion and > the tools developers use with it. Learn more about uberSVN and get a free > download at: http://p.sf.net/sfu/wandisco-dev2dev ------------------------------------------------------------------------------ uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev _______________________________________________ Openslp-users mailing list Openslp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openslp-users
