openslp-users — user issues and questions

Re: [Openslp-users] DA deployment

[Wang, R. <Ren...@nu...>]

Hi Matt,

When an application makes OpenSLP API calls, e.g. a SLPReg and/or SLPFindSrvs calls, does it always communicate with the local slpd daemon and the local daemon forwards the application requests to the network, or the application directly sends unicast/broadcast/multicast message out?

Ren


From: Wang, Ren
Sent: Wednesday, October 24, 2012 7:19 PM
To: 'HIRD Matthew'; Nick Wagner
Cc: ope...@li...
Subject: RE: [Openslp-users] DA deployment

Matt,

Thank you so much for your help. Yes, it makes sense.

Ren

From: HIRD Matthew [mailto:Mat...@uk...]<mailto:[mailto:Mat...@uk...]>
Sent: Wednesday, October 24, 2012 11:36 AM
To: Wang, Ren; Nick Wagner
Cc: ope...@li...<mailto:ope...@li...>
Subject: RE: [Openslp-users] DA deployment

sent again but trimmed to fit within the mailing list size limits. Ren, reply or it will be held for approval on the mailing list.

Ren

when you search, are you using slptool? if so, after step 3 run slptool but with the (I think) -u option to do a unicast search against a particular daemon. I think you might find that your app is using the same slp.conf as the daemon and so registers directly with the DA. ie. the SA is never involved and so has nothing to sync to the DA when it comes back up. Make sense?

cheers
Matt

From: Wang, Ren [mailto:Ren...@nu...]<mailto:[mailto:Ren...@nu...]>
Sent: 23 October 2012 14:36
To: HIRD Matthew; Nick Wagner
Cc: ope...@li...<mailto:ope...@li...>
Subject: RE: [Openslp-users] DA deployment

Hi Matt,

In my test case, there are two slpd daemons, one is a DA (net.slp.isDA=true),  and one is SA which statically configured to communicate with DA (set the net.slp.DAAddresses to the DA IP address).

I conducted more tests today with net.slp.DASyncReg = true. Here is the test result:


1)      Start slpd on the DA machine

2)      Start slpad on the SA machine

3)      Run the SA application with SLPReg call

4)      Run slptool findsrvs command, the registered service is found no problem

5)      Shutdown slpd on the DA machine

6)      Run slptool findsrvs command again, the registered service can't found. I think this is OK since there is no DA and my SA is pointing to an invalid DA.

7)      Start slpd on the DA machine again

8)      Run slptool findsrvs command again, the registered service still can't found - I think this is a problem.

Regards,

Ren

From: HIRD Matthew [mailto:Mat...@uk...]<mailto:[mailto:Mat...@uk...]>
Sent: Tuesday, October 23, 2012 5:45 AM
To: Wang, Ren; Nick Wagner
Cc: ope...@li...<mailto:ope...@li...>
Subject: RE: [Openslp-users] DA deployment

Ren

How many SLP daemons are running in your system? Do you actually have an SA running?

cheers
Matt


From: Wang, Ren [mailto:Ren...@nu...]<mailto:[mailto:Ren...@nu...]>
Sent: 22 October 2012 11:53
To: HIRD Matthew; Nick Wagner
Cc: ope...@li...<mailto:ope...@li...>
Subject: RE: [Openslp-users] DA deployment

Hi Matt,

Please see my answers bellow:

when your app runs, does it register and then exit or does it stay running?
It stays running.

do you have the watchPID functionality switched on?
No, it is off

Is the app registering with an SA or with a DA directly?
I have a DA IP address specified, e.g: net.slp.DAAddresses = 10.16.19.20
But, net.slp.DASyncReg is set to false, not sure if it is the issue

Are the SA and the DA using the same scope? Are they just using DEFAULT?
I didn't provide any scope in the conf file, I believe they using the default scope.


Regards,

Ren

From: HIRD Matthew [mailto:Mat...@uk...]<mailto:[mailto:Mat...@uk...]>
Sent: Monday, October 22, 2012 6:46 AM
To: Wang, Ren; Nick Wagner
Cc: ope...@li...<mailto:ope...@li...>
Subject: RE: [Openslp-users] DA deployment

Ren

when your app runs, does it register and then exit or does it stay running? do you have the watchPID functionality switched on?

Is the app registering with an SA or with a DA directly?

Are the SA and the DA using the same scope? Are they just using DEFAULT?

cheers
Matt

Re: [Openslp-users] DA deployment

[Wang, R. <Ren...@nu...>]

Matt,

Thank you so much for your help. Yes, it makes sense.

Ren

From: HIRD Matthew [mailto:Mat...@uk...]
Sent: Wednesday, October 24, 2012 11:36 AM
To: Wang, Ren; Nick Wagner
Cc: ope...@li...
Subject: RE: [Openslp-users] DA deployment

sent again but trimmed to fit within the mailing list size limits. Ren, reply or it will be held for approval on the mailing list.

Ren

when you search, are you using slptool? if so, after step 3 run slptool but with the (I think) -u option to do a unicast search against a particular daemon. I think you might find that your app is using the same slp.conf as the daemon and so registers directly with the DA. ie. the SA is never involved and so has nothing to sync to the DA when it comes back up. Make sense?

cheers
Matt

From: Wang, Ren [mailto:Ren...@nu...]<mailto:[mailto:Ren...@nu...]>
Sent: 23 October 2012 14:36
To: HIRD Matthew; Nick Wagner
Cc: ope...@li...<mailto:ope...@li...>
Subject: RE: [Openslp-users] DA deployment

Hi Matt,

In my test case, there are two slpd daemons, one is a DA (net.slp.isDA=true),  and one is SA which statically configured to communicate with DA (set the net.slp.DAAddresses to the DA IP address).

I conducted more tests today with net.slp.DASyncReg = true. Here is the test result:


1)      Start slpd on the DA machine

2)      Start slpad on the SA machine

3)      Run the SA application with SLPReg call

4)      Run slptool findsrvs command, the registered service is found no problem

5)      Shutdown slpd on the DA machine

6)      Run slptool findsrvs command again, the registered service can't found. I think this is OK since there is no DA and my SA is pointing to an invalid DA.

7)      Start slpd on the DA machine again

8)      Run slptool findsrvs command again, the registered service still can't found - I think this is a problem.

Regards,

Ren

From: HIRD Matthew [mailto:Mat...@uk...]<mailto:[mailto:Mat...@uk...]>
Sent: Tuesday, October 23, 2012 5:45 AM
To: Wang, Ren; Nick Wagner
Cc: ope...@li...<mailto:ope...@li...>
Subject: RE: [Openslp-users] DA deployment

Ren

How many SLP daemons are running in your system? Do you actually have an SA running?

cheers
Matt


From: Wang, Ren [mailto:Ren...@nu...]<mailto:[mailto:Ren...@nu...]>
Sent: 22 October 2012 11:53
To: HIRD Matthew; Nick Wagner
Cc: ope...@li...<mailto:ope...@li...>
Subject: RE: [Openslp-users] DA deployment

Hi Matt,

Please see my answers bellow:

when your app runs, does it register and then exit or does it stay running?
It stays running.

do you have the watchPID functionality switched on?
No, it is off

Is the app registering with an SA or with a DA directly?
I have a DA IP address specified, e.g: net.slp.DAAddresses = 10.16.19.20
But, net.slp.DASyncReg is set to false, not sure if it is the issue

Are the SA and the DA using the same scope? Are they just using DEFAULT?
I didn't provide any scope in the conf file, I believe they using the default scope.


Regards,

Ren

From: HIRD Matthew [mailto:Mat...@uk...]<mailto:[mailto:Mat...@uk...]>
Sent: Monday, October 22, 2012 6:46 AM
To: Wang, Ren; Nick Wagner
Cc: ope...@li...<mailto:ope...@li...>
Subject: RE: [Openslp-users] DA deployment

Ren

when your app runs, does it register and then exit or does it stay running? do you have the watchPID functionality switched on?

Is the app registering with an SA or with a DA directly?

Are the SA and the DA using the same scope? Are they just using DEFAULT?

cheers
Matt

[Openslp-users] AUTO: Devchandra Leishangthem is out of the office (returning 10/29/2012)

[Devchandra L. <del...@in...>]

I am out of the office until 10/29/2012.

For any urgent work please contact Ashok K Pathak or Ajay N Rao


Note: This is an automated response to your message  "Openslp-users Digest,
Vol 35, Issue 10" sent on 24/10/2012 21:06:31.

This is the only notification you will receive while this person is away.

Re: [Openslp-users] DA deployment

[HIRD M. <Mat...@uk...>]

sent again but trimmed to fit within the mailing list size limits. Ren, reply or it will be held for approval on the mailing list.

Ren

when you search, are you using slptool? if so, after step 3 run slptool but with the (I think) -u option to do a unicast search against a particular daemon. I think you might find that your app is using the same slp.conf as the daemon and so registers directly with the DA. ie. the SA is never involved and so has nothing to sync to the DA when it comes back up. Make sense?

cheers
Matt

From: Wang, Ren [mailto:Ren...@nu...]
Sent: 23 October 2012 14:36
To: HIRD Matthew; Nick Wagner
Cc: ope...@li...
Subject: RE: [Openslp-users] DA deployment

Hi Matt,

In my test case, there are two slpd daemons, one is a DA (net.slp.isDA=true),  and one is SA which statically configured to communicate with DA (set the net.slp.DAAddresses to the DA IP address).

I conducted more tests today with net.slp.DASyncReg = true. Here is the test result:


1)      Start slpd on the DA machine

2)      Start slpad on the SA machine

3)      Run the SA application with SLPReg call

4)      Run slptool findsrvs command, the registered service is found no problem

5)      Shutdown slpd on the DA machine

6)      Run slptool findsrvs command again, the registered service can't found. I think this is OK since there is no DA and my SA is pointing to an invalid DA.

7)      Start slpd on the DA machine again

8)      Run slptool findsrvs command again, the registered service still can't found - I think this is a problem.

Regards,

Ren

From: HIRD Matthew [mailto:Mat...@uk...]
Sent: Tuesday, October 23, 2012 5:45 AM
To: Wang, Ren; Nick Wagner
Cc: ope...@li...
Subject: RE: [Openslp-users] DA deployment

Ren

How many SLP daemons are running in your system? Do you actually have an SA running?

cheers
Matt


From: Wang, Ren [mailto:Ren...@nu...]<mailto:[mailto:Ren...@nu...]>
Sent: 22 October 2012 11:53
To: HIRD Matthew; Nick Wagner
Cc: ope...@li...<mailto:ope...@li...>
Subject: RE: [Openslp-users] DA deployment

Hi Matt,

Please see my answers bellow:

when your app runs, does it register and then exit or does it stay running?
It stays running.

do you have the watchPID functionality switched on?
No, it is off

Is the app registering with an SA or with a DA directly?
I have a DA IP address specified, e.g: net.slp.DAAddresses = 10.16.19.20
But, net.slp.DASyncReg is set to false, not sure if it is the issue

Are the SA and the DA using the same scope? Are they just using DEFAULT?
I didn't provide any scope in the conf file, I believe they using the default scope.


Regards,

Ren

From: HIRD Matthew [mailto:Mat...@uk...]<mailto:[mailto:Mat...@uk...]>
Sent: Monday, October 22, 2012 6:46 AM
To: Wang, Ren; Nick Wagner
Cc: ope...@li...<mailto:ope...@li...>
Subject: RE: [Openslp-users] DA deployment

Ren

when your app runs, does it register and then exit or does it stay running? do you have the watchPID functionality switched on?

Is the app registering with an SA or with a DA directly?

Are the SA and the DA using the same scope? Are they just using DEFAULT?

cheers
Matt

[Openslp-users] net.slp.isDABackup

