On 11/10/2010 06:19 PM, Nick Wagner wrote:
> I actually needed something like this for a windows project.  I did 
> not submit it back to the group at the time because I didn't have time 
> to create a general solution for the rest of the platforms, and 
> because I relied on static linking to iphlpapi which would have been a 
> new build dependency that was not in all windows platforms at the 
> time.  I would love it if slpd handled network changes on all platforms.
>
> I've attached my version of slpd_win32.c, just look for NJW comments. 
>  If the attachment doesn't go through, the relevant code is pretty simple:
>
> I spawn a thread that uses iphlpapi to notify me whenever the network 
> has changed, at which I set a flag.  In the main service loop where 
> G_SIGALRM is checked, I also check my new flag:
>
> /* NJW Handle our signal as well*/
> if (G_SIGRECON_DA)
> {
> //We don't want to lose any locally-registered services, but we want 
> to rediscover
> //everyone.  We'll reinit our socket lists, and then change our boot time
> SLPDLog("Network changing, re-initializing sockets and re-discovering\n");
> SLPDPropertyInit(G_SlpdCommandLine.cfgfile);  //We need to re-init the 
> network interfaces, also inits the DA timestamp and active/passive 
> discovery triggers
> SLPDIncomingInit();
> SLPDOutgoingInit();
>
> //Pretend we've rebooted and need to discover everyone
> SLPDatabaseInit(&G_SlpdKnownDAs);
> G_SIGRECON_DA = 0;
> }
>
> I also needed to add an extern for G_SlpdKnownDAs to make it compile.
>
> --Nick
Hi Nick,

Thanks for sharing your solution. Since the 'reconnect' functionality 
and the 'network change detection' functionality are actually separate 
things, we might consider to start with only making this 'reconnect' 
functionality available, with perhaps some signal mechanism to trigger 
it from 'outside'. When this is done from some network script (like they 
are used on most Linux systems), this will probably already be 
sufficient for a lot of systems.

The way you do the reconnect is quite rigorous, especially with the 
changing DA boot timestamp and the fact that any ongoing communication 
will be aborted. How hard do you think it is to only delete existing 
sockets for network interfaces that were removed and to create new 
sockets only for interfaces that were added? Also only for new 
interfaces DA discovery needs to be done, I guess.

BR,
     Roel
>
>
>
> On Wed, Nov 10, 2010 at 6:47 AM, Roel van de Kraats 
> <r...@advancedcargo.eu <mailto:r...@advancedcargo.eu>> wrote:
>
>     Dear all,
>
>     Currently, slpd only looks for the available network interfaces
>     once at
>     start-up. In a situation where for instance dhcp is used, but no IP
>     address was obtained yet when slpd starts, a (manual) restart of
>     slpd is
>     required to bind to that interface afterwards. Any local registrations
>     (from applications using libslp) will be lost in that restart.
>
>     Does anyone have the same experience? Do you happen to have any
>     solution?
>
>     A solution I can think of, is that slpd is notified with e.g. a signal
>     to find the interfaces again, bind to the ones that were not already
>     used before, locate DAs again, register services with the new
>     address, etc.
>
>     What are your ideas on this?
>
>     Thanks in advance for thinking along..
>
>     Best regards,
>         Roel
>
>     
> ------------------------------------------------------------------------------
>     The Next 800 Companies to Lead America's Growth: New Video Whitepaper
>     David G. Thomson, author of the best-selling book "Blueprint to a
>     Billion" shares his insights and actions to help propel your
>     business during the next growth cycle. Listen Now!
>     http://p.sf.net/sfu/SAP-dev2dev
>     _______________________________________________
>     Openslp-devel mailing list
>     Openslp-devel@lists.sourceforge.net
>     <mailto:Openslp-devel@lists.sourceforge.net>
>     https://lists.sourceforge.net/lists/listinfo/openslp-devel
>
>


------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
_______________________________________________
Openslp-devel mailing list
Openslp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openslp-devel

Reply via email to