[Wang, R. <Ren...@nu...>]

I started the DA with net.slp.isDABackup set to true, and registered a service from a SA machine. But, I can't see the backup file /etc/slp.reg.d/slpd/DABackup created. The directory /etc/slp.reg.d/slpd has nothing there. What's the correct way to enable DA backup?

Regards,

Ren

[Openslp-users] DASyncReg paramter

[Wang, R. <Ren...@nu...>]

Based on the documentation, the net.slp.DASyncReg parameter can enable slpd to sync service registration between SLP DAs on startup. Is there a way to configure which DA to sync with?

Ren

Re: [Openslp-users] DA deployment

[HIRD M. <Mat...@uk...>]

Ren

How many SLP daemons are running in your system? Do you actually have an SA running?

cheers
Matt


From: Wang, Ren [mailto:Ren...@nu...]
Sent: 22 October 2012 11:53
To: HIRD Matthew; Nick Wagner
Cc: ope...@li...
Subject: RE: [Openslp-users] DA deployment

Hi Matt,

Please see my answers bellow:

when your app runs, does it register and then exit or does it stay running?
It stays running.

do you have the watchPID functionality switched on?
No, it is off

Is the app registering with an SA or with a DA directly?
I have a DA IP address specified, e.g: net.slp.DAAddresses = 10.16.19.20
But, net.slp.DASyncReg is set to false, not sure if it is the issue

Are the SA and the DA using the same scope? Are they just using DEFAULT?
I didn't provide any scope in the conf file, I believe they using the default scope.


Regards,

Ren

From: HIRD Matthew [mailto:Mat...@uk...]
Sent: Monday, October 22, 2012 6:46 AM
To: Wang, Ren; Nick Wagner
Cc: ope...@li...
Subject: RE: [Openslp-users] DA deployment

Ren

when your app runs, does it register and then exit or does it stay running? do you have the watchPID functionality switched on?

Is the app registering with an SA or with a DA directly?

Are the SA and the DA using the same scope? Are they just using DEFAULT?

cheers
Matt


From: Wang, Ren [mailto:Ren...@nu...]<mailto:[mailto:Ren...@nu...]>
Sent: 20 October 2012 21:13
To: Nick Wagner
Cc: ope...@li...<mailto:ope...@li...>
Subject: Re: [Openslp-users] DA deployment

I guess my question should be if SA received DAAdvert message, is there a way to register a callback function to the DAAdvert event so that SA can know the DA is there and register the service to it?

The way as you described "It is the responsibility of the SA to find DA's and keep registering with them" - is it also done by the slpd "automatically"?

We have a test as following:


1)      an application calls OpenSLP SLPReg when it started, the application is a service agent points to a static DA IP address

2)      run slptool findsrvs service:TESTAPP, it shows the application registered with the URL

3)      shut done the DA

4)      restart the DA

5)      run slptool findsrvs service:TESTAPP again, no service found


Based on the test case, "It is the responsibility of the SA to find DA's and keep registering with them", which the application needs to know the DA is up again and re-register it again. And it is not handled by slpd automatically. Is this the correct?

Regards,

Ren

From: nwa...@gm...<mailto:nwa...@gm...> [mailto:nwa...@gm...]<mailto:[mailto:nwa...@gm...]> On Behalf Of Nick Wagner
Sent: Saturday, October 20, 2012 1:05 PM
To: Wang, Ren
Cc: ope...@li...<mailto:ope...@li...>
Subject: Re: [Openslp-users] DA deployment

The library and slpd service handle all of that for you.  There is no need to subscribe directly.
On Sat, Oct 20, 2012 at 8:20 AM, Wang, Ren <Ren...@nu...<mailto:Ren...@nu...>> wrote:
Thank you so much Nick for your answers, very helpful!

Is there a API to let SA to listen to the DAAdvert message? I guess SA must already do it now in OpenSLP, but I can't find a API to subscribe the DAAdvert message.

Ren

From: nwa...@gm...<mailto:nwa...@gm...> [mailto:nwa...@gm...<mailto:nwa...@gm...>] On Behalf Of Nick Wagner
Sent: Friday, October 19, 2012 11:06 AM
To: Wang, Ren
Cc: ope...@li...<mailto:ope...@li...>
Subject: Re: [Openslp-users] DA deployment

It is the responsibility of the SA to find DA's and keep registering with them.  The registrations have an explicit timeout, and if the SA doesn't re-register, the DA assumes they are gone.  For more information of this general sort, RFC 2608 can give a lot of useful information.  http://www.ietf.org/rfc/rfc2608.txt

Of course we'd be happy to answer any subsequent questions.

--Nick
On Fri, Oct 19, 2012 at 9:20 AM, Wang, Ren <Ren...@nu...<mailto:Ren...@nu...>> wrote:
If we have two DAs with the same scope deployed, does the SA registration will populated to both DAs?

If a DA restarted, does SA need to re-register the service to it? Or it will be populated automatically with the information from other DA?

Regards,

Ren

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Openslp-users mailing list
Ope...@li...<mailto:Ope...@li...>
https://lists.sourceforge.net/lists/listinfo/openslp-users

Re: [Openslp-users] DA deployment

[Wang, R. <Ren...@nu...>]

Hi Matt,

Please see my answers bellow:

when your app runs, does it register and then exit or does it stay running?
It stays running.

do you have the watchPID functionality switched on?
No, it is off

Is the app registering with an SA or with a DA directly?
I have a DA IP address specified, e.g: net.slp.DAAddresses = 10.16.19.20
But, net.slp.DASyncReg is set to false, not sure if it is the issue

Are the SA and the DA using the same scope? Are they just using DEFAULT?
I didn't provide any scope in the conf file, I believe they using the default scope.


Regards,

Ren

From: HIRD Matthew [mailto:Mat...@uk...]
Sent: Monday, October 22, 2012 6:46 AM
To: Wang, Ren; Nick Wagner
Cc: ope...@li...
Subject: RE: [Openslp-users] DA deployment

Ren

when your app runs, does it register and then exit or does it stay running? do you have the watchPID functionality switched on?

Is the app registering with an SA or with a DA directly?

Are the SA and the DA using the same scope? Are they just using DEFAULT?

cheers
Matt


From: Wang, Ren [mailto:Ren...@nu...]<mailto:[mailto:Ren...@nu...]>
Sent: 20 October 2012 21:13
To: Nick Wagner
Cc: ope...@li...<mailto:ope...@li...>
Subject: Re: [Openslp-users] DA deployment

I guess my question should be if SA received DAAdvert message, is there a way to register a callback function to the DAAdvert event so that SA can know the DA is there and register the service to it?

The way as you described "It is the responsibility of the SA to find DA's and keep registering with them" - is it also done by the slpd "automatically"?

We have a test as following:


1)      an application calls OpenSLP SLPReg when it started, the application is a service agent points to a static DA IP address

2)      run slptool findsrvs service:TESTAPP, it shows the application registered with the URL

3)      shut done the DA

4)      restart the DA

5)      run slptool findsrvs service:TESTAPP again, no service found


Based on the test case, "It is the responsibility of the SA to find DA's and keep registering with them", which the application needs to know the DA is up again and re-register it again. And it is not handled by slpd automatically. Is this the correct?

Regards,

Ren

From: nwa...@gm...<mailto:nwa...@gm...> [mailto:nwa...@gm...]<mailto:[mailto:nwa...@gm...]> On Behalf Of Nick Wagner
Sent: Saturday, October 20, 2012 1:05 PM
To: Wang, Ren
Cc: ope...@li...<mailto:ope...@li...>
Subject: Re: [Openslp-users] DA deployment

The library and slpd service handle all of that for you.  There is no need to subscribe directly.
On Sat, Oct 20, 2012 at 8:20 AM, Wang, Ren <Ren...@nu...<mailto:Ren...@nu...>> wrote:
Thank you so much Nick for your answers, very helpful!

Is there a API to let SA to listen to the DAAdvert message? I guess SA must already do it now in OpenSLP, but I can't find a API to subscribe the DAAdvert message.

Ren

From: nwa...@gm...<mailto:nwa...@gm...> [mailto:nwa...@gm...<mailto:nwa...@gm...>] On Behalf Of Nick Wagner
Sent: Friday, October 19, 2012 11:06 AM
To: Wang, Ren
Cc: ope...@li...<mailto:ope...@li...>
Subject: Re: [Openslp-users] DA deployment

It is the responsibility of the SA to find DA's and keep registering with them.  The registrations have an explicit timeout, and if the SA doesn't re-register, the DA assumes they are gone.  For more information of this general sort, RFC 2608 can give a lot of useful information.  http://www.ietf.org/rfc/rfc2608.txt

Of course we'd be happy to answer any subsequent questions.

--Nick
On Fri, Oct 19, 2012 at 9:20 AM, Wang, Ren <Ren...@nu...<mailto:Ren...@nu...>> wrote:
If we have two DAs with the same scope deployed, does the SA registration will populated to both DAs?

If a DA restarted, does SA need to re-register the service to it? Or it will be populated automatically with the information from other DA?

Regards,

Ren

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Openslp-users mailing list
Ope...@li...<mailto:Ope...@li...>
https://lists.sourceforge.net/lists/listinfo/openslp-users

Re: [Openslp-users] DA deployment

[HIRD M. <Mat...@uk...>]

Ren

when your app runs, does it register and then exit or does it stay running? do you have the watchPID functionality switched on?

Is the app registering with an SA or with a DA directly?

Are the SA and the DA using the same scope? Are they just using DEFAULT?

cheers
Matt


From: Wang, Ren [mailto:Ren...@nu...]
Sent: 20 October 2012 21:13
To: Nick Wagner
Cc: ope...@li...
Subject: Re: [Openslp-users] DA deployment

I guess my question should be if SA received DAAdvert message, is there a way to register a callback function to the DAAdvert event so that SA can know the DA is there and register the service to it?

The way as you described "It is the responsibility of the SA to find DA's and keep registering with them" - is it also done by the slpd "automatically"?

We have a test as following:


1)      an application calls OpenSLP SLPReg when it started, the application is a service agent points to a static DA IP address

2)      run slptool findsrvs service:TESTAPP, it shows the application registered with the URL

3)      shut done the DA

4)      restart the DA

5)      run slptool findsrvs service:TESTAPP again, no service found


Based on the test case, "It is the responsibility of the SA to find DA's and keep registering with them", which the application needs to know the DA is up again and re-register it again. And it is not handled by slpd automatically. Is this the correct?

Regards,

Ren

From: nwa...@gm... [mailto:nwa...@gm...] On Behalf Of Nick Wagner
Sent: Saturday, October 20, 2012 1:05 PM
To: Wang, Ren
Cc: ope...@li...
Subject: Re: [Openslp-users] DA deployment

The library and slpd service handle all of that for you.  There is no need to subscribe directly.
On Sat, Oct 20, 2012 at 8:20 AM, Wang, Ren <Ren...@nu...<mailto:Ren...@nu...>> wrote:
Thank you so much Nick for your answers, very helpful!

Is there a API to let SA to listen to the DAAdvert message? I guess SA must already do it now in OpenSLP, but I can't find a API to subscribe the DAAdvert message.

Ren

From: nwa...@gm...<mailto:nwa...@gm...> [mailto:nwa...@gm...<mailto:nwa...@gm...>] On Behalf Of Nick Wagner
Sent: Friday, October 19, 2012 11:06 AM
To: Wang, Ren
Cc: ope...@li...<mailto:ope...@li...>
Subject: Re: [Openslp-users] DA deployment

It is the responsibility of the SA to find DA's and keep registering with them.  The registrations have an explicit timeout, and if the SA doesn't re-register, the DA assumes they are gone.  For more information of this general sort, RFC 2608 can give a lot of useful information.  http://www.ietf.org/rfc/rfc2608.txt

Of course we'd be happy to answer any subsequent questions.

--Nick
On Fri, Oct 19, 2012 at 9:20 AM, Wang, Ren <Ren...@nu...<mailto:Ren...@nu...>> wrote:
If we have two DAs with the same scope deployed, does the SA registration will populated to both DAs?

If a DA restarted, does SA need to re-register the service to it? Or it will be populated automatically with the information from other DA?

Regards,

Ren

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Openslp-users mailing list
Ope...@li...<mailto:Ope...@li...>
https://lists.sourceforge.net/lists/listinfo/openslp-users

Re: [Openslp-users] DA deployment

[Wang, R. <Ren...@nu...>]

I guess my question should be if SA received DAAdvert message, is there a way to register a callback function to the DAAdvert event so that SA can know the DA is there and register the service to it?

The way as you described "It is the responsibility of the SA to find DA's and keep registering with them" - is it also done by the slpd "automatically"?

We have a test as following:


1)      an application calls OpenSLP SLPReg when it started, the application is a service agent points to a static DA IP address

2)      run slptool findsrvs service:TESTAPP, it shows the application registered with the URL

3)      shut done the DA

4)      restart the DA

5)      run slptool findsrvs service:TESTAPP again, no service found


Based on the test case, "It is the responsibility of the SA to find DA's and keep registering with them", which the application needs to know the DA is up again and re-register it again. And it is not handled by slpd automatically. Is this the correct?

Regards,

Ren

From: nwa...@gm... [mailto:nwa...@gm...] On Behalf Of Nick Wagner
Sent: Saturday, October 20, 2012 1:05 PM
To: Wang, Ren
Cc: ope...@li...
Subject: Re: [Openslp-users] DA deployment

The library and slpd service handle all of that for you.  There is no need to subscribe directly.
On Sat, Oct 20, 2012 at 8:20 AM, Wang, Ren <Ren...@nu...<mailto:Ren...@nu...>> wrote:
Thank you so much Nick for your answers, very helpful!

Is there a API to let SA to listen to the DAAdvert message? I guess SA must already do it now in OpenSLP, but I can't find a API to subscribe the DAAdvert message.

Ren

From: nwa...@gm...<mailto:nwa...@gm...> [mailto:nwa...@gm...<mailto:nwa...@gm...>] On Behalf Of Nick Wagner
Sent: Friday, October 19, 2012 11:06 AM
To: Wang, Ren
Cc: ope...@li...<mailto:ope...@li...>
Subject: Re: [Openslp-users] DA deployment

It is the responsibility of the SA to find DA's and keep registering with them.  The registrations have an explicit timeout, and if the SA doesn't re-register, the DA assumes they are gone.  For more information of this general sort, RFC 2608 can give a lot of useful information.  http://www.ietf.org/rfc/rfc2608.txt

Of course we'd be happy to answer any subsequent questions.

--Nick
On Fri, Oct 19, 2012 at 9:20 AM, Wang, Ren <Ren...@nu...<mailto:Ren...@nu...>> wrote:
If we have two DAs with the same scope deployed, does the SA registration will populated to both DAs?

If a DA restarted, does SA need to re-register the service to it? Or it will be populated automatically with the information from other DA?

Regards,

Ren

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Openslp-users mailing list
Ope...@li...<mailto:Ope...@li...>
https://lists.sourceforge.net/lists/listinfo/openslp-users

Re: [Openslp-users] DA deployment

[Nick W. <ne...@wi...>]

The library and slpd service handle all of that for you.  There is no need
to subscribe directly.

On Sat, Oct 20, 2012 at 8:20 AM, Wang, Ren <Ren...@nu...> wrote:

>  Thank you so much Nick for your answers, very helpful!****
>
> ** **
>
> Is there a API to let SA to listen to the DAAdvert message? I guess SA
> must already do it now in OpenSLP, but I can’t find a API to subscribe the
> DAAdvert message.****
>
> ** **
>
> Ren****
>
> ** **
>
> *From:* nwa...@gm... [mailto:nwa...@gm...] *On Behalf Of *Nick
> Wagner
> *Sent:* Friday, October 19, 2012 11:06 AM
> *To:* Wang, Ren
> *Cc:* ope...@li...
> *Subject:* Re: [Openslp-users] DA deployment****
>
> ** **
>
> It is the responsibility of the SA to find DA's and keep registering with
> them.  The registrations have an explicit timeout, and if the SA doesn't
> re-register, the DA assumes they are gone.  For more information of this
> general sort, RFC 2608 can give a lot of useful information.
> http://www.ietf.org/rfc/rfc2608.txt ****
>
> ** **
>
> Of course we'd be happy to answer any subsequent questions.****
>
> ** **
>
> --Nick****
>
> On Fri, Oct 19, 2012 at 9:20 AM, Wang, Ren <Ren...@nu...> wrote:***
> *
>
> If we have two DAs with the same scope deployed, does the SA registration
> will populated to both DAs? ****
>
>  ****
>
> If a DA restarted, does SA need to re-register the service to it? Or it
> will be populated automatically with the information from other DA?****
>
>  ****
>
> Regards,****
>
>  ****
>
> Ren****
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> Openslp-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openslp-users****
>
> ** **
>

Re: [Openslp-users] DA deployment

[Wang, R. <Ren...@nu...>]

Thank you so much Nick for your answers, very helpful!

Is there a API to let SA to listen to the DAAdvert message? I guess SA must already do it now in OpenSLP, but I can't find a API to subscribe the DAAdvert message.

Ren

From: nwa...@gm... [mailto:nwa...@gm...] On Behalf Of Nick Wagner
Sent: Friday, October 19, 2012 11:06 AM
To: Wang, Ren
Cc: ope...@li...
Subject: Re: [Openslp-users] DA deployment

It is the responsibility of the SA to find DA's and keep registering with them.  The registrations have an explicit timeout, and if the SA doesn't re-register, the DA assumes they are gone.  For more information of this general sort, RFC 2608 can give a lot of useful information.  http://www.ietf.org/rfc/rfc2608.txt

Of course we'd be happy to answer any subsequent questions.

--Nick
On Fri, Oct 19, 2012 at 9:20 AM, Wang, Ren <Ren...@nu...<mailto:Ren...@nu...>> wrote:
If we have two DAs with the same scope deployed, does the SA registration will populated to both DAs?

If a DA restarted, does SA need to re-register the service to it? Or it will be populated automatically with the information from other DA?

Regards,

Ren

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Openslp-users mailing list
Ope...@li...<mailto:Ope...@li...>
https://lists.sourceforge.net/lists/listinfo/openslp-users

Re: [Openslp-users] scope setting for service registion

[Nick W. <ne...@wi...>]

Offhand, I don't see one.  I've never looked for it before.

--Nick

On Wed, Oct 17, 2012 at 4:40 PM, Wang, Ren <Ren...@nu...> wrote:

>  SLPReg API has no parameter for scope, I guest it will use the slp.conf
> scope setting. Is  there a way to use API to set the scope?****
>
> ** **
>
> Regards,****
>
> ** **
>
> Ren****
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> Openslp-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openslp-users
>
>

Re: [Openslp-users] DA deployment

[Nick W. <ne...@wi...>]

It is the responsibility of the SA to find DA's and keep registering with
them.  The registrations have an explicit timeout, and if the SA doesn't
re-register, the DA assumes they are gone.  For more information of this
general sort, RFC 2608 can give a lot of useful information.
http://www.ietf.org/rfc/rfc2608.txt

Of course we'd be happy to answer any subsequent questions.

--Nick

On Fri, Oct 19, 2012 at 9:20 AM, Wang, Ren <Ren...@nu...> wrote:

>  If we have two DAs with the same scope deployed, does the SA
> registration will populated to both DAs? ****
>
> ** **
>
> If a DA restarted, does SA need to re-register the service to it? Or it
> will be populated automatically with the information from other DA?****
>
> ** **
>
> Regards,****
>
> ** **
>
> Ren****
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> Openslp-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openslp-users
>
>

[Openslp-users] DA deployment

[Wang, R. <Ren...@nu...>]

If we have two DAs with the same scope deployed, does the SA registration will populated to both DAs?

If a DA restarted, does SA need to re-register the service to it? Or it will be populated automatically with the information from other DA?

Regards,

Ren

Re: [Openslp-users] slpd seems to hijack the port I'm using in my application

[Robert H. <rh...@hs...>]

Thank you for the fix. I tried it and it solves my problem :)

As mentioned earlier it would be great if someone could also have a look 
at the Debian related stuff. It looks like the start/stop script needs 
some work and I also did not manage to build the Debian package as 
described in openslp.misc/Readme.debian.

Robert


Am 18.10.2012 03:08, schrieb John Calcote:
> Hi all –
>
> I’ve enhanced the daemonizing code in slpd_main.c – my changes are
> committed in rev 1692. Basically, I moved the call to Daemonize up above
> all the initialization so we don’t open all our socket handles before
> daemonizing – this is generally considered standard procedure.
>
> I then added the loop that Robert wanted that closes the first 8k file
> handles. A better way of doing this is to freopen the standard handles
> to /dev/null so that someone attempting to write to the handle doesn’t
> cause flush to hang on shutdown. Luckily, we don’t use printf in our
> production code, so this isn’t really an issue for slpd.
>
> Finally, I moved the setuid code out of Daemonize into its own routine,
> DropPrivileges, and places a call to that function where the call to
> Daemonize used to be. The reason Daemonize was called so late was so we
> could open our privileged sockets before we drop privs. Another standard
> procedure is to daemonize early and drop privs as soon as we can, but no
> sooner.
>
> I’ve built and tested this code on Ubuntu 12.04. It’s a *nix-only source
> file, so I don’t think these changes will have any effect on Windows,
> but others should give it a try on other Unix platforms. I don’t expect
> any problems, but you never know…
>
> Hope this helps,
>
> John
>
> *From:*Nick Wagner [mailto:ne...@wi...]
> *Sent:* Wednesday, October 17, 2012 9:45 AM
> *To:* Robert Hegner
> *Cc:* ope...@li...;
> ope...@li...
> *Subject:* Re: [Openslp-users] slpd seems to hijack the port I'm using
> in my application
>
> Someone on the devel list with more experience working with linux
> daemons will need to make this fix.  And they should patch the debian
> start-stop script as well as earlier explained in this email chain.  We
> should do this before the code freeze.
>
> Robert, thanks for finding these issues!
>
> --Nick
>
> On Wed, Oct 17, 2012 at 10:30 AM, Robert Hegner
> <rh...@hs...
> <mailto:rh...@hs...>> wrote:
>
> Ok I found out what's wrong. And I would consider this as a bug in OpenSLP.
>
> I'm a Linux newbie but The Linux Programming Interface by Michael
> Kerrisk (a great book, by the way) helped me understand what's going on.
>
> You can see in my first post that when slpd listens to the same port as
> my application, it also uses the same file descriptor.
>
> As I wrote earlier, I use system() to run the start/stop script of slpd.
> According to Kerrisk's book, system() is typically implemented using a
> combination of fork() (which copies all open file descriptors) and
> exec() (which does not close any file descriptors). So slpd inherits my
> open file descriptors when I start it from within my application.
>
> In chapter 37 of his book, Kerrisk also describes the seven steps for
> daemonizing a program. Step 6 is:
> "Close all open file descriptors that the daemon has inherited from its
> parent. (A daemon may need to keep certain inherited file descriptors
> open, [...]"
>
> And he also provides some example code showing how to accomplish this:
>
> maxfd = sysconf(_SC_OPEN_MAX);
> if (maxfd == -1)
>      maxfd = BD_MAX_CLOSE; // 8192 in his example
> for (fd = 0; fd < maxfd; fd++)
>      close(fd);
>
> I had a look at the OpenSLP source code and I found that Daemonize() (in
> slpd_main.c) does not close all open file descriptors (it only closes
> descriptors 0 to 2 under some condition).
>
> I tried to close all file descriptors in Daemonize() but it seemed to
> cause some problems. I guess that slpd has already opened some of its
> own sockets at that time, which are then being closed again.
>
> But adding
>
> for (i = 3; i < 8192; i++)
>      close(i);
>
> at the beginning of main() solves all my problems :)
>
> Something like this should be in Daemonize() and not at the beginning of
> main(), but I guess someone who is familiar with the initialization code
> of slpd should have a look at this.
>
> I hope this change will make it into Release of version 2.0
>
> Robert
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
>
>
>

Re: [Openslp-users] slpd seems to hijack the port I'm using in my application

[John C. <joh...@gm...>]

Hi all - 

 

I've enhanced the daemonizing code in slpd_main.c - my changes are committed
in rev 1692. Basically, I moved the call to Daemonize up above all the
initialization so we don't open all our socket handles before daemonizing -
this is generally considered standard procedure.

 

I then added the loop that Robert wanted that closes the first 8k file
handles. A better way of doing this is to freopen the standard handles to
/dev/null so that someone attempting to write to the handle doesn't cause
flush to hang on shutdown. Luckily, we don't use printf in our production
code, so this isn't really an issue for slpd.

 

Finally, I moved the setuid code out of Daemonize into its own routine,
DropPrivileges, and places a call to that function where the call to
Daemonize used to be. The reason Daemonize was called so late was so we
could open our privileged sockets before we drop privs. Another standard
procedure is to daemonize early and drop privs as soon as we can, but no
sooner.

 

I've built and tested this code on Ubuntu 12.04. It's a *nix-only source
file, so I don't think these changes will have any effect on Windows, but
others should give it a try on other Unix platforms. I don't expect any
problems, but you never know.

 

Hope this helps,

John

 

From: Nick Wagner [mailto:ne...@wi...] 
Sent: Wednesday, October 17, 2012 9:45 AM
To: Robert Hegner
Cc: ope...@li...; ope...@li...
Subject: Re: [Openslp-users] slpd seems to hijack the port I'm using in my
application

 

Someone on the devel list with more experience working with linux daemons
will need to make this fix.  And they should patch the debian start-stop
script as well as earlier explained in this email chain.  We should do this
before the code freeze.

 

Robert, thanks for finding these issues!

 

--Nick

 

On Wed, Oct 17, 2012 at 10:30 AM, Robert Hegner <rh...@hs...> wrote:

Ok I found out what's wrong. And I would consider this as a bug in OpenSLP.

I'm a Linux newbie but The Linux Programming Interface by Michael
Kerrisk (a great book, by the way) helped me understand what's going on.

You can see in my first post that when slpd listens to the same port as
my application, it also uses the same file descriptor.

As I wrote earlier, I use system() to run the start/stop script of slpd.
According to Kerrisk's book, system() is typically implemented using a
combination of fork() (which copies all open file descriptors) and
exec() (which does not close any file descriptors). So slpd inherits my
open file descriptors when I start it from within my application.

In chapter 37 of his book, Kerrisk also describes the seven steps for
daemonizing a program. Step 6 is:
"Close all open file descriptors that the daemon has inherited from its
parent. (A daemon may need to keep certain inherited file descriptors
open, [...]"

And he also provides some example code showing how to accomplish this:

maxfd = sysconf(_SC_OPEN_MAX);
if (maxfd == -1)
    maxfd = BD_MAX_CLOSE; // 8192 in his example
for (fd = 0; fd < maxfd; fd++)
    close(fd);

I had a look at the OpenSLP source code and I found that Daemonize() (in
slpd_main.c) does not close all open file descriptors (it only closes
descriptors 0 to 2 under some condition).

I tried to close all file descriptors in Daemonize() but it seemed to
cause some problems. I guess that slpd has already opened some of its
own sockets at that time, which are then being closed again.

But adding

for (i = 3; i < 8192; i++)
    close(i);

at the beginning of main() solves all my problems :)

Something like this should be in Daemonize() and not at the beginning of
main(), but I guess someone who is familiar with the initialization code
of slpd should have a look at this.

I hope this change will make it into Release of version 2.0

Robert

 

[Openslp-users] scope setting for service registion

[Wang, R. <Ren...@nu...>]

SLPReg API has no parameter for scope, I guest it will use the slp.conf scope setting. Is  there a way to use API to set the scope?

Regards,

Ren

Re: [Openslp-users] slpd seems to hijack the port I'm using in my application

[Nick W. <ne...@wi...>]

Someone on the devel list with more experience working with linux daemons
will need to make this fix.  And they should patch the debian start-stop
script as well as earlier explained in this email chain.  We should do this
before the code freeze.

Robert, thanks for finding these issues!

--Nick

On Wed, Oct 17, 2012 at 10:30 AM, Robert Hegner <rh...@hs...> wrote:

> Ok I found out what's wrong. And I would consider this as a bug in OpenSLP.
>
> I'm a Linux newbie but The Linux Programming Interface by Michael
> Kerrisk (a great book, by the way) helped me understand what's going on.
>
> You can see in my first post that when slpd listens to the same port as
> my application, it also uses the same file descriptor.
>
> As I wrote earlier, I use system() to run the start/stop script of slpd.
> According to Kerrisk's book, system() is typically implemented using a
> combination of fork() (which copies all open file descriptors) and
> exec() (which does not close any file descriptors). So slpd inherits my
> open file descriptors when I start it from within my application.
>
> In chapter 37 of his book, Kerrisk also describes the seven steps for
> daemonizing a program. Step 6 is:
> "Close all open file descriptors that the daemon has inherited from its
> parent. (A daemon may need to keep certain inherited file descriptors
> open, [...]"
>
> And he also provides some example code showing how to accomplish this:
>
> maxfd = sysconf(_SC_OPEN_MAX);
> if (maxfd == -1)
>     maxfd = BD_MAX_CLOSE; // 8192 in his example
> for (fd = 0; fd < maxfd; fd++)
>     close(fd);
>
> I had a look at the OpenSLP source code and I found that Daemonize() (in
> slpd_main.c) does not close all open file descriptors (it only closes
> descriptors 0 to 2 under some condition).
>
> I tried to close all file descriptors in Daemonize() but it seemed to
> cause some problems. I guess that slpd has already opened some of its
> own sockets at that time, which are then being closed again.
>
> But adding
>
> for (i = 3; i < 8192; i++)
>     close(i);
>
> at the beginning of main() solves all my problems :)
>
> Something like this should be in Daemonize() and not at the beginning of
> main(), but I guess someone who is familiar with the initialization code
> of slpd should have a look at this.
>
> I hope this change will make it into Release of version 2.0
>
> Robert
>
>

Re: [Openslp-users] slpd seems to hijack the port I'm using in my application

[Robert H. <rh...@hs...>]

Ok I found out what's wrong. And I would consider this as a bug in OpenSLP.

I'm a Linux newbie but The Linux Programming Interface by Michael 
Kerrisk (a great book, by the way) helped me understand what's going on.

You can see in my first post that when slpd listens to the same port as 
my application, it also uses the same file descriptor.

As I wrote earlier, I use system() to run the start/stop script of slpd. 
According to Kerrisk's book, system() is typically implemented using a 
combination of fork() (which copies all open file descriptors) and 
exec() (which does not close any file descriptors). So slpd inherits my 
open file descriptors when I start it from within my application.

In chapter 37 of his book, Kerrisk also describes the seven steps for 
daemonizing a program. Step 6 is:
"Close all open file descriptors that the daemon has inherited from its 
parent. (A daemon may need to keep certain inherited file descriptors 
open, [...]"

And he also provides some example code showing how to accomplish this:

maxfd = sysconf(_SC_OPEN_MAX);
if (maxfd == -1)
    maxfd = BD_MAX_CLOSE; // 8192 in his example
for (fd = 0; fd < maxfd; fd++)
    close(fd);

I had a look at the OpenSLP source code and I found that Daemonize() (in 
slpd_main.c) does not close all open file descriptors (it only closes 
descriptors 0 to 2 under some condition).

I tried to close all file descriptors in Daemonize() but it seemed to 
cause some problems. I guess that slpd has already opened some of its 
own sockets at that time, which are then being closed again.

But adding

for (i = 3; i < 8192; i++)
    close(i);

at the beginning of main() solves all my problems :)

Something like this should be in Daemonize() and not at the beginning of 
main(), but I guess someone who is familiar with the initialization code 
of slpd should have a look at this.

I hope this change will make it into Release of version 2.0

Robert



Am 16.10.2012 08:59, schrieb Robert Hegner:
> Yes it happens with any port.
>
> I want to try it with version 2.0 but I have some problems getting it to
> work (I'm new to the Linux world...). I managed to build it but I
> couldn't start/stop slpd properly. I'll have a look at this again today.
>
> You might have noticed in the lsof -i listings in my original post that
> the PID of slpd changes. The reason is that my application restarts slpd
> under certain conditions to make sure its service is published on all
> available network interfaces. The application starts and stops slpd by
> calling (as root):
> int ret = system("/bin/sh -e /etc/init.d/slpd stop");
> int ret = system("/bin/sh -e /etc/init.d/slpd start");
>
> Do you think this could cause the problem? Is this the proper way to
> programmatically restart slpd under Linux (Debian)? Under Windows I use
> the scmanager API and it works like a charm (with version 2.0, I've
> never tested it with version 1.x under Windows). I'll try and check how
> version 2.0 behaves in this scenario later today.
>
> Gavin Lambert posted a patch in the developers newsgroup to make slpd
> re-initialize its interfaces by sending it a signal. It would be great
> if some mechanism like this made it into the release version of OpenSLP
> 2.0. In my scenario I would not have to restart spld anymore.
>
> PS: It would make things much easier if version 2.0 came as a prebuilt
> Debian package, so I'm glad to hear that it will soon reach release
> status. Do you think it will make it into Debian Wheezy (which I think
> will soon change from testing to stable)?
>
> Thanks,
> Robert
>
>
> Am 15.10.2012 16:51, schrieb Nick Wagner:
>> If you try some other port, does SLP hijack that too?  We're nearing
>> release on version 2.0, would you like to try that and see if if you
>> have a similar problem?  I don't believe we're doing anything in the
>> current code that would cause that side effect, and 1.2.1 was a long
>> time ago.
>>
>> --Nick
>>
>> On Fri, Oct 12, 2012 at 3:35 AM, Robert Hegner
>> <rh...@hs... <mailto:rh...@hs...>> wrote:
>>
>>      I recently ported my application from Windows to Linux and now I'm
>>      experiencing some strange problem when running it under Debian
>>      together with OpenSLP 1.2.1-9 (this is the version that comes out of
>>      the box with Debian).
>>
>>      The problem is that slpd seems to occupy the port I'm using for my
>>      application. Let me explain...
>>
>>      Before I start my application, "lsof -i" lists the following spld
>>      related entries:
>>
>>      COMMAND    PID        USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
>>      slpd      2786      daemon    4u  IPv4   6415      0t0  TCP
>>      localhost:svrloc (LISTEN)
>>      slpd      2786      daemon    5u  IPv4   6416      0t0  TCP
>>      DebianWheezy.local:svrloc (LISTEN)
>>      slpd      2786      daemon    6u  IPv4   6417      0t0  UDP
>>      239.255.255.253:svrloc
>>      slpd      2786      daemon    7u  IPv4   6418      0t0  UDP
>>      DebianWheezy.local:svrloc
>>      slpd      2786      daemon    8u  IPv4   6419      0t0  TCP
>>      3724G-21104-2.hsr.ch:svrloc (LISTEN)
>>      slpd      2786      daemon    9u  IPv4   6420      0t0  UDP
>>      239.255.255.253:svrloc
>>      slpd      2786      daemon   10u  IPv4   6421      0t0  UDP
>>      3724G-21104-2.hsr.ch:svrloc
>>
>>      Then I start my application which registers the following two
>>      services with SLP:
>>      service:TrackingNode.ADEC:CP://10.0.2.15:1234/1c736ed2-e8b7-545c-998a-2ce095e600ea
>>      <http://10.0.2.15:1234/1c736ed2-e8b7-545c-998a-2ce095e600ea>
>>      service:TrackingNode.ADEC:CP://192.168.0.24:1234/1c736ed2-e8b7-545c-998a-2ce095e600ea
>>      <http://192.168.0.24:1234/1c736ed2-e8b7-545c-998a-2ce095e600ea>
>>
>>      Of course my application opens a socket to listen to port 1234. Now
>>      comes the part that surprised me: slpd also begins to listen to port
>>      1234 (why??). "lsof -i" shows this:
>>
>>      COMMAND    PID        USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
>>      *TrackingN 4795        root    6u  IPv4  12170      0t0 TCP *:1234
>>      (LISTEN)*
>>      TrackingN 4795        root    7u  IPv4  12186      0t0  TCP
>>      localhost:45272->localhost:svrloc (ESTABLISHED)
>>      slpd      4805      daemon    0u  IPv4  12189      0t0  TCP
>>      localhost:svrloc->localhost:45272 (ESTABLISHED)
>>      slpd      4805      daemon    1u  IPv4  12204      0t0  UDP *:37734
>>      slpd      4805      daemon    2u  IPv4  12199      0t0  UDP *:49554
>>      slpd      4805      daemon    4u  IPv4  12176      0t0  TCP
>>      localhost:svrloc (LISTEN)
>>      slpd      4805      daemon    5u  IPv4  12177      0t0  TCP
>>      DebianWheezy.local:svrloc (LISTEN)
>>      *slpd      4805      daemon    6u  IPv4  12170      0t0 TCP *:1234
>>      (LISTEN)*
>>      slpd      4805      daemon    7u  IPv4  12178      0t0  UDP
>>      239.255.255.253:svrloc
>>      slpd      4805      daemon    8u  IPv4  12179      0t0  UDP
>>      DebianWheezy.local:svrloc
>>      slpd      4805      daemon    9u  IPv4  12180      0t0  TCP
>>      3724G-21104-2.hsr.ch:svrloc (LISTEN)
>>      slpd      4805      daemon   10u  IPv4  12181      0t0  UDP
>>      239.255.255.253:svrloc
>>      slpd      4805      daemon   11u  IPv4  12182      0t0  UDP
>>      3724G-21104-2.hsr.ch:svrloc
>>
>>      And then, when I quit my application, slpd keeps listening on port 1234:
>>
>>      COMMAND    PID        USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
>>      slpd      4816      daemon    4u  IPv4  12317      0t0  TCP
>>      localhost:svrloc (LISTEN)
>>      slpd      4816      daemon    5u  IPv4  12318      0t0  TCP
>>      DebianWheezy.local:svrloc (LISTEN)
>>      *slpd      4816      daemon    6u  IPv4  12170      0t0 TCP *:1234
>>      (LISTEN)*
>>      slpd      4816      daemon    7u  IPv4  12319      0t0  UDP
>>      239.255.255.253:svrloc
>>      slpd      4816      daemon    8u  IPv4  12320      0t0  UDP
>>      DebianWheezy.local:svrloc
>>      slpd      4816      daemon    9u  IPv4  12321      0t0  TCP
>>      3724G-21104-2.hsr.ch:svrloc (LISTEN)
>>      slpd      4816      daemon   10u  IPv4  12322      0t0  UDP
>>      239.255.255.253:svrloc
>>      slpd      4816      daemon   11u  IPv4  12323      0t0  UDP
>>      3724G-21104-2.hsr.ch:svrloc
>>      slpd      4816      daemon   13u  IPv4  12326      0t0  UDP *:47496
>>
>>      Now when I restart my application and it tries to open a socket to
>>      listen to port 1234 again, I get an "Address already in use" error,
>>      since slpd still occupies that port.
>>
>>      Can anyone explain what's happening here? Why does slpd hijack my port?
>>
>>      ------------------------------------------------------------------------------
>>      Don't let slow site performance ruin your business. Deploy New Relic APM
>>      Deploy New Relic app performance management and know exactly
>>      what is happening inside your Ruby, Python, PHP, Java, and .NET app
>>      Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>>      http://p.sf.net/sfu/newrelic-dev2dev
>>      _______________________________________________
>>      Openslp-users mailing list
>>      Ope...@li...
>>      <mailto:Ope...@li...>
>>      https://lists.sourceforge.net/lists/listinfo/openslp-users
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Don't let slow site performance ruin your business. Deploy New Relic APM
>> Deploy New Relic app performance management and know exactly
>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>> http://p.sf.net/sfu/newrelic-dev2dev
>>
>>
>>
>> _______________________________________________
>> Openslp-users mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/openslp-users
>>
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
>

Re: [Openslp-users] slpd seems to hijack the port I'm using in my application

[Nick W. <ne...@wi...>]

What does your slpd.log show?

On Wed, Oct 17, 2012 at 5:50 AM, Robert Hegner <rh...@hs...> wrote:

> Ok I managed to setup the latest SVN revision of OpenSLP now. I had to
> modify the start script a little bit, like this:
>
>      start-stop-daemon --pidfile /var/run/$NAME.pid \
>          --exec $DAEMON --start -- -p /var/run/$NAME.pid
>
> Now the bad news is that I'm experiencing exactly the same port
> hijacking behaviour as before :(
>
>
>
> Am 16.10.2012 08:59, schrieb Robert Hegner:
> > Yes it happens with any port.
> >
> > I want to try it with version 2.0 but I have some problems getting it to
> > work (I'm new to the Linux world...). I managed to build it but I
> > couldn't start/stop slpd properly. I'll have a look at this again today.
> >
> > You might have noticed in the lsof -i listings in my original post that
> > the PID of slpd changes. The reason is that my application restarts slpd
> > under certain conditions to make sure its service is published on all
> > available network interfaces. The application starts and stops slpd by
> > calling (as root):
> > int ret = system("/bin/sh -e /etc/init.d/slpd stop");
> > int ret = system("/bin/sh -e /etc/init.d/slpd start");
> >
> > Do you think this could cause the problem? Is this the proper way to
> > programmatically restart slpd under Linux (Debian)? Under Windows I use
> > the scmanager API and it works like a charm (with version 2.0, I've
> > never tested it with version 1.x under Windows). I'll try and check how
> > version 2.0 behaves in this scenario later today.
> >
> > Gavin Lambert posted a patch in the developers newsgroup to make slpd
> > re-initialize its interfaces by sending it a signal. It would be great
> > if some mechanism like this made it into the release version of OpenSLP
> > 2.0. In my scenario I would not have to restart spld anymore.
> >
> > PS: It would make things much easier if version 2.0 came as a prebuilt
> > Debian package, so I'm glad to hear that it will soon reach release
> > status. Do you think it will make it into Debian Wheezy (which I think
> > will soon change from testing to stable)?
> >
> > Thanks,
> > Robert
> >
> >
> > Am 15.10.2012 16:51, schrieb Nick Wagner:
> >> If you try some other port, does SLP hijack that too?  We're nearing
> >> release on version 2.0, would you like to try that and see if if you
> >> have a similar problem?  I don't believe we're doing anything in the
> >> current code that would cause that side effect, and 1.2.1 was a long
> >> time ago.
> >>
> >> --Nick
> >>
> >> On Fri, Oct 12, 2012 at 3:35 AM, Robert Hegner
> >> <rh...@hs... <mailto:rh...@hs...>> wrote:
> >>
> >>      I recently ported my application from Windows to Linux and now I'm
> >>      experiencing some strange problem when running it under Debian
> >>      together with OpenSLP 1.2.1-9 (this is the version that comes out
> of
> >>      the box with Debian).
> >>
> >>      The problem is that slpd seems to occupy the port I'm using for my
> >>      application. Let me explain...
> >>
> >>      Before I start my application, "lsof -i" lists the following spld
> >>      related entries:
> >>
> >>      COMMAND    PID        USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
> >>      slpd      2786      daemon    4u  IPv4   6415      0t0  TCP
> >>      localhost:svrloc (LISTEN)
> >>      slpd      2786      daemon    5u  IPv4   6416      0t0  TCP
> >>      DebianWheezy.local:svrloc (LISTEN)
> >>      slpd      2786      daemon    6u  IPv4   6417      0t0  UDP
> >>      239.255.255.253:svrloc
> >>      slpd      2786      daemon    7u  IPv4   6418      0t0  UDP
> >>      DebianWheezy.local:svrloc
> >>      slpd      2786      daemon    8u  IPv4   6419      0t0  TCP
> >>      3724G-21104-2.hsr.ch:svrloc (LISTEN)
> >>      slpd      2786      daemon    9u  IPv4   6420      0t0  UDP
> >>      239.255.255.253:svrloc
> >>      slpd      2786      daemon   10u  IPv4   6421      0t0  UDP
> >>      3724G-21104-2.hsr.ch:svrloc
> >>
> >>      Then I start my application which registers the following two
> >>      services with SLP:
> >>      service:TrackingNode.ADEC:CP://
> 10.0.2.15:1234/1c736ed2-e8b7-545c-998a-2ce095e600ea
> >>      <http://10.0.2.15:1234/1c736ed2-e8b7-545c-998a-2ce095e600ea>
> >>      service:TrackingNode.ADEC:CP://
> 192.168.0.24:1234/1c736ed2-e8b7-545c-998a-2ce095e600ea
> >>      <http://192.168.0.24:1234/1c736ed2-e8b7-545c-998a-2ce095e600ea>
> >>
> >>      Of course my application opens a socket to listen to port 1234. Now
> >>      comes the part that surprised me: slpd also begins to listen to
> port
> >>      1234 (why??). "lsof -i" shows this:
> >>
> >>      COMMAND    PID        USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
> >>      *TrackingN 4795        root    6u  IPv4  12170      0t0 TCP *:1234
> >>      (LISTEN)*
> >>      TrackingN 4795        root    7u  IPv4  12186      0t0  TCP
> >>      localhost:45272->localhost:svrloc (ESTABLISHED)
> >>      slpd      4805      daemon    0u  IPv4  12189      0t0  TCP
> >>      localhost:svrloc->localhost:45272 (ESTABLISHED)
> >>      slpd      4805      daemon    1u  IPv4  12204      0t0  UDP *:37734
> >>      slpd      4805      daemon    2u  IPv4  12199      0t0  UDP *:49554
> >>      slpd      4805      daemon    4u  IPv4  12176      0t0  TCP
> >>      localhost:svrloc (LISTEN)
> >>      slpd      4805      daemon    5u  IPv4  12177      0t0  TCP
> >>      DebianWheezy.local:svrloc (LISTEN)
> >>      *slpd      4805      daemon    6u  IPv4  12170      0t0 TCP *:1234
> >>      (LISTEN)*
> >>      slpd      4805      daemon    7u  IPv4  12178      0t0  UDP
> >>      239.255.255.253:svrloc
> >>      slpd      4805      daemon    8u  IPv4  12179      0t0  UDP
> >>      DebianWheezy.local:svrloc
> >>      slpd      4805      daemon    9u  IPv4  12180      0t0  TCP
> >>      3724G-21104-2.hsr.ch:svrloc (LISTEN)
> >>      slpd      4805      daemon   10u  IPv4  12181      0t0  UDP
> >>      239.255.255.253:svrloc
> >>      slpd      4805      daemon   11u  IPv4  12182      0t0  UDP
> >>      3724G-21104-2.hsr.ch:svrloc
> >>
> >>      And then, when I quit my application, slpd keeps listening on port
> 1234:
> >>
> >>      COMMAND    PID        USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
> >>      slpd      4816      daemon    4u  IPv4  12317      0t0  TCP
> >>      localhost:svrloc (LISTEN)
> >>      slpd      4816      daemon    5u  IPv4  12318      0t0  TCP
> >>      DebianWheezy.local:svrloc (LISTEN)
> >>      *slpd      4816      daemon    6u  IPv4  12170      0t0 TCP *:1234
> >>      (LISTEN)*
> >>      slpd      4816      daemon    7u  IPv4  12319      0t0  UDP
> >>      239.255.255.253:svrloc
> >>      slpd      4816      daemon    8u  IPv4  12320      0t0  UDP
> >>      DebianWheezy.local:svrloc
> >>      slpd      4816      daemon    9u  IPv4  12321      0t0  TCP
> >>      3724G-21104-2.hsr.ch:svrloc (LISTEN)
> >>      slpd      4816      daemon   10u  IPv4  12322      0t0  UDP
> >>      239.255.255.253:svrloc
> >>      slpd      4816      daemon   11u  IPv4  12323      0t0  UDP
> >>      3724G-21104-2.hsr.ch:svrloc
> >>      slpd      4816      daemon   13u  IPv4  12326      0t0  UDP *:47496
> >>
> >>      Now when I restart my application and it tries to open a socket to
> >>      listen to port 1234 again, I get an "Address already in use" error,
> >>      since slpd still occupies that port.
> >>
> >>      Can anyone explain what's happening here? Why does slpd hijack my
> port?
> >>
> >>
>  ------------------------------------------------------------------------------
> >>      Don't let slow site performance ruin your business. Deploy New
> Relic APM
> >>      Deploy New Relic app performance management and know exactly
> >>      what is happening inside your Ruby, Python, PHP, Java, and .NET app
> >>      Try New Relic at no cost today and get our sweet Data Nerd shirt
> too!
> >>      http://p.sf.net/sfu/newrelic-dev2dev
> >>      _______________________________________________
> >>      Openslp-users mailing list
> >>      Ope...@li...
> >>      <mailto:Ope...@li...>
> >>      https://lists.sourceforge.net/lists/listinfo/openslp-users
> >>
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Don't let slow site performance ruin your business. Deploy New Relic APM
> >> Deploy New Relic app performance management and know exactly
> >> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> >> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> >> http://p.sf.net/sfu/newrelic-dev2dev
> >>
> >>
> >>
> >> _______________________________________________
> >> Openslp-users mailing list
> >> Ope...@li...
> >> https://lists.sourceforge.net/lists/listinfo/openslp-users
> >>
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Don't let slow site performance ruin your business. Deploy New Relic APM
> > Deploy New Relic app performance management and know exactly
> > what is happening inside your Ruby, Python, PHP, Java, and .NET app
> > Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> > http://p.sf.net/sfu/newrelic-dev2dev
> >
>
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> Openslp-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openslp-users
>

Re: [Openslp-users] slpd seems to hijack the port I'm using in my application

[Robert H. <rh...@hs...>]

Ok I managed to setup the latest SVN revision of OpenSLP now. I had to 
modify the start script a little bit, like this:

     start-stop-daemon --pidfile /var/run/$NAME.pid \
         --exec $DAEMON --start -- -p /var/run/$NAME.pid

Now the bad news is that I'm experiencing exactly the same port 
hijacking behaviour as before :(



Am 16.10.2012 08:59, schrieb Robert Hegner:
> Yes it happens with any port.
>
> I want to try it with version 2.0 but I have some problems getting it to
> work (I'm new to the Linux world...). I managed to build it but I
> couldn't start/stop slpd properly. I'll have a look at this again today.
>
> You might have noticed in the lsof -i listings in my original post that
> the PID of slpd changes. The reason is that my application restarts slpd
> under certain conditions to make sure its service is published on all
> available network interfaces. The application starts and stops slpd by
> calling (as root):
> int ret = system("/bin/sh -e /etc/init.d/slpd stop");
> int ret = system("/bin/sh -e /etc/init.d/slpd start");
>
> Do you think this could cause the problem? Is this the proper way to
> programmatically restart slpd under Linux (Debian)? Under Windows I use
> the scmanager API and it works like a charm (with version 2.0, I've
> never tested it with version 1.x under Windows). I'll try and check how
> version 2.0 behaves in this scenario later today.
>
> Gavin Lambert posted a patch in the developers newsgroup to make slpd
> re-initialize its interfaces by sending it a signal. It would be great
> if some mechanism like this made it into the release version of OpenSLP
> 2.0. In my scenario I would not have to restart spld anymore.
>
> PS: It would make things much easier if version 2.0 came as a prebuilt
> Debian package, so I'm glad to hear that it will soon reach release
> status. Do you think it will make it into Debian Wheezy (which I think
> will soon change from testing to stable)?
>
> Thanks,
> Robert
>
>
> Am 15.10.2012 16:51, schrieb Nick Wagner:
>> If you try some other port, does SLP hijack that too?  We're nearing
>> release on version 2.0, would you like to try that and see if if you
>> have a similar problem?  I don't believe we're doing anything in the
>> current code that would cause that side effect, and 1.2.1 was a long
>> time ago.
>>
>> --Nick
>>
>> On Fri, Oct 12, 2012 at 3:35 AM, Robert Hegner
>> <rh...@hs... <mailto:rh...@hs...>> wrote:
>>
>>      I recently ported my application from Windows to Linux and now I'm
>>      experiencing some strange problem when running it under Debian
>>      together with OpenSLP 1.2.1-9 (this is the version that comes out of
>>      the box with Debian).
>>
>>      The problem is that slpd seems to occupy the port I'm using for my
>>      application. Let me explain...
>>
>>      Before I start my application, "lsof -i" lists the following spld
>>      related entries:
>>
>>      COMMAND    PID        USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
>>      slpd      2786      daemon    4u  IPv4   6415      0t0  TCP
>>      localhost:svrloc (LISTEN)
>>      slpd      2786      daemon    5u  IPv4   6416      0t0  TCP
>>      DebianWheezy.local:svrloc (LISTEN)
>>      slpd      2786      daemon    6u  IPv4   6417      0t0  UDP
>>      239.255.255.253:svrloc
>>      slpd      2786      daemon    7u  IPv4   6418      0t0  UDP
>>      DebianWheezy.local:svrloc
>>      slpd      2786      daemon    8u  IPv4   6419      0t0  TCP
>>      3724G-21104-2.hsr.ch:svrloc (LISTEN)
>>      slpd      2786      daemon    9u  IPv4   6420      0t0  UDP
>>      239.255.255.253:svrloc
>>      slpd      2786      daemon   10u  IPv4   6421      0t0  UDP
>>      3724G-21104-2.hsr.ch:svrloc
>>
>>      Then I start my application which registers the following two
>>      services with SLP:
>>      service:TrackingNode.ADEC:CP://10.0.2.15:1234/1c736ed2-e8b7-545c-998a-2ce095e600ea
>>      <http://10.0.2.15:1234/1c736ed2-e8b7-545c-998a-2ce095e600ea>
>>      service:TrackingNode.ADEC:CP://192.168.0.24:1234/1c736ed2-e8b7-545c-998a-2ce095e600ea
>>      <http://192.168.0.24:1234/1c736ed2-e8b7-545c-998a-2ce095e600ea>
>>
>>      Of course my application opens a socket to listen to port 1234. Now
>>      comes the part that surprised me: slpd also begins to listen to port
>>      1234 (why??). "lsof -i" shows this:
>>
>>      COMMAND    PID        USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
>>      *TrackingN 4795        root    6u  IPv4  12170      0t0 TCP *:1234
>>      (LISTEN)*
>>      TrackingN 4795        root    7u  IPv4  12186      0t0  TCP
>>      localhost:45272->localhost:svrloc (ESTABLISHED)
>>      slpd      4805      daemon    0u  IPv4  12189      0t0  TCP
>>      localhost:svrloc->localhost:45272 (ESTABLISHED)
>>      slpd      4805      daemon    1u  IPv4  12204      0t0  UDP *:37734
>>      slpd      4805      daemon    2u  IPv4  12199      0t0  UDP *:49554
>>      slpd      4805      daemon    4u  IPv4  12176      0t0  TCP
>>      localhost:svrloc (LISTEN)
>>      slpd      4805      daemon    5u  IPv4  12177      0t0  TCP
>>      DebianWheezy.local:svrloc (LISTEN)
>>      *slpd      4805      daemon    6u  IPv4  12170      0t0 TCP *:1234
>>      (LISTEN)*
>>      slpd      4805      daemon    7u  IPv4  12178      0t0  UDP
>>      239.255.255.253:svrloc
>>      slpd      4805      daemon    8u  IPv4  12179      0t0  UDP
>>      DebianWheezy.local:svrloc
>>      slpd      4805      daemon    9u  IPv4  12180      0t0  TCP
>>      3724G-21104-2.hsr.ch:svrloc (LISTEN)
>>      slpd      4805      daemon   10u  IPv4  12181      0t0  UDP
>>      239.255.255.253:svrloc
>>      slpd      4805      daemon   11u  IPv4  12182      0t0  UDP
>>      3724G-21104-2.hsr.ch:svrloc
>>
>>      And then, when I quit my application, slpd keeps listening on port 1234:
>>
>>      COMMAND    PID        USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
>>      slpd      4816      daemon    4u  IPv4  12317      0t0  TCP
>>      localhost:svrloc (LISTEN)
>>      slpd      4816      daemon    5u  IPv4  12318      0t0  TCP
>>      DebianWheezy.local:svrloc (LISTEN)
>>      *slpd      4816      daemon    6u  IPv4  12170      0t0 TCP *:1234
>>      (LISTEN)*
>>      slpd      4816      daemon    7u  IPv4  12319      0t0  UDP
>>      239.255.255.253:svrloc
>>      slpd      4816      daemon    8u  IPv4  12320      0t0  UDP
>>      DebianWheezy.local:svrloc
>>      slpd      4816      daemon    9u  IPv4  12321      0t0  TCP
>>      3724G-21104-2.hsr.ch:svrloc (LISTEN)
>>      slpd      4816      daemon   10u  IPv4  12322      0t0  UDP
>>      239.255.255.253:svrloc
>>      slpd      4816      daemon   11u  IPv4  12323      0t0  UDP
>>      3724G-21104-2.hsr.ch:svrloc
>>      slpd      4816      daemon   13u  IPv4  12326      0t0  UDP *:47496
>>
>>      Now when I restart my application and it tries to open a socket to
>>      listen to port 1234 again, I get an "Address already in use" error,
>>      since slpd still occupies that port.
>>
>>      Can anyone explain what's happening here? Why does slpd hijack my port?
>>
>>      ------------------------------------------------------------------------------
>>      Don't let slow site performance ruin your business. Deploy New Relic APM
>>      Deploy New Relic app performance management and know exactly
>>      what is happening inside your Ruby, Python, PHP, Java, and .NET app
>>      Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>>      http://p.sf.net/sfu/newrelic-dev2dev
>>      _______________________________________________
>>      Openslp-users mailing list
>>      Ope...@li...
>>      <mailto:Ope...@li...>
>>      https://lists.sourceforge.net/lists/listinfo/openslp-users
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Don't let slow site performance ruin your business. Deploy New Relic APM
>> Deploy New Relic app performance management and know exactly
>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>> http://p.sf.net/sfu/newrelic-dev2dev
>>
>>
>>
>> _______________________________________________
>> Openslp-users mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/openslp-users
>>
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
>

Re: [Openslp-users] slpd seems to hijack the port I'm using in my application

[Nick W. <ne...@wi...>]

Is the pid file being created in /usr/local/var/run?  Otherwise, you should
be able to use the -p option to specify its location.

Since you can make it run, does the problem occur?

--Nick


On Tue, Oct 16, 2012 at 4:30 AM, Robert Hegner <rh...@hs...> wrote:

> I tried to check if I can reproduce the problem described in my original
> post with the latest SVN revision of OpenSLP. But I just can't install
> it properly (on Debian). Here is what I tried:
>
> 1) run "./autogen.sh"
> 2) run "./configure --enable-static=yes --enable-shared=no --prefix=/usr"
> 3) run "make"
> 4) run "make install"
> 5) step 4 does not create the start-stop-script in /etc/init.d, but I
> found the script in  ../openslp.misc/debian/init.d. I copied that as
> slpd to /etc/init.d and set the execution flag.
>
> Now it looks like I can start slpd by running "/etc/init.d/slpd start".
> It shows up in the list of running processes afterwards. But running
> "/etc/init.d/slpd stop" does not stop the process, it keeps running. I
> guess the problem is related to the PID file (/var/run/slpd.pid is not
> being created). What am I doing wrong?
>
> I also tried to create the Debian package as described in
> ../openslp.misc/Readme.debain but that doesn't work either (some
> documentation files are missing). I guess these scripts are for building
> the 1.2 release package and they don't work with version 2.0 anymore.
>
> Any help on getting this to work is appreciated!
>
> Robert
>
>
>
> Am 15.10.2012 16:51, schrieb Nick Wagner:
> > If you try some other port, does SLP hijack that too?  We're nearing
> > release on version 2.0, would you like to try that and see if if you
> > have a similar problem?  I don't believe we're doing anything in the
> > current code that would cause that side effect, and 1.2.1 was a long
> > time ago.
> >
> > --Nick
> >
> > On Fri, Oct 12, 2012 at 3:35 AM, Robert Hegner
> > <rh...@hs... <mailto:rh...@hs...>> wrote:
> >
> >     I recently ported my application from Windows to Linux and now I'm
> >     experiencing some strange problem when running it under Debian
> >     together with OpenSLP 1.2.1-9 (this is the version that comes out of
> >     the box with Debian).
> >
> >     The problem is that slpd seems to occupy the port I'm using for my
> >     application. Let me explain...
> >
> >     Before I start my application, "lsof -i" lists the following spld
> >     related entries:
> >
> >     COMMAND    PID        USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
> >     slpd      2786      daemon    4u  IPv4   6415      0t0  TCP
> >     localhost:svrloc (LISTEN)
> >     slpd      2786      daemon    5u  IPv4   6416      0t0  TCP
> >     DebianWheezy.local:svrloc (LISTEN)
> >     slpd      2786      daemon    6u  IPv4   6417      0t0  UDP
> >     239.255.255.253:svrloc
> >     slpd      2786      daemon    7u  IPv4   6418      0t0  UDP
> >     DebianWheezy.local:svrloc
> >     slpd      2786      daemon    8u  IPv4   6419      0t0  TCP
> >     3724G-21104-2.hsr.ch:svrloc (LISTEN)
> >     slpd      2786      daemon    9u  IPv4   6420      0t0  UDP
> >     239.255.255.253:svrloc
> >     slpd      2786      daemon   10u  IPv4   6421      0t0  UDP
> >     3724G-21104-2.hsr.ch:svrloc
> >
> >     Then I start my application which registers the following two
> >     services with SLP:
> >     service:TrackingNode.ADEC:CP://
> 10.0.2.15:1234/1c736ed2-e8b7-545c-998a-2ce095e600ea
> >     <http://10.0.2.15:1234/1c736ed2-e8b7-545c-998a-2ce095e600ea>
> >     service:TrackingNode.ADEC:CP://
> 192.168.0.24:1234/1c736ed2-e8b7-545c-998a-2ce095e600ea
> >     <http://192.168.0.24:1234/1c736ed2-e8b7-545c-998a-2ce095e600ea>
> >
> >     Of course my application opens a socket to listen to port 1234. Now
> >     comes the part that surprised me: slpd also begins to listen to port
> >     1234 (why??). "lsof -i" shows this:
> >
> >     COMMAND    PID        USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
> >     *TrackingN 4795        root    6u  IPv4  12170      0t0 TCP *:1234
> >     (LISTEN)*
> >     TrackingN 4795        root    7u  IPv4  12186      0t0  TCP
> >     localhost:45272->localhost:svrloc (ESTABLISHED)
> >     slpd      4805      daemon    0u  IPv4  12189      0t0  TCP
> >     localhost:svrloc->localhost:45272 (ESTABLISHED)
> >     slpd      4805      daemon    1u  IPv4  12204      0t0  UDP *:37734
> >     slpd      4805      daemon    2u  IPv4  12199      0t0  UDP *:49554
> >     slpd      4805      daemon    4u  IPv4  12176      0t0  TCP
> >     localhost:svrloc (LISTEN)
> >     slpd      4805      daemon    5u  IPv4  12177      0t0  TCP
> >     DebianWheezy.local:svrloc (LISTEN)
> >     *slpd      4805      daemon    6u  IPv4  12170      0t0 TCP *:1234
> >     (LISTEN)*
> >     slpd      4805      daemon    7u  IPv4  12178      0t0  UDP
> >     239.255.255.253:svrloc
> >     slpd      4805      daemon    8u  IPv4  12179      0t0  UDP
> >     DebianWheezy.local:svrloc
> >     slpd      4805      daemon    9u  IPv4  12180      0t0  TCP
> >     3724G-21104-2.hsr.ch:svrloc (LISTEN)
> >     slpd      4805      daemon   10u  IPv4  12181      0t0  UDP
> >     239.255.255.253:svrloc
> >     slpd      4805      daemon   11u  IPv4  12182      0t0  UDP
> >     3724G-21104-2.hsr.ch:svrloc
> >
> >     And then, when I quit my application, slpd keeps listening on port
> 1234:
> >
> >     COMMAND    PID        USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
> >     slpd      4816      daemon    4u  IPv4  12317      0t0  TCP
> >     localhost:svrloc (LISTEN)
> >     slpd      4816      daemon    5u  IPv4  12318      0t0  TCP
> >     DebianWheezy.local:svrloc (LISTEN)
> >     *slpd      4816      daemon    6u  IPv4  12170      0t0 TCP *:1234
> >     (LISTEN)*
> >     slpd      4816      daemon    7u  IPv4  12319      0t0  UDP
> >     239.255.255.253:svrloc
> >     slpd      4816      daemon    8u  IPv4  12320      0t0  UDP
> >     DebianWheezy.local:svrloc
> >     slpd      4816      daemon    9u  IPv4  12321      0t0  TCP
> >     3724G-21104-2.hsr.ch:svrloc (LISTEN)
> >     slpd      4816      daemon   10u  IPv4  12322      0t0  UDP
> >     239.255.255.253:svrloc
> >     slpd      4816      daemon   11u  IPv4  12323      0t0  UDP
> >     3724G-21104-2.hsr.ch:svrloc
> >     slpd      4816      daemon   13u  IPv4  12326      0t0  UDP *:47496
> >
> >     Now when I restart my application and it tries to open a socket to
> >     listen to port 1234 again, I get an "Address already in use" error,
> >     since slpd still occupies that port.
> >
> >     Can anyone explain what's happening here? Why does slpd hijack my
> port?
> >
> >
> ------------------------------------------------------------------------------
> >     Don't let slow site performance ruin your business. Deploy New Relic
> APM
> >     Deploy New Relic app performance management and know exactly
> >     what is happening inside your Ruby, Python, PHP, Java, and .NET app
> >     Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> >     http://p.sf.net/sfu/newrelic-dev2dev
> >     _______________________________________________
> >     Openslp-users mailing list
> >     Ope...@li...
> >     <mailto:Ope...@li...>
> >     https://lists.sourceforge.net/lists/listinfo/openslp-users
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Don't let slow site performance ruin your business. Deploy New Relic APM
> > Deploy New Relic app performance management and know exactly
> > what is happening inside your Ruby, Python, PHP, Java, and .NET app
> > Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> > http://p.sf.net/sfu/newrelic-dev2dev
> >
> >
> >
> > _______________________________________________
> > Openslp-users mailing list
> > Ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/openslp-users
> >
>
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Openslp-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openslp-users
>

Re: [Openslp-users] slpd seems to hijack the port I'm using in my application

[Robert H. <rh...@hs...>]

I tried to check if I can reproduce the problem described in my original 
post with the latest SVN revision of OpenSLP. But I just can't install 
it properly (on Debian). Here is what I tried:

1) run "./autogen.sh"
2) run "./configure --enable-static=yes --enable-shared=no --prefix=/usr"
3) run "make"
4) run "make install"
5) step 4 does not create the start-stop-script in /etc/init.d, but I 
found the script in  ../openslp.misc/debian/init.d. I copied that as 
slpd to /etc/init.d and set the execution flag.

Now it looks like I can start slpd by running "/etc/init.d/slpd start". 
It shows up in the list of running processes afterwards. But running 
"/etc/init.d/slpd stop" does not stop the process, it keeps running. I 
guess the problem is related to the PID file (/var/run/slpd.pid is not 
being created). What am I doing wrong?

I also tried to create the Debian package as described in 
../openslp.misc/Readme.debain but that doesn't work either (some 
documentation files are missing). I guess these scripts are for building 
the 1.2 release package and they don't work with version 2.0 anymore.

Any help on getting this to work is appreciated!

Robert



Am 15.10.2012 16:51, schrieb Nick Wagner:
> If you try some other port, does SLP hijack that too?  We're nearing
> release on version 2.0, would you like to try that and see if if you
> have a similar problem?  I don't believe we're doing anything in the
> current code that would cause that side effect, and 1.2.1 was a long
> time ago.
>
> --Nick
>
> On Fri, Oct 12, 2012 at 3:35 AM, Robert Hegner
> <rh...@hs... <mailto:rh...@hs...>> wrote:
>
>     I recently ported my application from Windows to Linux and now I'm
>     experiencing some strange problem when running it under Debian
>     together with OpenSLP 1.2.1-9 (this is the version that comes out of
>     the box with Debian).
>
>     The problem is that slpd seems to occupy the port I'm using for my
>     application. Let me explain...
>
>     Before I start my application, "lsof -i" lists the following spld
>     related entries:
>
>     COMMAND    PID        USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
>     slpd      2786      daemon    4u  IPv4   6415      0t0  TCP
>     localhost:svrloc (LISTEN)
>     slpd      2786      daemon    5u  IPv4   6416      0t0  TCP
>     DebianWheezy.local:svrloc (LISTEN)
>     slpd      2786      daemon    6u  IPv4   6417      0t0  UDP
>     239.255.255.253:svrloc
>     slpd      2786      daemon    7u  IPv4   6418      0t0  UDP
>     DebianWheezy.local:svrloc
>     slpd      2786      daemon    8u  IPv4   6419      0t0  TCP
>     3724G-21104-2.hsr.ch:svrloc (LISTEN)
>     slpd      2786      daemon    9u  IPv4   6420      0t0  UDP
>     239.255.255.253:svrloc
>     slpd      2786      daemon   10u  IPv4   6421      0t0  UDP
>     3724G-21104-2.hsr.ch:svrloc
>
>     Then I start my application which registers the following two
>     services with SLP:
>     service:TrackingNode.ADEC:CP://10.0.2.15:1234/1c736ed2-e8b7-545c-998a-2ce095e600ea
>     <http://10.0.2.15:1234/1c736ed2-e8b7-545c-998a-2ce095e600ea>
>     service:TrackingNode.ADEC:CP://192.168.0.24:1234/1c736ed2-e8b7-545c-998a-2ce095e600ea
>     <http://192.168.0.24:1234/1c736ed2-e8b7-545c-998a-2ce095e600ea>
>
>     Of course my application opens a socket to listen to port 1234. Now
>     comes the part that surprised me: slpd also begins to listen to port
>     1234 (why??). "lsof -i" shows this:
>
>     COMMAND    PID        USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
>     *TrackingN 4795        root    6u  IPv4  12170      0t0 TCP *:1234
>     (LISTEN)*
>     TrackingN 4795        root    7u  IPv4  12186      0t0  TCP
>     localhost:45272->localhost:svrloc (ESTABLISHED)
>     slpd      4805      daemon    0u  IPv4  12189      0t0  TCP
>     localhost:svrloc->localhost:45272 (ESTABLISHED)
>     slpd      4805      daemon    1u  IPv4  12204      0t0  UDP *:37734
>     slpd      4805      daemon    2u  IPv4  12199      0t0  UDP *:49554
>     slpd      4805      daemon    4u  IPv4  12176      0t0  TCP
>     localhost:svrloc (LISTEN)
>     slpd      4805      daemon    5u  IPv4  12177      0t0  TCP
>     DebianWheezy.local:svrloc (LISTEN)
>     *slpd      4805      daemon    6u  IPv4  12170      0t0 TCP *:1234
>     (LISTEN)*
>     slpd      4805      daemon    7u  IPv4  12178      0t0  UDP
>     239.255.255.253:svrloc
>     slpd      4805      daemon    8u  IPv4  12179      0t0  UDP
>     DebianWheezy.local:svrloc
>     slpd      4805      daemon    9u  IPv4  12180      0t0  TCP
>     3724G-21104-2.hsr.ch:svrloc (LISTEN)
>     slpd      4805      daemon   10u  IPv4  12181      0t0  UDP
>     239.255.255.253:svrloc
>     slpd      4805      daemon   11u  IPv4  12182      0t0  UDP
>     3724G-21104-2.hsr.ch:svrloc
>
>     And then, when I quit my application, slpd keeps listening on port 1234:
>
>     COMMAND    PID        USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
>     slpd      4816      daemon    4u  IPv4  12317      0t0  TCP
>     localhost:svrloc (LISTEN)
>     slpd      4816      daemon    5u  IPv4  12318      0t0  TCP
>     DebianWheezy.local:svrloc (LISTEN)
>     *slpd      4816      daemon    6u  IPv4  12170      0t0 TCP *:1234
>     (LISTEN)*
>     slpd      4816      daemon    7u  IPv4  12319      0t0  UDP
>     239.255.255.253:svrloc
>     slpd      4816      daemon    8u  IPv4  12320      0t0  UDP
>     DebianWheezy.local:svrloc
>     slpd      4816      daemon    9u  IPv4  12321      0t0  TCP
>     3724G-21104-2.hsr.ch:svrloc (LISTEN)
>     slpd      4816      daemon   10u  IPv4  12322      0t0  UDP
>     239.255.255.253:svrloc
>     slpd      4816      daemon   11u  IPv4  12323      0t0  UDP
>     3724G-21104-2.hsr.ch:svrloc
>     slpd      4816      daemon   13u  IPv4  12326      0t0  UDP *:47496
>
>     Now when I restart my application and it tries to open a socket to
>     listen to port 1234 again, I get an "Address already in use" error,
>     since slpd still occupies that port.
>
>     Can anyone explain what's happening here? Why does slpd hijack my port?
>
>     ------------------------------------------------------------------------------
>     Don't let slow site performance ruin your business. Deploy New Relic APM
>     Deploy New Relic app performance management and know exactly
>     what is happening inside your Ruby, Python, PHP, Java, and .NET app
>     Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>     http://p.sf.net/sfu/newrelic-dev2dev
>     _______________________________________________
>     Openslp-users mailing list
>     Ope...@li...
>     <mailto:Ope...@li...>
>     https://lists.sourceforge.net/lists/listinfo/openslp-users
>
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
>
>
>
> _______________________________________________
> Openslp-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openslp-users
>

Re: [Openslp-users] slpd seems to hijack the port I'm using in my application

[Robert H. <rh...@hs...>]

Yes it happens with any port.

I want to try it with version 2.0 but I have some problems getting it to 
work (I'm new to the Linux world...). I managed to build it but I 
couldn't start/stop slpd properly. I'll have a look at this again today.

You might have noticed in the lsof -i listings in my original post that 
the PID of slpd changes. The reason is that my application restarts slpd 
under certain conditions to make sure its service is published on all 
available network interfaces. The application starts and stops slpd by 
calling (as root):
int ret = system("/bin/sh -e /etc/init.d/slpd stop");
int ret = system("/bin/sh -e /etc/init.d/slpd start");

Do you think this could cause the problem? Is this the proper way to 
programmatically restart slpd under Linux (Debian)? Under Windows I use 
the scmanager API and it works like a charm (with version 2.0, I've 
never tested it with version 1.x under Windows). I'll try and check how 
version 2.0 behaves in this scenario later today.

Gavin Lambert posted a patch in the developers newsgroup to make slpd 
re-initialize its interfaces by sending it a signal. It would be great 
if some mechanism like this made it into the release version of OpenSLP 
2.0. In my scenario I would not have to restart spld anymore.

PS: It would make things much easier if version 2.0 came as a prebuilt 
Debian package, so I'm glad to hear that it will soon reach release 
status. Do you think it will make it into Debian Wheezy (which I think 
will soon change from testing to stable)?

Thanks,
Robert


Am 15.10.2012 16:51, schrieb Nick Wagner:
> If you try some other port, does SLP hijack that too?  We're nearing
> release on version 2.0, would you like to try that and see if if you
> have a similar problem?  I don't believe we're doing anything in the
> current code that would cause that side effect, and 1.2.1 was a long
> time ago.
>
> --Nick
>
> On Fri, Oct 12, 2012 at 3:35 AM, Robert Hegner
> <rh...@hs... <mailto:rh...@hs...>> wrote:
>
>     I recently ported my application from Windows to Linux and now I'm
>     experiencing some strange problem when running it under Debian
>     together with OpenSLP 1.2.1-9 (this is the version that comes out of
>     the box with Debian).
>
>     The problem is that slpd seems to occupy the port I'm using for my
>     application. Let me explain...
>
>     Before I start my application, "lsof -i" lists the following spld
>     related entries:
>
>     COMMAND    PID        USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
>     slpd      2786      daemon    4u  IPv4   6415      0t0  TCP
>     localhost:svrloc (LISTEN)
>     slpd      2786      daemon    5u  IPv4   6416      0t0  TCP
>     DebianWheezy.local:svrloc (LISTEN)
>     slpd      2786      daemon    6u  IPv4   6417      0t0  UDP
>     239.255.255.253:svrloc
>     slpd      2786      daemon    7u  IPv4   6418      0t0  UDP
>     DebianWheezy.local:svrloc
>     slpd      2786      daemon    8u  IPv4   6419      0t0  TCP
>     3724G-21104-2.hsr.ch:svrloc (LISTEN)
>     slpd      2786      daemon    9u  IPv4   6420      0t0  UDP
>     239.255.255.253:svrloc
>     slpd      2786      daemon   10u  IPv4   6421      0t0  UDP
>     3724G-21104-2.hsr.ch:svrloc
>
>     Then I start my application which registers the following two
>     services with SLP:
>     service:TrackingNode.ADEC:CP://10.0.2.15:1234/1c736ed2-e8b7-545c-998a-2ce095e600ea
>     <http://10.0.2.15:1234/1c736ed2-e8b7-545c-998a-2ce095e600ea>
>     service:TrackingNode.ADEC:CP://192.168.0.24:1234/1c736ed2-e8b7-545c-998a-2ce095e600ea
>     <http://192.168.0.24:1234/1c736ed2-e8b7-545c-998a-2ce095e600ea>
>
>     Of course my application opens a socket to listen to port 1234. Now
>     comes the part that surprised me: slpd also begins to listen to port
>     1234 (why??). "lsof -i" shows this:
>
>     COMMAND    PID        USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
>     *TrackingN 4795        root    6u  IPv4  12170      0t0 TCP *:1234
>     (LISTEN)*
>     TrackingN 4795        root    7u  IPv4  12186      0t0  TCP
>     localhost:45272->localhost:svrloc (ESTABLISHED)
>     slpd      4805      daemon    0u  IPv4  12189      0t0  TCP
>     localhost:svrloc->localhost:45272 (ESTABLISHED)
>     slpd      4805      daemon    1u  IPv4  12204      0t0  UDP *:37734
>     slpd      4805      daemon    2u  IPv4  12199      0t0  UDP *:49554
>     slpd      4805      daemon    4u  IPv4  12176      0t0  TCP
>     localhost:svrloc (LISTEN)
>     slpd      4805      daemon    5u  IPv4  12177      0t0  TCP
>     DebianWheezy.local:svrloc (LISTEN)
>     *slpd      4805      daemon    6u  IPv4  12170      0t0 TCP *:1234
>     (LISTEN)*
>     slpd      4805      daemon    7u  IPv4  12178      0t0  UDP
>     239.255.255.253:svrloc
>     slpd      4805      daemon    8u  IPv4  12179      0t0  UDP
>     DebianWheezy.local:svrloc
>     slpd      4805      daemon    9u  IPv4  12180      0t0  TCP
>     3724G-21104-2.hsr.ch:svrloc (LISTEN)
>     slpd      4805      daemon   10u  IPv4  12181      0t0  UDP
>     239.255.255.253:svrloc
>     slpd      4805      daemon   11u  IPv4  12182      0t0  UDP
>     3724G-21104-2.hsr.ch:svrloc
>
>     And then, when I quit my application, slpd keeps listening on port 1234:
>
>     COMMAND    PID        USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
>     slpd      4816      daemon    4u  IPv4  12317      0t0  TCP
>     localhost:svrloc (LISTEN)
>     slpd      4816      daemon    5u  IPv4  12318      0t0  TCP
>     DebianWheezy.local:svrloc (LISTEN)
>     *slpd      4816      daemon    6u  IPv4  12170      0t0 TCP *:1234
>     (LISTEN)*
>     slpd      4816      daemon    7u  IPv4  12319      0t0  UDP
>     239.255.255.253:svrloc
>     slpd      4816      daemon    8u  IPv4  12320      0t0  UDP
>     DebianWheezy.local:svrloc
>     slpd      4816      daemon    9u  IPv4  12321      0t0  TCP
>     3724G-21104-2.hsr.ch:svrloc (LISTEN)
>     slpd      4816      daemon   10u  IPv4  12322      0t0  UDP
>     239.255.255.253:svrloc
>     slpd      4816      daemon   11u  IPv4  12323      0t0  UDP
>     3724G-21104-2.hsr.ch:svrloc
>     slpd      4816      daemon   13u  IPv4  12326      0t0  UDP *:47496
>
>     Now when I restart my application and it tries to open a socket to
>     listen to port 1234 again, I get an "Address already in use" error,
>     since slpd still occupies that port.
>
>     Can anyone explain what's happening here? Why does slpd hijack my port?
>
>     ------------------------------------------------------------------------------
>     Don't let slow site performance ruin your business. Deploy New Relic APM
>     Deploy New Relic app performance management and know exactly
>     what is happening inside your Ruby, Python, PHP, Java, and .NET app
>     Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>     http://p.sf.net/sfu/newrelic-dev2dev
>     _______________________________________________
>     Openslp-users mailing list
>     Ope...@li...
>     <mailto:Ope...@li...>
>     https://lists.sourceforge.net/lists/listinfo/openslp-users
>
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
>
>
>
> _______________________________________________
> Openslp-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openslp-users
>