openslp-devel — development futures

[Openslp-devel] OpenSLP 2.0.0 Released!

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

We're excited to announce the long-awaited release of OpenSLP 2.0.0. 

 

Sourceforge.net has been updated with new 2.0.0 download packages (tar.gz
source and doxygen tarballs), as well as Windows x86 and x64 msi installer
packages. 

 

http://sourceforge.net/projects/openslp

 

Enjoy!

[Openslp-devel] iphone and android SA?

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

Every once in a while, I come across someone wanting to have SA
functionality on their iphone or android.  Usually we try to find a
solution to the application/protocol so UA functionality is all that is
needed, but it comes up enough that I thought it might be nice to discuss
solutions as a group.

As always, the issue is port 427 requiring root access.  It is configurable
in openslp, but moving this to a higher port number means everyone has to
know the new port and be configured to that port.

What if the application required that a DA is online?  It would appear that
SAs could find and register with the DA, even though they can't respond to
any multicast.

Any other ideas?


--Nick

[Openslp-devel] OpenSLP 2.0 release?

[Jim M. <jim...@wb...>]

Hi,
  Was wondering if there was a status on making a 2.0 release?

Thank you

Re: [Openslp-devel] [PATCHv2] semi-automatically refresh listening interfaces

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

Thanks Gavin.

changeset:   1766:cdaeb8be5165
tag:         tip
user:        John Calcote <joh...@gm...>
date:        Thu Feb 28 18:59:10 2013 -0700
summary:     glambert: Fix to win32 interface change notify code.

John

> -----Original Message-----
> From: Gavin Lambert [mailto:ga...@co...]
> Sent: Thursday, February 28, 2013 6:40 PM
> To: 'John Calcote'
> Cc: ope...@li...
> Subject: RE: [Openslp-devel] [PATCHv2] semi-automatically refresh
listening
> interfaces
> 
> Hi John,
> 
> Just noticed a minor bug (sorry, it was in my original patch):
> 
> In slpd/slp_win32.c line 135 (InterfaceMonitorInit):
> 
> -      if (!(self->pNotifyIpInterfaceChange &&
> self->pNotifyIpInterfaceChange))
> +      if (!(self->pNotifyIpInterfaceChange &&
> self->pCancelMibChangeNotify2))
> 
> It won't actually cause any problems in practice, as one of these won't
exist
> without the other.  But this is more correct.
> 
> Also the comment at line 146 (regarding casting) can be removed; this was
> from an older version of the code, which was solved differently in the
final
> patch (see line 77).
> 
> Regards,
> Gavin
> 
> > -----Original Message-----
> > From: John Calcote [mailto:joh...@gm...]
> > Sent: Thursday, 29 November 2012 08:50
> > To: 'Gavin Lambert'; ope...@li...
> > Subject: RE: [Openslp-devel] [PATCHv2] semi-automatically refresh
> > listening interfaces
> >
> > Hi Gavin,
> >
> > Your dynamic ifc reinit patch has been incorporated into the repository.
> > Thanks for your efforts.
> >
> > Regards,
> > John
> >
> > > -----Original Message-----
> > > From: Gavin Lambert [mailto:ga...@co...]
> > > Sent: Thursday, October 25, 2012 9:32 PM
> > > To: ope...@li...
> > > Subject: [Openslp-devel] [PATCHv2] semi-automatically refresh
> > > listening interfaces
> > >
> > > I've attached a variation of the previous patch (still against the
> > > 2.0
> > beta
> > > 2 tarball) which handles the reinit slightly differently from the
> > original.
> > >
> > > This one will start listening on any newly discovered (or
> > > configured) interfaces, without closing or stopping any previously
> > > opened incoming sockets.
> > >
> > > The advantage over the previous patch is that it will cause less
> > disruption to
> > > ongoing communications, particularly if only a secondary interface
> > > is changing.  The disadvantage is that if the service is left
> > > running for a
> > long time
> > > on a network that keeps assigning it different addresses (presumably
> > > via a DHCP server with a bad memory) then it will gradually eat up
> > > more and more resources, and probably eventually fail.  (I'm not
> > > sure which tradeoff is
> > better
> > > overall.)
> > >
> > > A suggested improvement (which again I'm not quite familiar enough
> > > with the code to do at this point) would be to track which sockets
> > > are
> > associated
> > > with a particular interface and close them if their interface is not
> > > still
> > present
> > > during the reinit.
> > >
> > > Note that for code simplicity it's currently assuming that if the
> > > TCP
> > listen
> > > socket exists then all the other related sockets are still ok too.
> 

Re: [Openslp-devel] [PATCHv2] semi-automatically refresh listening interfaces

[Gavin L. <ga...@co...>]

Hi John,

Just noticed a minor bug (sorry, it was in my original patch):

In slpd/slp_win32.c line 135 (InterfaceMonitorInit):

-      if (!(self->pNotifyIpInterfaceChange &&
self->pNotifyIpInterfaceChange))
+      if (!(self->pNotifyIpInterfaceChange &&
self->pCancelMibChangeNotify2))

It won't actually cause any problems in practice, as one of these won't
exist without the other.  But this is more correct.

Also the comment at line 146 (regarding casting) can be removed; this was
from an older version of the code, which was solved differently in the final
patch (see line 77).

Regards,
Gavin

> -----Original Message-----
> From: John Calcote [mailto:joh...@gm...]
> Sent: Thursday, 29 November 2012 08:50
> To: 'Gavin Lambert'; ope...@li...
> Subject: RE: [Openslp-devel] [PATCHv2] semi-automatically refresh
> listening interfaces
> 
> Hi Gavin,
> 
> Your dynamic ifc reinit patch has been incorporated into the repository.
> Thanks for your efforts.
> 
> Regards,
> John
> 
> > -----Original Message-----
> > From: Gavin Lambert [mailto:ga...@co...]
> > Sent: Thursday, October 25, 2012 9:32 PM
> > To: ope...@li...
> > Subject: [Openslp-devel] [PATCHv2] semi-automatically refresh
> > listening interfaces
> >
> > I've attached a variation of the previous patch (still against the 2.0
> beta
> > 2 tarball) which handles the reinit slightly differently from the
> original.
> >
> > This one will start listening on any newly discovered (or configured)
> > interfaces, without closing or stopping any previously opened incoming
> > sockets.
> >
> > The advantage over the previous patch is that it will cause less
> disruption to
> > ongoing communications, particularly if only a secondary interface is
> > changing.  The disadvantage is that if the service is left running for
> > a
> long time
> > on a network that keeps assigning it different addresses (presumably
> > via a DHCP server with a bad memory) then it will gradually eat up
> > more and more resources, and probably eventually fail.  (I'm not sure
> > which tradeoff is
> better
> > overall.)
> >
> > A suggested improvement (which again I'm not quite familiar enough
> > with the code to do at this point) would be to track which sockets are
> associated
> > with a particular interface and close them if their interface is not
> > still
> present
> > during the reinit.
> >
> > Note that for code simplicity it's currently assuming that if the TCP
> listen
> > socket exists then all the other related sockets are still ok too.

[Openslp-devel] OpenSLPConfig

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

I noticed there is an environment variable setting "OpenSLPConfig" by reading the source code, I wonder if it is set, does the slp.dll and slpd will read the configurations from it instead of from the default location .e.g. from %windows%\slp.conf? Seems OpenSLP also can read properties from global, and application configurations as well. Is there a document or someone can explain how they suppose to work?


Regards,

Ren

Re: [Openslp-devel] SLPReg fresh=false

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

Ren,

If you're making changes to send back to us, I recommend you just clone the
sf.net openslp mercurial repo and use the tip of default. 

If you want the code in openslp 2.0 beta2, do the same thing, but "hg update
-r 2.0.beta2" to update your work area to the code used for that release.
(If you want to know what tags are in the repo, run "hg tags".)

I'm not sure what your goal is, so I gave you both options. 

John

> -----Original Message-----
> From: Wang, Ren [mailto:Ren...@nu...]
> Sent: Thursday, February 07, 2013 12:55 PM
> To: John Calcote
> Cc: 'OpenSLP Devel Mailing List'
> Subject: RE: SLPReg fresh=false
> 
> Hi John,
> 
> We started code change based on the latest OpenSLP 2.x source
> downloaded from the URL
> https://openslp.svn.sourceforge.net/svnroot/openslp/trunk.
> 
> In order to merge the changes into  the stable OpenSLP release code, can
> you provide the stable source code which used to build the OpenSLP 2.0.0
> Beta 2 installer?
> 
> Or, should we send the code to you to merge into the system?
> 
> Ren
> 
> -----Original Message-----
> From: John Calcote [mailto:joh...@gm...]
> Sent: Friday, January 11, 2013 11:29 AM
> To: Wang, Ren
> Cc: 'OpenSLP Devel Mailing List'
> Subject: RE: SLPReg fresh=false
> 
> Just write clean code and try to conform the style that appears in the
existing
> code base - for consistency. Nothing written down.
> 
> --John
> 
> > -----Original Message-----
> > From: Wang, Ren [mailto:Ren...@nu...]
> > Sent: Friday, January 11, 2013 5:28 AM
> > To: John Calcote
> > Cc: 'OpenSLP Devel Mailing List'
> > Subject: RE: SLPReg fresh=false
> >
> > John,
> >
> > Is there any development guideline or design that we need to
> > understand and follow for the implementation?
> >
> > Ren
> >
> > -----Original Message-----
> > From: John Calcote [mailto:joh...@gm...]
> > Sent: Wednesday, January 09, 2013 1:40 PM
> > To: Wang, Ren
> > Cc: 'OpenSLP Devel Mailing List'
> > Subject: RE: SLPReg fresh=false
> >
> > If you are going to implement it anyway, please feel free to
> > contribute
> the
> > patch. We'll evaluate it as a community to understand the impact. If
> > it
> doesn't
> > impact performance much, we'll probably take it. I agree that slpv2bis
> > is
> not
> > slpv2, however, we've planned to do other bis features, such as mesh-
> > enhanced slp in v2 at some point. But please do submit the patch - I'm
> open
> > to new features, as long as the issues and concerns are managed
properly.
> >
> > John
> >
> > > -----Original Message-----
> > > From: Wang, Ren [mailto:Ren...@nu...]
> > > Sent: Wednesday, January 09, 2013 11:13 AM
> > > To: John Calcote
> > > Cc: OpenSLP Devel Mailing List
> > > Subject: RE: SLPReg fresh=false
> > >
> > > Hi John,
> > >
> > > I can understand the reason for not supporting it. But, jSLP and Sun
> > support
> > > it.
> > >
> > > I can't find a formal RFC to drop the feature as well. Do you mind
> > > if we
> > as a
> > > contributor for this feature?
> > >
> > > Ren
> > >
> > > -----Original Message-----
> > > From: John Calcote [mailto:joh...@gm...]
> > > Sent: Tuesday, January 08, 2013 1:26 PM
> > > To: Wang, Ren
> > > Cc: OpenSLP Devel Mailing List
> > > Subject: RE: SLPReg fresh=false
> > >
> > > Hi Ren,
> > >
> > > After a scan of the mailing list archives for the srvloc project on
> > sf.net, I found
> > > the following message submitted by Matt Peterson:
> > >
> > > http://sourceforge.net/mailarchive/message.php?msg_id=3209418
> > >
> > > This message explains the rationale behind disabling incremental
> > > service registration and deregistration. I agree with Matt's
> > > assessment and feel
> > that
> > > we should keep the code as is - incremental service registration is
> > > not supported in OpenSLP because using it overtaxes the SLP protocol.
> > > If you need incremental registration and deregistration, perhaps you
> > > should consider using LDAP instead of SLP.
> > >
> > > Any comments are appreciated (from anyone).
> > >
> > > John
> > >
> > > > -----Original Message-----
> > > > From: John Calcote [mailto:joh...@gm...]
> > > > Sent: Tuesday, January 08, 2013 11:09 AM
> > > > To: 'Wang, Ren'
> > > > Cc: OpenSLP Devel Mailing List
> > > > (ope...@li...)
> > > > Subject: RE: SLPReg fresh=false
> > > >
> > > > (Adding devel list back in so others can chime in if they have
> > > > input)
> > > >
> > > > Hi Ren,
> > > >
> > > > Ok - I was correct in my understanding then - I thought I
> > > > understood that
> > > you
> > > > wanted incremental registrations. My original reply to you was
> > > > that the entire concept of incremental registrations appears to be
> > > > deprecated in slpv2bis, which is the standard that OpenSLP is
> > > > trying to
> > > follow.
> > > >
> > > > Incremental registrations is controlled by the FRESH flag in SLP
> > > > message headers, and the FRESH flag is required to be set to 1 by
> > > > slpv2bis. What I
> > > > *don't* know is why. I don't see any explanation anywhere of why
> > > > this flag was deprecated and required to be set to 1 in message
> > > > headers. I presume that Matt Peterson disabled the use of the
> > > > boolean fresh field in the
> > > SLPReg
> > > > api in order to support the deprecation of incremental
registrations.
> > > >
> > > > In this document: http://srvloc.sourceforge.net/compatibility.html
> > > > the
> > > fresh
> > > > flag is listed under the SLPv2 column as:
> > > >
> > > > "When this flag is present in a SrvReg, this registration
> > > > overwrites any existing registration with the same URL. When this
> > > > flag is absent, a
> > > SrvReg will
> > > > incrementally add to an existing registration."
> > > >
> > > > And under the slpv2bis column as:
> > > >
> > > > "As RFC 2608, except that the Fresh Flag MUST be set on
registrations.
> > > > If
> > > not,
> > > > return a FRESH_MUST_BE_SET error?" (The error code to be returned
> > > > was properly defined after this document was created.)
> > > >
> > > > In other words, since the current implementation of OpenSLP tries
> > > > to support SLPv2bis as closely as possible, we've disabled
> > > > incremental registration by ignoring the Boolean fresh argument
> > > > passed to SLPReg and hard-coding the FRESH flag in the SrvReg
> message header to 1.
> > > > Note that
> > > this
> > > > flag is not a tri-state - the field is always present, and must be
> > > > either
> > > 1 or 0. At
> > > > certain places in the documents referenced on this thread, it
> > > > appears that the flag may be present or not, and if present it
> > > > must be 1 and may not be zero. The flags word is always present,
> > > > and the FRESH flag is hard-coded
> > > to a
> > > > particular position in this word, so it must be present, and must
> > > > be set
> > > to 1.
> > > > Since setting this flag to 1 means the registration is fresh, the
> > > registration will
> > > > overwrite any existing registration.
> > > >
> > > > Once again, I don't know why this was done - no documents I've
> > > > been able
> > > to
> > > > find on the topic seem to indicate the rationale or discussion of
> > > > the
> > > issue that
> > > > caused the change. If anyone on the list knows, please chime in.
> > > >
> > > > Please understand Ren, that I'm not against incremental refresh -
> > > > if I understood the rationale begin removing it, I would be able
> > > > to make an intelligent decision about whether to follow the
> > > > standard in
> this
> > area.
> > > Since I
> > > > don't know why it was deprecated, I have only the wording of the
> > > > standard to go by. If you can find any documentation on the net as
> > > > to why it was removed in the first place, I'd appreciate your
insight.
> > > >
> > > > John
> > > >
> > > > > -----Original Message-----
> > > > > From: Wang, Ren [mailto:Ren...@nu...]
> > > > > Sent: Tuesday, January 08, 2013 9:21 AM
> > > > > To: John Calcote
> > > > > Subject: RE: SLPReg fresh=false
> > > > >
> > > > > Hi John,
> > > > >
> > > > > What we are looking for is to support incremental service
> > registrations.
> > > > >
> > > > > For example, if there is a service registered with attribute
> > > > > (user_id= Ren), and later a new user added to the service, so
> > > > > the increment registration will call SLPReg with attr
> > > > > (user_id=John) and fresh flag set to false to indicate it is an
> > > > > incremental registration. In the registry, the service should
> > > > > have attribute
> > > (user_id=Ren, John).
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: John Calcote [mailto:joh...@gm...]
> > > > > Sent: Tuesday, January 08, 2013 11:13 AM
> > > > > To: Wang, Ren
> > > > > Subject: RE: SLPReg fresh=false
> > > > >
> > > > > I'm sorry Ren, I still don't understand what you're after.
> > > > > Please forgive my incomprehension - if you could explain exactly
> > > > > what you want to use the fresh flag for and why, then perhaps
> > > > > I'd understand what you're asking. I was simply explaining why
> > > > > it's currently
> > > implemented
> > > > (or not) the way it is.
> > > > >
> > > > > John
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Wang, Ren [mailto:Ren...@nu...]
> > > > > > Sent: Tuesday, January 08, 2013 8:07 AM
> > > > > > To: joh...@gm...
> > > > > > Subject: RE: SLPReg fresh=false
> > > > > >
> > > > > > Hi John,
> > > > > >
> > > > > > Thank you again for your response and the URLs.
> > > > > >
> > > > > > Maybe my question was not clear to you, but I was trying to
> > > > > > ask if OpenSLP will support fresh=false instead of not set the
> > > > > > fresh
> flag.
> > > > > > On you second
> > > > > URL,
> > > > > > page 6, it says  "FRESH" MUST be set to 1 on every SrvReg.
> > > > > > Otherwise,
> > > > > MUST
> > > > > > be 0."
> > > > > >
> > > > > > Since current OpenSLP implementation does not support 0 for
> > SrvReg.
> > > > > > Based on the OpenSLP.org, "Currently, OpenSLP does not support
> > > > > > incremental registrations.  If fresh is SLP_FALSE, SLPReg()
> > > > > > will return SLP_NOT_IMPLEMENTED."
> > > > > >
> > > > > > This is why I want to know if you plan to support it.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Ren
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: John Calcote [mailto:joh...@gm...]
> > > > > > Sent: Monday, January 07, 2013 6:37 PM
> > > > > > To: Wang, Ren
> > > > > > Cc: ope...@li...
> > > > > > Subject: RE: SLPReg fresh=false
> > > > > >
> > > > > > Hi Ren,
> > > > > >
> > > > > > The FRESH flag was deprecated after RFC 2608 was published.
> > > > > >
> > > > > > See:
> > > > > >
> > > > > > http://srvloc.sourceforge.net/new_drafts/draft-guttman-svrloc-
> > > > > > as-
> > 00.
> > > > > > tx
> > > > > > t
> > > > > > http://srvloc.sourceforge.net/new_drafts/draft-guttman-svrloc-
> > > > > > rf
> > > > > > c2
> > > > > > 60
> > > > > > 8b
> > > > > > is-
> > > > > > 01.
> > > > > > txt
> > > > > >
> > > > > > In the first document it states on page 3 that an error
> > > > > > (INVALID_UPDATE)
> > > > > is
> > > > > > returned by the SA/DA for registrations that don't set the
> > > > > > FRESH flag in
> > > > > post
> > > > > > slpv2 implementations (slpv2bis - the second document - pp 6,
> > > > > > 7,
> > 21).
> > > > > > The slpv2bis document isn't clear as to why the FRESH flag
> > > > > > must be set
> > > > > > -
> > > > > just
> > > > > > states that it must be set. I presume it's a security issue of
> > > > > > some
> > > kind.
> > > > > >
> > > > > > John
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Wang, Ren [mailto:Ren...@nu...]
> > > > > > > Sent: Monday, January 07, 2013 9:08 AM
> > > > > > > To: John Calcote
> > > > > > > Cc: ope...@li...
> > > > > > > Subject: SLPReg fresh=false
> > > > > > >
> > > > > > > Hi John,
> > > > > > >
> > > > > > > Is there a plan to support fresh=false for SLPReg API?
> > > > > > >
> > > > > > > Since it is a required feature for our project, we may need
> > > > > > > to provide the change to the OpenSLP if there is no short
> > > > > > > term plan to
> > > > > support it.
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > > Ren
> > > > >
> > >
> >
> 

Re: [Openslp-devel] SLPReg fresh=false

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

Hi John,

We started code change based on the latest OpenSLP 2.x source downloaded from the URL https://openslp.svn.sourceforge.net/svnroot/openslp/trunk.

In order to merge the changes into  the stable OpenSLP release code, can you provide the stable source code which used to build the OpenSLP 2.0.0 Beta 2 installer?

Or, should we send the code to you to merge into the system?

Ren

-----Original Message-----
From: John Calcote [mailto:joh...@gm...] 
Sent: Friday, January 11, 2013 11:29 AM
To: Wang, Ren
Cc: 'OpenSLP Devel Mailing List'
Subject: RE: SLPReg fresh=false

Just write clean code and try to conform the style that appears in the existing code base - for consistency. Nothing written down.

--John

> -----Original Message-----
> From: Wang, Ren [mailto:Ren...@nu...]
> Sent: Friday, January 11, 2013 5:28 AM
> To: John Calcote
> Cc: 'OpenSLP Devel Mailing List'
> Subject: RE: SLPReg fresh=false
> 
> John,
> 
> Is there any development guideline or design that we need to 
> understand and follow for the implementation?
> 
> Ren
> 
> -----Original Message-----
> From: John Calcote [mailto:joh...@gm...]
> Sent: Wednesday, January 09, 2013 1:40 PM
> To: Wang, Ren
> Cc: 'OpenSLP Devel Mailing List'
> Subject: RE: SLPReg fresh=false
> 
> If you are going to implement it anyway, please feel free to 
> contribute
the
> patch. We'll evaluate it as a community to understand the impact. If 
> it
doesn't
> impact performance much, we'll probably take it. I agree that slpv2bis 
> is
not
> slpv2, however, we've planned to do other bis features, such as mesh- 
> enhanced slp in v2 at some point. But please do submit the patch - I'm
open
> to new features, as long as the issues and concerns are managed properly.
> 
> John
> 
> > -----Original Message-----
> > From: Wang, Ren [mailto:Ren...@nu...]
> > Sent: Wednesday, January 09, 2013 11:13 AM
> > To: John Calcote
> > Cc: OpenSLP Devel Mailing List
> > Subject: RE: SLPReg fresh=false
> >
> > Hi John,
> >
> > I can understand the reason for not supporting it. But, jSLP and Sun
> support
> > it.
> >
> > I can't find a formal RFC to drop the feature as well. Do you mind 
> > if we
> as a
> > contributor for this feature?
> >
> > Ren
> >
> > -----Original Message-----
> > From: John Calcote [mailto:joh...@gm...]
> > Sent: Tuesday, January 08, 2013 1:26 PM
> > To: Wang, Ren
> > Cc: OpenSLP Devel Mailing List
> > Subject: RE: SLPReg fresh=false
> >
> > Hi Ren,
> >
> > After a scan of the mailing list archives for the srvloc project on
> sf.net, I found
> > the following message submitted by Matt Peterson:
> >
> > http://sourceforge.net/mailarchive/message.php?msg_id=3209418
> >
> > This message explains the rationale behind disabling incremental 
> > service registration and deregistration. I agree with Matt's 
> > assessment and feel
> that
> > we should keep the code as is - incremental service registration is 
> > not supported in OpenSLP because using it overtaxes the SLP protocol.
> > If you need incremental registration and deregistration, perhaps you 
> > should consider using LDAP instead of SLP.
> >
> > Any comments are appreciated (from anyone).
> >
> > John
> >
> > > -----Original Message-----
> > > From: John Calcote [mailto:joh...@gm...]
> > > Sent: Tuesday, January 08, 2013 11:09 AM
> > > To: 'Wang, Ren'
> > > Cc: OpenSLP Devel Mailing List 
> > > (ope...@li...)
> > > Subject: RE: SLPReg fresh=false
> > >
> > > (Adding devel list back in so others can chime in if they have
> > > input)
> > >
> > > Hi Ren,
> > >
> > > Ok - I was correct in my understanding then - I thought I 
> > > understood that
> > you
> > > wanted incremental registrations. My original reply to you was 
> > > that the entire concept of incremental registrations appears to be 
> > > deprecated in slpv2bis, which is the standard that OpenSLP is 
> > > trying to
> > follow.
> > >
> > > Incremental registrations is controlled by the FRESH flag in SLP 
> > > message headers, and the FRESH flag is required to be set to 1 by 
> > > slpv2bis. What I
> > > *don't* know is why. I don't see any explanation anywhere of why 
> > > this flag was deprecated and required to be set to 1 in message 
> > > headers. I presume that Matt Peterson disabled the use of the 
> > > boolean fresh field in the
> > SLPReg
> > > api in order to support the deprecation of incremental registrations.
> > >
> > > In this document: http://srvloc.sourceforge.net/compatibility.html
> > > the
> > fresh
> > > flag is listed under the SLPv2 column as:
> > >
> > > "When this flag is present in a SrvReg, this registration 
> > > overwrites any existing registration with the same URL. When this 
> > > flag is absent, a
> > SrvReg will
> > > incrementally add to an existing registration."
> > >
> > > And under the slpv2bis column as:
> > >
> > > "As RFC 2608, except that the Fresh Flag MUST be set on registrations.
> > > If
> > not,
> > > return a FRESH_MUST_BE_SET error?" (The error code to be returned 
> > > was properly defined after this document was created.)
> > >
> > > In other words, since the current implementation of OpenSLP tries 
> > > to support SLPv2bis as closely as possible, we've disabled 
> > > incremental registration by ignoring the Boolean fresh argument 
> > > passed to SLPReg and hard-coding the FRESH flag in the SrvReg message header to 1.
> > > Note that
> > this
> > > flag is not a tri-state - the field is always present, and must be 
> > > either
> > 1 or 0. At
> > > certain places in the documents referenced on this thread, it 
> > > appears that the flag may be present or not, and if present it 
> > > must be 1 and may not be zero. The flags word is always present, 
> > > and the FRESH flag is hard-coded
> > to a
> > > particular position in this word, so it must be present, and must 
> > > be set
> > to 1.
> > > Since setting this flag to 1 means the registration is fresh, the
> > registration will
> > > overwrite any existing registration.
> > >
> > > Once again, I don't know why this was done - no documents I've 
> > > been able
> > to
> > > find on the topic seem to indicate the rationale or discussion of 
> > > the
> > issue that
> > > caused the change. If anyone on the list knows, please chime in.
> > >
> > > Please understand Ren, that I'm not against incremental refresh - 
> > > if I understood the rationale begin removing it, I would be able 
> > > to make an intelligent decision about whether to follow the 
> > > standard in
this
> area.
> > Since I
> > > don't know why it was deprecated, I have only the wording of the 
> > > standard to go by. If you can find any documentation on the net as 
> > > to why it was removed in the first place, I'd appreciate your insight.
> > >
> > > John
> > >
> > > > -----Original Message-----
> > > > From: Wang, Ren [mailto:Ren...@nu...]
> > > > Sent: Tuesday, January 08, 2013 9:21 AM
> > > > To: John Calcote
> > > > Subject: RE: SLPReg fresh=false
> > > >
> > > > Hi John,
> > > >
> > > > What we are looking for is to support incremental service
> registrations.
> > > >
> > > > For example, if there is a service registered with attribute 
> > > > (user_id= Ren), and later a new user added to the service, so 
> > > > the increment registration will call SLPReg with attr 
> > > > (user_id=John) and fresh flag set to false to indicate it is an 
> > > > incremental registration. In the registry, the service should 
> > > > have attribute
> > (user_id=Ren, John).
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: John Calcote [mailto:joh...@gm...]
> > > > Sent: Tuesday, January 08, 2013 11:13 AM
> > > > To: Wang, Ren
> > > > Subject: RE: SLPReg fresh=false
> > > >
> > > > I'm sorry Ren, I still don't understand what you're after. 
> > > > Please forgive my incomprehension - if you could explain exactly 
> > > > what you want to use the fresh flag for and why, then perhaps 
> > > > I'd understand what you're asking. I was simply explaining why 
> > > > it's currently
> > implemented
> > > (or not) the way it is.
> > > >
> > > > John
> > > >
> > > > > -----Original Message-----
> > > > > From: Wang, Ren [mailto:Ren...@nu...]
> > > > > Sent: Tuesday, January 08, 2013 8:07 AM
> > > > > To: joh...@gm...
> > > > > Subject: RE: SLPReg fresh=false
> > > > >
> > > > > Hi John,
> > > > >
> > > > > Thank you again for your response and the URLs.
> > > > >
> > > > > Maybe my question was not clear to you, but I was trying to 
> > > > > ask if OpenSLP will support fresh=false instead of not set the 
> > > > > fresh
flag.
> > > > > On you second
> > > > URL,
> > > > > page 6, it says  "FRESH" MUST be set to 1 on every SrvReg.
> > > > > Otherwise,
> > > > MUST
> > > > > be 0."
> > > > >
> > > > > Since current OpenSLP implementation does not support 0 for
> SrvReg.
> > > > > Based on the OpenSLP.org, "Currently, OpenSLP does not support 
> > > > > incremental registrations.  If fresh is SLP_FALSE, SLPReg() 
> > > > > will return SLP_NOT_IMPLEMENTED."
> > > > >
> > > > > This is why I want to know if you plan to support it.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Ren
> > > > >
> > > > > -----Original Message-----
> > > > > From: John Calcote [mailto:joh...@gm...]
> > > > > Sent: Monday, January 07, 2013 6:37 PM
> > > > > To: Wang, Ren
> > > > > Cc: ope...@li...
> > > > > Subject: RE: SLPReg fresh=false
> > > > >
> > > > > Hi Ren,
> > > > >
> > > > > The FRESH flag was deprecated after RFC 2608 was published.
> > > > >
> > > > > See:
> > > > >
> > > > > http://srvloc.sourceforge.net/new_drafts/draft-guttman-svrloc-
> > > > > as-
> 00.
> > > > > tx
> > > > > t
> > > > > http://srvloc.sourceforge.net/new_drafts/draft-guttman-svrloc-
> > > > > rf
> > > > > c2
> > > > > 60
> > > > > 8b
> > > > > is-
> > > > > 01.
> > > > > txt
> > > > >
> > > > > In the first document it states on page 3 that an error
> > > > > (INVALID_UPDATE)
> > > > is
> > > > > returned by the SA/DA for registrations that don't set the 
> > > > > FRESH flag in
> > > > post
> > > > > slpv2 implementations (slpv2bis - the second document - pp 6, 
> > > > > 7,
> 21).
> > > > > The slpv2bis document isn't clear as to why the FRESH flag 
> > > > > must be set
> > > > > -
> > > > just
> > > > > states that it must be set. I presume it's a security issue of 
> > > > > some
> > kind.
> > > > >
> > > > > John
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Wang, Ren [mailto:Ren...@nu...]
> > > > > > Sent: Monday, January 07, 2013 9:08 AM
> > > > > > To: John Calcote
> > > > > > Cc: ope...@li...
> > > > > > Subject: SLPReg fresh=false
> > > > > >
> > > > > > Hi John,
> > > > > >
> > > > > > Is there a plan to support fresh=false for SLPReg API?
> > > > > >
> > > > > > Since it is a required feature for our project, we may need 
> > > > > > to provide the change to the OpenSLP if there is no short 
> > > > > > term plan to
> > > > support it.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Ren
> > > >
> >
> 

Re: [Openslp-devel] slptool patch to support --scopes

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

Thanks Simon. Committed to HEAD of default. I modified it slightly, but it's
functionally equivalent.

John

> -----Original Message-----
> From: Simon Newton [mailto:li...@no...]
> Sent: Friday, January 25, 2013 9:34 PM
> To: OpenSLP Devel Mailing List
> Subject: [Openslp-devel] slptool patch to support --scopes
> 
> slptool doesn't honor the -s option when registering a service. The
attached
> patch fixes that.
> 
> I'd submit a bug through sourceforce, but the site is down.....
> 
> Simon

[Openslp-devel] slptool patch to support --scopes

[Simon N. <li...@no...>]

slptool doesn't honor the -s option when registering a service. The
attached patch fixes that.

I'd submit a bug through sourceforce, but the site is down.....

Simon

Re: [Openslp-devel] SLPReg fresh=false

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

Just write clean code and try to conform the style that appears in the
existing code base - for consistency. Nothing written down.

--John

> -----Original Message-----
> From: Wang, Ren [mailto:Ren...@nu...]
> Sent: Friday, January 11, 2013 5:28 AM
> To: John Calcote
> Cc: 'OpenSLP Devel Mailing List'
> Subject: RE: SLPReg fresh=false
> 
> John,
> 
> Is there any development guideline or design that we need to understand
> and follow for the implementation?
> 
> Ren
> 
> -----Original Message-----
> From: John Calcote [mailto:joh...@gm...]
> Sent: Wednesday, January 09, 2013 1:40 PM
> To: Wang, Ren
> Cc: 'OpenSLP Devel Mailing List'
> Subject: RE: SLPReg fresh=false
> 
> If you are going to implement it anyway, please feel free to contribute
the
> patch. We'll evaluate it as a community to understand the impact. If it
doesn't
> impact performance much, we'll probably take it. I agree that slpv2bis is
not
> slpv2, however, we've planned to do other bis features, such as mesh-
> enhanced slp in v2 at some point. But please do submit the patch - I'm
open
> to new features, as long as the issues and concerns are managed properly.
> 
> John
> 
> > -----Original Message-----
> > From: Wang, Ren [mailto:Ren...@nu...]
> > Sent: Wednesday, January 09, 2013 11:13 AM
> > To: John Calcote
> > Cc: OpenSLP Devel Mailing List
> > Subject: RE: SLPReg fresh=false
> >
> > Hi John,
> >
> > I can understand the reason for not supporting it. But, jSLP and Sun
> support
> > it.
> >
> > I can't find a formal RFC to drop the feature as well. Do you mind if
> > we
> as a
> > contributor for this feature?
> >
> > Ren
> >
> > -----Original Message-----
> > From: John Calcote [mailto:joh...@gm...]
> > Sent: Tuesday, January 08, 2013 1:26 PM
> > To: Wang, Ren
> > Cc: OpenSLP Devel Mailing List
> > Subject: RE: SLPReg fresh=false
> >
> > Hi Ren,
> >
> > After a scan of the mailing list archives for the srvloc project on
> sf.net, I found
> > the following message submitted by Matt Peterson:
> >
> > http://sourceforge.net/mailarchive/message.php?msg_id=3209418
> >
> > This message explains the rationale behind disabling incremental
> > service registration and deregistration. I agree with Matt's
> > assessment and feel
> that
> > we should keep the code as is - incremental service registration is
> > not supported in OpenSLP because using it overtaxes the SLP protocol.
> > If you need incremental registration and deregistration, perhaps you
> > should consider using LDAP instead of SLP.
> >
> > Any comments are appreciated (from anyone).
> >
> > John
> >
> > > -----Original Message-----
> > > From: John Calcote [mailto:joh...@gm...]
> > > Sent: Tuesday, January 08, 2013 11:09 AM
> > > To: 'Wang, Ren'
> > > Cc: OpenSLP Devel Mailing List (ope...@li...)
> > > Subject: RE: SLPReg fresh=false
> > >
> > > (Adding devel list back in so others can chime in if they have
> > > input)
> > >
> > > Hi Ren,
> > >
> > > Ok - I was correct in my understanding then - I thought I understood
> > > that
> > you
> > > wanted incremental registrations. My original reply to you was that
> > > the entire concept of incremental registrations appears to be
> > > deprecated in slpv2bis, which is the standard that OpenSLP is trying
> > > to
> > follow.
> > >
> > > Incremental registrations is controlled by the FRESH flag in SLP
> > > message headers, and the FRESH flag is required to be set to 1 by
> > > slpv2bis. What I
> > > *don't* know is why. I don't see any explanation anywhere of why
> > > this flag was deprecated and required to be set to 1 in message
> > > headers. I presume that Matt Peterson disabled the use of the
> > > boolean fresh field in the
> > SLPReg
> > > api in order to support the deprecation of incremental registrations.
> > >
> > > In this document: http://srvloc.sourceforge.net/compatibility.html
> > > the
> > fresh
> > > flag is listed under the SLPv2 column as:
> > >
> > > "When this flag is present in a SrvReg, this registration overwrites
> > > any existing registration with the same URL. When this flag is
> > > absent, a
> > SrvReg will
> > > incrementally add to an existing registration."
> > >
> > > And under the slpv2bis column as:
> > >
> > > "As RFC 2608, except that the Fresh Flag MUST be set on registrations.
> > > If
> > not,
> > > return a FRESH_MUST_BE_SET error?" (The error code to be returned
> > > was properly defined after this document was created.)
> > >
> > > In other words, since the current implementation of OpenSLP tries to
> > > support SLPv2bis as closely as possible, we've disabled incremental
> > > registration by ignoring the Boolean fresh argument passed to SLPReg
> > > and hard-coding the FRESH flag in the SrvReg message header to 1.
> > > Note that
> > this
> > > flag is not a tri-state - the field is always present, and must be
> > > either
> > 1 or 0. At
> > > certain places in the documents referenced on this thread, it
> > > appears that the flag may be present or not, and if present it must
> > > be 1 and may not be zero. The flags word is always present, and the
> > > FRESH flag is hard-coded
> > to a
> > > particular position in this word, so it must be present, and must be
> > > set
> > to 1.
> > > Since setting this flag to 1 means the registration is fresh, the
> > registration will
> > > overwrite any existing registration.
> > >
> > > Once again, I don't know why this was done - no documents I've been
> > > able
> > to
> > > find on the topic seem to indicate the rationale or discussion of
> > > the
> > issue that
> > > caused the change. If anyone on the list knows, please chime in.
> > >
> > > Please understand Ren, that I'm not against incremental refresh - if
> > > I understood the rationale begin removing it, I would be able to
> > > make an intelligent decision about whether to follow the standard in
this
> area.
> > Since I
> > > don't know why it was deprecated, I have only the wording of the
> > > standard to go by. If you can find any documentation on the net as
> > > to why it was removed in the first place, I'd appreciate your insight.
> > >
> > > John
> > >
> > > > -----Original Message-----
> > > > From: Wang, Ren [mailto:Ren...@nu...]
> > > > Sent: Tuesday, January 08, 2013 9:21 AM
> > > > To: John Calcote
> > > > Subject: RE: SLPReg fresh=false
> > > >
> > > > Hi John,
> > > >
> > > > What we are looking for is to support incremental service
> registrations.
> > > >
> > > > For example, if there is a service registered with attribute
> > > > (user_id= Ren), and later a new user added to the service, so the
> > > > increment registration will call SLPReg with attr (user_id=John)
> > > > and fresh flag set to false to indicate it is an incremental
> > > > registration. In the registry, the service should have attribute
> > (user_id=Ren, John).
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: John Calcote [mailto:joh...@gm...]
> > > > Sent: Tuesday, January 08, 2013 11:13 AM
> > > > To: Wang, Ren
> > > > Subject: RE: SLPReg fresh=false
> > > >
> > > > I'm sorry Ren, I still don't understand what you're after. Please
> > > > forgive my incomprehension - if you could explain exactly what you
> > > > want to use the fresh flag for and why, then perhaps I'd
> > > > understand what you're asking. I was simply explaining why it's
> > > > currently
> > implemented
> > > (or not) the way it is.
> > > >
> > > > John
> > > >
> > > > > -----Original Message-----
> > > > > From: Wang, Ren [mailto:Ren...@nu...]
> > > > > Sent: Tuesday, January 08, 2013 8:07 AM
> > > > > To: joh...@gm...
> > > > > Subject: RE: SLPReg fresh=false
> > > > >
> > > > > Hi John,
> > > > >
> > > > > Thank you again for your response and the URLs.
> > > > >
> > > > > Maybe my question was not clear to you, but I was trying to ask
> > > > > if OpenSLP will support fresh=false instead of not set the fresh
flag.
> > > > > On you second
> > > > URL,
> > > > > page 6, it says  "FRESH" MUST be set to 1 on every SrvReg.
> > > > > Otherwise,
> > > > MUST
> > > > > be 0."
> > > > >
> > > > > Since current OpenSLP implementation does not support 0 for
> SrvReg.
> > > > > Based on the OpenSLP.org, "Currently, OpenSLP does not support
> > > > > incremental registrations.  If fresh is SLP_FALSE, SLPReg() will
> > > > > return SLP_NOT_IMPLEMENTED."
> > > > >
> > > > > This is why I want to know if you plan to support it.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Ren
> > > > >
> > > > > -----Original Message-----
> > > > > From: John Calcote [mailto:joh...@gm...]
> > > > > Sent: Monday, January 07, 2013 6:37 PM
> > > > > To: Wang, Ren
> > > > > Cc: ope...@li...
> > > > > Subject: RE: SLPReg fresh=false
> > > > >
> > > > > Hi Ren,
> > > > >
> > > > > The FRESH flag was deprecated after RFC 2608 was published.
> > > > >
> > > > > See:
> > > > >
> > > > > http://srvloc.sourceforge.net/new_drafts/draft-guttman-svrloc-as-
> 00.
> > > > > tx
> > > > > t
> > > > > http://srvloc.sourceforge.net/new_drafts/draft-guttman-svrloc-rf
> > > > > c2
> > > > > 60
> > > > > 8b
> > > > > is-
> > > > > 01.
> > > > > txt
> > > > >
> > > > > In the first document it states on page 3 that an error
> > > > > (INVALID_UPDATE)
> > > > is
> > > > > returned by the SA/DA for registrations that don't set the FRESH
> > > > > flag in
> > > > post
> > > > > slpv2 implementations (slpv2bis - the second document - pp 6, 7,
> 21).
> > > > > The slpv2bis document isn't clear as to why the FRESH flag must
> > > > > be set
> > > > > -
> > > > just
> > > > > states that it must be set. I presume it's a security issue of
> > > > > some
> > kind.
> > > > >
> > > > > John
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Wang, Ren [mailto:Ren...@nu...]
> > > > > > Sent: Monday, January 07, 2013 9:08 AM
> > > > > > To: John Calcote
> > > > > > Cc: ope...@li...
> > > > > > Subject: SLPReg fresh=false
> > > > > >
> > > > > > Hi John,
> > > > > >
> > > > > > Is there a plan to support fresh=false for SLPReg API?
> > > > > >
> > > > > > Since it is a required feature for our project, we may need to
> > > > > > provide the change to the OpenSLP if there is no short term
> > > > > > plan to
> > > > support it.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Ren
> > > >
> >
> 

Re: [Openslp-devel] SLPReg fresh=false

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

If you are going to implement it anyway, please feel free to contribute the
patch. We'll evaluate it as a community to understand the impact. If it
doesn't impact performance much, we'll probably take it. I agree that
slpv2bis is not slpv2, however, we've planned to do other bis features, such
as mesh-enhanced slp in v2 at some point. But please do submit the patch -
I'm open to new features, as long as the issues and concerns are managed
properly.

John

> -----Original Message-----
> From: Wang, Ren [mailto:Ren...@nu...]
> Sent: Wednesday, January 09, 2013 11:13 AM
> To: John Calcote
> Cc: OpenSLP Devel Mailing List
> Subject: RE: SLPReg fresh=false
> 
> Hi John,
> 
> I can understand the reason for not supporting it. But, jSLP and Sun
support
> it.
> 
> I can't find a formal RFC to drop the feature as well. Do you mind if we
as a
> contributor for this feature?
> 
> Ren
> 
> -----Original Message-----
> From: John Calcote [mailto:joh...@gm...]
> Sent: Tuesday, January 08, 2013 1:26 PM
> To: Wang, Ren
> Cc: OpenSLP Devel Mailing List
> Subject: RE: SLPReg fresh=false
> 
> Hi Ren,
> 
> After a scan of the mailing list archives for the srvloc project on
sf.net, I found
> the following message submitted by Matt Peterson:
> 
> http://sourceforge.net/mailarchive/message.php?msg_id=3209418
> 
> This message explains the rationale behind disabling incremental service
> registration and deregistration. I agree with Matt's assessment and feel
that
> we should keep the code as is - incremental service registration is not
> supported in OpenSLP because using it overtaxes the SLP protocol. If you
> need incremental registration and deregistration, perhaps you should
> consider using LDAP instead of SLP.
> 
> Any comments are appreciated (from anyone).
> 
> John
> 
> > -----Original Message-----
> > From: John Calcote [mailto:joh...@gm...]
> > Sent: Tuesday, January 08, 2013 11:09 AM
> > To: 'Wang, Ren'
> > Cc: OpenSLP Devel Mailing List (ope...@li...)
> > Subject: RE: SLPReg fresh=false
> >
> > (Adding devel list back in so others can chime in if they have input)
> >
> > Hi Ren,
> >
> > Ok - I was correct in my understanding then - I thought I understood
> > that
> you
> > wanted incremental registrations. My original reply to you was that
> > the entire concept of incremental registrations appears to be
> > deprecated in slpv2bis, which is the standard that OpenSLP is trying to
> follow.
> >
> > Incremental registrations is controlled by the FRESH flag in SLP
> > message headers, and the FRESH flag is required to be set to 1 by
> > slpv2bis. What I
> > *don't* know is why. I don't see any explanation anywhere of why this
> > flag was deprecated and required to be set to 1 in message headers. I
> > presume that Matt Peterson disabled the use of the boolean fresh field
> > in the
> SLPReg
> > api in order to support the deprecation of incremental registrations.
> >
> > In this document: http://srvloc.sourceforge.net/compatibility.html the
> fresh
> > flag is listed under the SLPv2 column as:
> >
> > "When this flag is present in a SrvReg, this registration overwrites
> > any existing registration with the same URL. When this flag is absent,
> > a
> SrvReg will
> > incrementally add to an existing registration."
> >
> > And under the slpv2bis column as:
> >
> > "As RFC 2608, except that the Fresh Flag MUST be set on registrations.
> > If
> not,
> > return a FRESH_MUST_BE_SET error?" (The error code to be returned was
> > properly defined after this document was created.)
> >
> > In other words, since the current implementation of OpenSLP tries to
> > support SLPv2bis as closely as possible, we've disabled incremental
> > registration by ignoring the Boolean fresh argument passed to SLPReg
> > and hard-coding the FRESH flag in the SrvReg message header to 1. Note
> > that
> this
> > flag is not a tri-state - the field is always present, and must be
> > either
> 1 or 0. At
> > certain places in the documents referenced on this thread, it appears
> > that the flag may be present or not, and if present it must be 1 and
> > may not be zero. The flags word is always present, and the FRESH flag
> > is hard-coded
> to a
> > particular position in this word, so it must be present, and must be
> > set
> to 1.
> > Since setting this flag to 1 means the registration is fresh, the
> registration will
> > overwrite any existing registration.
> >
> > Once again, I don't know why this was done - no documents I've been
> > able
> to
> > find on the topic seem to indicate the rationale or discussion of the
> issue that
> > caused the change. If anyone on the list knows, please chime in.
> >
> > Please understand Ren, that I'm not against incremental refresh - if I
> > understood the rationale begin removing it, I would be able to make an
> > intelligent decision about whether to follow the standard in this area.
> Since I
> > don't know why it was deprecated, I have only the wording of the
> > standard to go by. If you can find any documentation on the net as to
> > why it was removed in the first place, I'd appreciate your insight.
> >
> > John
> >
> > > -----Original Message-----
> > > From: Wang, Ren [mailto:Ren...@nu...]
> > > Sent: Tuesday, January 08, 2013 9:21 AM
> > > To: John Calcote
> > > Subject: RE: SLPReg fresh=false
> > >
> > > Hi John,
> > >
> > > What we are looking for is to support incremental service
registrations.
> > >
> > > For example, if there is a service registered with attribute
> > > (user_id= Ren), and later a new user added to the service, so the
> > > increment registration will call SLPReg with attr (user_id=John) and
> > > fresh flag set to false to indicate it is an incremental
> > > registration. In the registry, the service should have attribute
> (user_id=Ren, John).
> > >
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: John Calcote [mailto:joh...@gm...]
> > > Sent: Tuesday, January 08, 2013 11:13 AM
> > > To: Wang, Ren
> > > Subject: RE: SLPReg fresh=false
> > >
> > > I'm sorry Ren, I still don't understand what you're after. Please
> > > forgive my incomprehension - if you could explain exactly what you
> > > want to use the fresh flag for and why, then perhaps I'd understand
> > > what you're asking. I was simply explaining why it's currently
> implemented
> > (or not) the way it is.
> > >
> > > John
> > >
> > > > -----Original Message-----
> > > > From: Wang, Ren [mailto:Ren...@nu...]
> > > > Sent: Tuesday, January 08, 2013 8:07 AM
> > > > To: joh...@gm...
> > > > Subject: RE: SLPReg fresh=false
> > > >
> > > > Hi John,
> > > >
> > > > Thank you again for your response and the URLs.
> > > >
> > > > Maybe my question was not clear to you, but I was trying to ask if
> > > > OpenSLP will support fresh=false instead of not set the fresh flag.
> > > > On you second
> > > URL,
> > > > page 6, it says  "FRESH" MUST be set to 1 on every SrvReg.
> > > > Otherwise,
> > > MUST
> > > > be 0."
> > > >
> > > > Since current OpenSLP implementation does not support 0 for SrvReg.
> > > > Based on the OpenSLP.org, "Currently, OpenSLP does not support
> > > > incremental registrations.  If fresh is SLP_FALSE, SLPReg() will
> > > > return SLP_NOT_IMPLEMENTED."
> > > >
> > > > This is why I want to know if you plan to support it.
> > > >
> > > > Regards,
> > > >
> > > > Ren
> > > >
> > > > -----Original Message-----
> > > > From: John Calcote [mailto:joh...@gm...]
> > > > Sent: Monday, January 07, 2013 6:37 PM
> > > > To: Wang, Ren
> > > > Cc: ope...@li...
> > > > Subject: RE: SLPReg fresh=false
> > > >
> > > > Hi Ren,
> > > >
> > > > The FRESH flag was deprecated after RFC 2608 was published.
> > > >
> > > > See:
> > > >
> > > > http://srvloc.sourceforge.net/new_drafts/draft-guttman-svrloc-as-00.
> > > > tx
> > > > t
> > > > http://srvloc.sourceforge.net/new_drafts/draft-guttman-svrloc-rfc2
> > > > 60
> > > > 8b
> > > > is-
> > > > 01.
> > > > txt
> > > >
> > > > In the first document it states on page 3 that an error
> > > > (INVALID_UPDATE)
> > > is
> > > > returned by the SA/DA for registrations that don't set the FRESH
> > > > flag in
> > > post
> > > > slpv2 implementations (slpv2bis - the second document - pp 6, 7,
21).
> > > > The slpv2bis document isn't clear as to why the FRESH flag must be
> > > > set
> > > > -
> > > just
> > > > states that it must be set. I presume it's a security issue of
> > > > some
> kind.
> > > >
> > > > John
> > > >
> > > > > -----Original Message-----
> > > > > From: Wang, Ren [mailto:Ren...@nu...]
> > > > > Sent: Monday, January 07, 2013 9:08 AM
> > > > > To: John Calcote
> > > > > Cc: ope...@li...
> > > > > Subject: SLPReg fresh=false
> > > > >
> > > > > Hi John,
> > > > >
> > > > > Is there a plan to support fresh=false for SLPReg API?
> > > > >
> > > > > Since it is a required feature for our project, we may need to
> > > > > provide the change to the OpenSLP if there is no short term plan
> > > > > to
> > > support it.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Ren
> > >
> 

Re: [Openslp-devel] SLPReg fresh=false

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

Hi Ren,

After a scan of the mailing list archives for the srvloc project on sf.net,
I found the following message submitted by Matt Peterson:

http://sourceforge.net/mailarchive/message.php?msg_id=3209418

This message explains the rationale behind disabling incremental service
registration and deregistration. I agree with Matt's assessment and feel
that we should keep the code as is - incremental service registration is not
supported in OpenSLP because using it overtaxes the SLP protocol. If you
need incremental registration and deregistration, perhaps you should
consider using LDAP instead of SLP.

Any comments are appreciated (from anyone).

John

> -----Original Message-----
> From: John Calcote [mailto:joh...@gm...]
> Sent: Tuesday, January 08, 2013 11:09 AM
> To: 'Wang, Ren'
> Cc: OpenSLP Devel Mailing List (ope...@li...)
> Subject: RE: SLPReg fresh=false
> 
> (Adding devel list back in so others can chime in if they have input)
> 
> Hi Ren,
> 
> Ok - I was correct in my understanding then - I thought I understood that
you
> wanted incremental registrations. My original reply to you was that the
> entire concept of incremental registrations appears to be deprecated in
> slpv2bis, which is the standard that OpenSLP is trying to follow.
> 
> Incremental registrations is controlled by the FRESH flag in SLP message
> headers, and the FRESH flag is required to be set to 1 by slpv2bis. What I
> *don't* know is why. I don't see any explanation anywhere of why this flag
> was deprecated and required to be set to 1 in message headers. I presume
> that Matt Peterson disabled the use of the boolean fresh field in the
SLPReg
> api in order to support the deprecation of incremental registrations.
> 
> In this document: http://srvloc.sourceforge.net/compatibility.html the
fresh
> flag is listed under the SLPv2 column as:
> 
> "When this flag is present in a SrvReg, this registration overwrites any
> existing registration with the same URL. When this flag is absent, a
SrvReg will
> incrementally add to an existing registration."
> 
> And under the slpv2bis column as:
> 
> "As RFC 2608, except that the Fresh Flag MUST be set on registrations. If
not,
> return a FRESH_MUST_BE_SET error?" (The error code to be returned was
> properly defined after this document was created.)
> 
> In other words, since the current implementation of OpenSLP tries to
> support SLPv2bis as closely as possible, we've disabled incremental
> registration by ignoring the Boolean fresh argument passed to SLPReg and
> hard-coding the FRESH flag in the SrvReg message header to 1. Note that
this
> flag is not a tri-state - the field is always present, and must be either
1 or 0. At
> certain places in the documents referenced on this thread, it appears that
> the flag may be present or not, and if present it must be 1 and may not be
> zero. The flags word is always present, and the FRESH flag is hard-coded
to a
> particular position in this word, so it must be present, and must be set
to 1.
> Since setting this flag to 1 means the registration is fresh, the
registration will
> overwrite any existing registration.
> 
> Once again, I don't know why this was done - no documents I've been able
to
> find on the topic seem to indicate the rationale or discussion of the
issue that
> caused the change. If anyone on the list knows, please chime in.
> 
> Please understand Ren, that I'm not against incremental refresh - if I
> understood the rationale begin removing it, I would be able to make an
> intelligent decision about whether to follow the standard in this area.
Since I
> don't know why it was deprecated, I have only the wording of the standard
> to go by. If you can find any documentation on the net as to why it was
> removed in the first place, I'd appreciate your insight.
> 
> John
> 
> > -----Original Message-----
> > From: Wang, Ren [mailto:Ren...@nu...]
> > Sent: Tuesday, January 08, 2013 9:21 AM
> > To: John Calcote
> > Subject: RE: SLPReg fresh=false
> >
> > Hi John,
> >
> > What we are looking for is to support incremental service registrations.
> >
> > For example, if there is a service registered with attribute (user_id=
> > Ren), and later a new user added to the service, so the increment
> > registration will call SLPReg with attr (user_id=John) and fresh flag
> > set to false to indicate it is an incremental registration. In the
> > registry, the service should have attribute (user_id=Ren, John).
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: John Calcote [mailto:joh...@gm...]
> > Sent: Tuesday, January 08, 2013 11:13 AM
> > To: Wang, Ren
> > Subject: RE: SLPReg fresh=false
> >
> > I'm sorry Ren, I still don't understand what you're after. Please
> > forgive my incomprehension - if you could explain exactly what you
> > want to use the fresh flag for and why, then perhaps I'd understand
> > what you're asking. I was simply explaining why it's currently
implemented
> (or not) the way it is.
> >
> > John
> >
> > > -----Original Message-----
> > > From: Wang, Ren [mailto:Ren...@nu...]
> > > Sent: Tuesday, January 08, 2013 8:07 AM
> > > To: joh...@gm...
> > > Subject: RE: SLPReg fresh=false
> > >
> > > Hi John,
> > >
> > > Thank you again for your response and the URLs.
> > >
> > > Maybe my question was not clear to you, but I was trying to ask if
> > > OpenSLP will support fresh=false instead of not set the fresh flag.
> > > On you second
> > URL,
> > > page 6, it says  "FRESH" MUST be set to 1 on every SrvReg.
> > > Otherwise,
> > MUST
> > > be 0."
> > >
> > > Since current OpenSLP implementation does not support 0 for SrvReg.
> > > Based on the OpenSLP.org, "Currently, OpenSLP does not support
> > > incremental registrations.  If fresh is SLP_FALSE, SLPReg() will
> > > return SLP_NOT_IMPLEMENTED."
> > >
> > > This is why I want to know if you plan to support it.
> > >
> > > Regards,
> > >
> > > Ren
> > >
> > > -----Original Message-----
> > > From: John Calcote [mailto:joh...@gm...]
> > > Sent: Monday, January 07, 2013 6:37 PM
> > > To: Wang, Ren
> > > Cc: ope...@li...
> > > Subject: RE: SLPReg fresh=false
> > >
> > > Hi Ren,
> > >
> > > The FRESH flag was deprecated after RFC 2608 was published.
> > >
> > > See:
> > >
> > > http://srvloc.sourceforge.net/new_drafts/draft-guttman-svrloc-as-00.
> > > tx
> > > t
> > > http://srvloc.sourceforge.net/new_drafts/draft-guttman-svrloc-rfc260
> > > 8b
> > > is-
> > > 01.
> > > txt
> > >
> > > In the first document it states on page 3 that an error
> > > (INVALID_UPDATE)
> > is
> > > returned by the SA/DA for registrations that don't set the FRESH
> > > flag in
> > post
> > > slpv2 implementations (slpv2bis - the second document - pp 6, 7, 21).
> > > The slpv2bis document isn't clear as to why the FRESH flag must be
> > > set
> > > -
> > just
> > > states that it must be set. I presume it's a security issue of some
kind.
> > >
> > > John
> > >
> > > > -----Original Message-----
> > > > From: Wang, Ren [mailto:Ren...@nu...]
> > > > Sent: Monday, January 07, 2013 9:08 AM
> > > > To: John Calcote
> > > > Cc: ope...@li...
> > > > Subject: SLPReg fresh=false
> > > >
> > > > Hi John,
> > > >
> > > > Is there a plan to support fresh=false for SLPReg API?
> > > >
> > > > Since it is a required feature for our project, we may need to
> > > > provide the change to the OpenSLP if there is no short term plan
> > > > to
> > support it.
> > > >
> > > > Regards,
> > > >
> > > > Ren
> >

Re: [Openslp-devel] SLPReg fresh=false

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

(Adding devel list back in so others can chime in if they have input)

Hi Ren,

Ok - I was correct in my understanding then - I thought I understood that
you wanted incremental registrations. My original reply to you was that the
entire concept of incremental registrations appears to be deprecated in
slpv2bis, which is the standard that OpenSLP is trying to follow.

Incremental registrations is controlled by the FRESH flag in SLP message
headers, and the FRESH flag is required to be set to 1 by slpv2bis. What I
*don't* know is why. I don't see any explanation anywhere of why this flag
was deprecated and required to be set to 1 in message headers. I presume
that Matt Peterson disabled the use of the boolean fresh field in the SLPReg
api in order to support the deprecation of incremental registrations.

In this document: http://srvloc.sourceforge.net/compatibility.html the fresh
flag is listed under the SLPv2 column as:

"When this flag is present in a SrvReg, this registration overwrites any
existing registration with the same URL. When this flag is absent, a SrvReg
will incrementally add to an existing registration."

And under the slpv2bis column as:

"As RFC 2608, except that the Fresh Flag MUST be set on registrations. If
not, return a FRESH_MUST_BE_SET error?" (The error code to be returned was
properly defined after this document was created.)

In other words, since the current implementation of OpenSLP tries to support
SLPv2bis as closely as possible, we've disabled incremental registration by
ignoring the Boolean fresh argument passed to SLPReg and hard-coding the
FRESH flag in the SrvReg message header to 1. Note that this flag is not a
tri-state - the field is always present, and must be either 1 or 0. At
certain places in the documents referenced on this thread, it appears that
the flag may be present or not, and if present it must be 1 and may not be
zero. The flags word is always present, and the FRESH flag is hard-coded to
a particular position in this word, so it must be present, and must be set
to 1. Since setting this flag to 1 means the registration is fresh, the
registration will overwrite any existing registration.

Once again, I don't know why this was done - no documents I've been able to
find on the topic seem to indicate the rationale or discussion of the issue
that caused the change. If anyone on the list knows, please chime in.

Please understand Ren, that I'm not against incremental refresh - if I
understood the rationale begin removing it, I would be able to make an
intelligent decision about whether to follow the standard in this area.
Since I don't know why it was deprecated, I have only the wording of the
standard to go by. If you can find any documentation on the net as to why it
was removed in the first place, I'd appreciate your insight.

John

> -----Original Message-----
> From: Wang, Ren [mailto:Ren...@nu...]
> Sent: Tuesday, January 08, 2013 9:21 AM
> To: John Calcote
> Subject: RE: SLPReg fresh=false
> 
> Hi John,
> 
> What we are looking for is to support incremental service registrations.
> 
> For example, if there is a service registered with attribute (user_id=
Ren),
> and later a new user added to the service, so the increment registration
will
> call SLPReg with attr (user_id=John) and fresh flag set to false to
indicate it is
> an incremental registration. In the registry, the service should have
attribute
> (user_id=Ren, John).
> 
> 
> 
> 
> 
> -----Original Message-----
> From: John Calcote [mailto:joh...@gm...]
> Sent: Tuesday, January 08, 2013 11:13 AM
> To: Wang, Ren
> Subject: RE: SLPReg fresh=false
> 
> I'm sorry Ren, I still don't understand what you're after. Please forgive
my
> incomprehension - if you could explain exactly what you want to use the
> fresh flag for and why, then perhaps I'd understand what you're asking. I
was
> simply explaining why it's currently implemented (or not) the way it is.
> 
> John
> 
> > -----Original Message-----
> > From: Wang, Ren [mailto:Ren...@nu...]
> > Sent: Tuesday, January 08, 2013 8:07 AM
> > To: joh...@gm...
> > Subject: RE: SLPReg fresh=false
> >
> > Hi John,
> >
> > Thank you again for your response and the URLs.
> >
> > Maybe my question was not clear to you, but I was trying to ask if
> > OpenSLP will support fresh=false instead of not set the fresh flag. On
> > you second
> URL,
> > page 6, it says  "FRESH" MUST be set to 1 on every SrvReg.  Otherwise,
> MUST
> > be 0."
> >
> > Since current OpenSLP implementation does not support 0 for SrvReg.
> > Based on the OpenSLP.org, "Currently, OpenSLP does not support
> > incremental registrations.  If fresh is SLP_FALSE, SLPReg() will
> > return SLP_NOT_IMPLEMENTED."
> >
> > This is why I want to know if you plan to support it.
> >
> > Regards,
> >
> > Ren
> >
> > -----Original Message-----
> > From: John Calcote [mailto:joh...@gm...]
> > Sent: Monday, January 07, 2013 6:37 PM
> > To: Wang, Ren
> > Cc: ope...@li...
> > Subject: RE: SLPReg fresh=false
> >
> > Hi Ren,
> >
> > The FRESH flag was deprecated after RFC 2608 was published.
> >
> > See:
> >
> > http://srvloc.sourceforge.net/new_drafts/draft-guttman-svrloc-as-00.tx
> > t
> > http://srvloc.sourceforge.net/new_drafts/draft-guttman-svrloc-rfc2608b
> > is-
> > 01.
> > txt
> >
> > In the first document it states on page 3 that an error
> > (INVALID_UPDATE)
> is
> > returned by the SA/DA for registrations that don't set the FRESH flag
> > in
> post
> > slpv2 implementations (slpv2bis - the second document - pp 6, 7, 21).
> > The slpv2bis document isn't clear as to why the FRESH flag must be set
> > -
> just
> > states that it must be set. I presume it's a security issue of some
kind.
> >
> > John
> >
> > > -----Original Message-----
> > > From: Wang, Ren [mailto:Ren...@nu...]
> > > Sent: Monday, January 07, 2013 9:08 AM
> > > To: John Calcote
> > > Cc: ope...@li...
> > > Subject: SLPReg fresh=false
> > >
> > > Hi John,
> > >
> > > Is there a plan to support fresh=false for SLPReg API?
> > >
> > > Since it is a required feature for our project, we may need to
> > > provide the change to the OpenSLP if there is no short term plan to
> support it.
> > >
> > > Regards,
> > >
> > > Ren
> 

Re: [Openslp-devel] Status on testing?

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

Thanks for the fresh eyes, Simon!  I was too focused on the intriguing
EADDRNOTAVAIL failure to realize that it was supposed to fail and something
else was wrong. :)

The OS X fix has been added to the hg tip.  And everything else seems to
pass my basic functional testing.

--Nick


On Thu, Jan 3, 2013 at 11:30 PM, Simon Newton <li...@no...> wrote:

>
>
> On Thu, Jan 3, 2013 at 9:06 AM, Nick Wagner <ne...@wi...> wrote:
>
>> Well, work's been swamped, so I took a little time to do some OS X
>> testing over the holidays.  And frankly, I'm a little stumped.  In
>> slpd_incoming.c, IncomingDatagramRead(), if the incoming message was sent
>> via multicast the sendto() always fails with a EADDRNOTAVAIL.  I can ping
>> the address, the address structure looks to be initialized correctly, etc.
>>  This problem occurs whether or not I take out the DARWIN section that I
>> added a while ago to fix a similar issue on multiNIC machines.
>>
>> It could just be my test envrionment, but I'm not sure.  Any ideas?
>>
>
> In the first call to sendto() on line 116 it uses sock->fd rather than
> sendsock. Change this and it will work correctly.
>
>
> Simon
>
>
>> --Nick
>>
>>
>> On Fri, Dec 21, 2012 at 4:21 PM, Nick Wagner <ne...@wi...>wrote:
>>
>>> I did a little bit of OSX testing -- I've found a bug that prevents slpd
>>> from responding to multicast requests, e.g. a multicast request for
>>> directory agents.  Hopefully I'll get to it in the next couple of days,
>>> although the holidays are upon us.  Is anyone else having a similar problem
>>> on Linux/Windows?
>>>
>>> --Nick
>>>
>>>
>>> On Thu, Dec 20, 2012 at 6:47 PM, John Calcote <joh...@gm...>wrote:
>>>
>>>> Thanks Jim.****
>>>>
>>>> ** **
>>>>
>>>> John****
>>>>
>>>> ** **
>>>>
>>>> *From:* Jim Davis [mailto:jim...@wb...]
>>>> *Sent:* Thursday, December 20, 2012 3:45 PM
>>>> *To:* John Calcote
>>>> *Cc:* OpenSLP Devel Mailing List
>>>> *Subject:* Re: [Openslp-devel] Status on testing?****
>>>>
>>>> ** **
>>>>
>>>> We have not yet completed our testing. We hope to complete it next week
>>>> (but it may be the first week of Jan).****
>>>> Jim Davis****CTO
>>>> 910-528-5511
>>>> [image: WS] <http://ws-inc.com/>****** **
>>>>
>>>> John Calcote wrote:****
>>>>
>>>> I haven’t seen much traffic for the last week. Anyone doing any testing
>>>> on the tip of default before Christmas?****
>>>>
>>>>  ****
>>>>
>>>> John****
>>>>
>>>>
>>>>
>>>>
>>>> ****
>>>>
>>>> ------------------------------------------------------------------------------****
>>>>
>>>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial****
>>>>
>>>> Remotely access PCs and mobile devices and provide instant support****
>>>>
>>>> Improve your efficiency, and focus on delivering more value-add services****
>>>>
>>>> Discover what IT Professionals Know. Rescue delivers****
>>>>
>>>> http://p.sf.net/sfu/logmein_12329d2d****
>>>>
>>>>
>>>>
>>>>
>>>> ****
>>>>
>>>> _______________________________________________****
>>>>
>>>>
>>>> Openslp-devel mailing list****
>>>>
>>>> Ope...@li...****
>>>>
>>>> https://lists.sourceforge.net/lists/listinfo/openslp-devel****
>>>>
>>>> ** **
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
>>>> Remotely access PCs and mobile devices and provide instant support
>>>> Improve your efficiency, and focus on delivering more value-add services
>>>> Discover what IT Professionals Know. Rescue delivers
>>>> http://p.sf.net/sfu/logmein_12329d2d
>>>> _______________________________________________
>>>> Openslp-devel mailing list
>>>> Ope...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/openslp-devel
>>>>
>>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
>> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
>> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
>> MVPs and experts. ON SALE this month only -- learn more at:
>> http://p.sf.net/sfu/learnmore_122712
>>
>> _______________________________________________
>> Openslp-devel mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/openslp-devel
>>
>>
>

Re: [Openslp-devel] Status on testing?

[Simon N. <li...@no...>]

On Thu, Jan 3, 2013 at 9:06 AM, Nick Wagner <ne...@wi...> wrote:

> Well, work's been swamped, so I took a little time to do some OS X testing
> over the holidays.  And frankly, I'm a little stumped.  In slpd_incoming.c,
> IncomingDatagramRead(), if the incoming message was sent via multicast the
> sendto() always fails with a EADDRNOTAVAIL.  I can ping the address, the
> address structure looks to be initialized correctly, etc.  This problem
> occurs whether or not I take out the DARWIN section that I added a while
> ago to fix a similar issue on multiNIC machines.
>
> It could just be my test envrionment, but I'm not sure.  Any ideas?
>

In the first call to sendto() on line 116 it uses sock->fd rather than
sendsock. Change this and it will work correctly.


Simon


> --Nick
>
>
> On Fri, Dec 21, 2012 at 4:21 PM, Nick Wagner <ne...@wi...>wrote:
>
>> I did a little bit of OSX testing -- I've found a bug that prevents slpd
>> from responding to multicast requests, e.g. a multicast request for
>> directory agents.  Hopefully I'll get to it in the next couple of days,
>> although the holidays are upon us.  Is anyone else having a similar problem
>> on Linux/Windows?
>>
>> --Nick
>>
>>
>> On Thu, Dec 20, 2012 at 6:47 PM, John Calcote <joh...@gm...>wrote:
>>
>>> Thanks Jim.****
>>>
>>> ** **
>>>
>>> John****
>>>
>>> ** **
>>>
>>> *From:* Jim Davis [mailto:jim...@wb...]
>>> *Sent:* Thursday, December 20, 2012 3:45 PM
>>> *To:* John Calcote
>>> *Cc:* OpenSLP Devel Mailing List
>>> *Subject:* Re: [Openslp-devel] Status on testing?****
>>>
>>> ** **
>>>
>>> We have not yet completed our testing. We hope to complete it next week
>>> (but it may be the first week of Jan).****
>>> Jim Davis****CTO
>>> 910-528-5511
>>> [image: WS] <http://ws-inc.com/>****** **
>>>
>>> John Calcote wrote:****
>>>
>>> I haven’t seen much traffic for the last week. Anyone doing any testing
>>> on the tip of default before Christmas?****
>>>
>>>  ****
>>>
>>> John****
>>>
>>>
>>>
>>>
>>> ****
>>>
>>> ------------------------------------------------------------------------------****
>>>
>>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial****
>>>
>>> Remotely access PCs and mobile devices and provide instant support****
>>>
>>> Improve your efficiency, and focus on delivering more value-add services****
>>>
>>> Discover what IT Professionals Know. Rescue delivers****
>>>
>>> http://p.sf.net/sfu/logmein_12329d2d****
>>>
>>>
>>>
>>>
>>> ****
>>>
>>> _______________________________________________****
>>>
>>>
>>> Openslp-devel mailing list****
>>>
>>> Ope...@li...****
>>>
>>> https://lists.sourceforge.net/lists/listinfo/openslp-devel****
>>>
>>> ** **
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
>>> Remotely access PCs and mobile devices and provide instant support
>>> Improve your efficiency, and focus on delivering more value-add services
>>> Discover what IT Professionals Know. Rescue delivers
>>> http://p.sf.net/sfu/logmein_12329d2d
>>> _______________________________________________
>>> Openslp-devel mailing list
>>> Ope...@li...
>>> https://lists.sourceforge.net/lists/listinfo/openslp-devel
>>>
>>>
>>
>
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122712
> _______________________________________________
> Openslp-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openslp-devel
>
>

Re: [Openslp-devel] Status on testing?

[Jim D. <jim...@wb...>]

We have not yet completed our testing. We hope to complete it next week 
(but it may be the first week of Jan).

mail
Jim Davis

CTO
910-528-5511
WS <http://ws-inc.com/>


John Calcote wrote:
>
> I haven't seen much traffic for the last week. Anyone doing any 
> testing on the tip of default before Christmas?
>
> John
>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
>
>
> _______________________________________________
> Openslp-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openslp-devel

[Openslp-devel] Status on testing?

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

I haven't seen much traffic for the last week. Anyone doing any testing on
the tip of default before Christmas?

 

John

Re: [Openslp-devel] What platforms are being tested?

[Jim M. <jim...@wb...>]

Once I get some free time I will test the latest tree on CentOS 5.5, 
Solaris 10 (sparc and intel), Windows and possibly AIX 5.3. Hopefully 
this will be done by the end of this week.

Jim

Nick Wagner wrote:
> I've discovered that my OS X setup at work isn't currently going to 
> work for testing openslp. Before I try to set something up at home, I 
> thought I'd check if anyone else was testing Mac?  Is anyone hitting 
> the Windows version?
>
> While it was great that the work Jim Marshall did spurred on this 
> release, it would have been nice if this work was in place _before_ he 
> did all of his testing. :)
>
> --Nick
>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
>
>
> _______________________________________________
> Openslp-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openslp-devel


-- 
mail
Jim Marshall

Sr. Software Engineer
WS <http://ws-inc.com/>

Re: [Openslp-devel] Remote DOS crash in openslp

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

(copying list)

In an attempt to begin doing more unit testing, I've added a unit test framework to slp_compare.c. This is nothing more than a test-main at the bottom of the source file. I've added six tests to start with, but many, many more could be added to give us better coverage of this utility module.

John

> -----Original Message-----
> From: Matthew Pendlebury [mailto:Matthew.Pendlebury@thales-
> esecurity.com]
> Sent: Wednesday, December 12, 2012 8:37 AM
> To: joh...@gm...
> Cc: Richard Porter
> Subject: RE: Re: Remote DOS crash in openslp
> 
> Hi John,
> 
> FWIW we were looking to see if we could find out what was causing the crash
> noted in http://secunia.com/advisories/50130/
> and if that still occurred using the v2 protocol which is what we are using here
> as the scant details of the vulnerability suggest a v1 issue.  However there is
> still a fair body of code in current version dating from v1.21 times especially in
> the parsing utility routines.  Figuring that if anyone other than the finder has
> more details of that vulnerability it is probably yourself, then you might want
> to quickly see if that cures this issue as well.
> 
> Hope that helps
> 
> --Matt
> 
> 
> 
> > -----Original Message-----
> > From: Richard Porter [mailto:Ric...@th...]
> > Sent: 12 December 2012 15:18
> > To: Matthew Pendlebury
> > Subject: Fwd: Re: Remote DOS crash in openslp
> >
> >
> >
> >
> > -------- Original Message --------
> > Subject:      Re: Remote DOS crash in openslp
> > Date:         Wed, 12 Dec 2012 15:15:37 +0000
> > From:         John Calcote <joh...@gm...>
> > To:   Richard Porter <Ric...@th...>
> >
> >
> >
> > Thanks Richard. I''ll apply the patch this morning.
> >
> > Sent from my HTC One™ X+, an AT&T 4G LTE smartphone
> >
> >
> > ----- Reply message -----
> > From: "Richard Porter" <Ric...@th...>
> > To: <joh...@gm...>
> > Subject: Remote DOS crash in openslp
> > Date: Wed, Dec 12, 2012 4:00 AM
> >
> >
> > Hi John
> >
> > This is an additional patch to the set I just posted to openslp-devel.
> >
> > We've recently performed some protocol fuzzing against openslp, and
> > recorded a crash in SLPDProcessMessage().  What seems to be happening
> > is, the SrvReg packet parser decides that the packet is not valid, and
> > sets errorcode.  The lines marked 'TRICKY' then free the recvbuf as it
> > was duplicated earlier.  Unfortunately, when the if statements unwind,
> > the end of the function checks if errorcode is set and then tries to
> > log the now-freed recvbuf, which segfaults.  My fix is to set
> > recvbuf=0 when it is freed, which then short-circuits the
> SLPDLogMessage() function.
> >
> > I've attached a patch, and a way to reproduce the crash.
> >
> > - Richard
> >
> > Consider the environment before printing this mail.
> >
> > Thales e-Security Limited is incorporated in England and Wales with
> > company registration number 2518805. Its registered office is located
> > at
> > 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Nr.
> > Weybridge, Surrey KT15 2NX.
> >
> > The information contained in this e-mail is confidential. It may also
> > be privileged. It is intended only for the stated addressee(s) and
> > access to it by any other person is unauthorised. If you are not an
> > addressee or the intended addressee, you must not disclose, copy,
> > circulate or in any other way use or rely on the information contained in this
> e-mail.
> > Such unauthorised use may be unlawful. If you have received this
> > e-mail in error, please inform us immediately on +44 (0)1223 723600
> > and delete it and all copies from your system.  Commercial matters
> > detailed or referred to in this e-mail are subject to a written
> > contract signed for and on behalf of Thales e-Security Limited.
> >
> 
> 
> Consider the environment before printing this mail.
> 
> Thales e-Security Limited is incorporated in England and Wales with company
> registration number 2518805. Its registered office is located at 2 Dashwood
> Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey
> KT15 2NX.
> 
> The information contained in this e-mail is confidential. It may also be
> privileged. It is intended only for the stated addressee(s) and access to it by
> any other person is unauthorised. If you are not an addressee or the
> intended addressee, you must not disclose, copy, circulate or in any other
> way use or rely on the information contained in this e-mail. Such
> unauthorised use may be unlawful. If you have received this e-mail in error,
> please inform us immediately on +44 (0)1223 723600 and delete it and all
> copies from your system.  Commercial matters detailed or referred to in this
> e-mail are subject to a written contract signed for and on behalf of Thales e-
> Security Limited.

Re: [Openslp-devel] What platforms are being tested?

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

Agreed.

 

I realize you're not pointing fingers Nick, but I must apologize for my part
in this. I'm sorry for causing all the code churn right before a release.
I'll try to commit submitted patches in a more timely fashion in the future.

 

John

 

From: Nick Wagner [mailto:ne...@wi...] 
Sent: Wednesday, December 12, 2012 12:07 PM
To: ope...@li...
Subject: [Openslp-devel] What platforms are being tested?

 

I've discovered that my OS X setup at work isn't currently going to work for
testing openslp. Before I try to set something up at home, I thought I'd
check if anyone else was testing Mac?  Is anyone hitting the Windows
version?

 

While it was great that the work Jim Marshall did spurred on this release,
it would have been nice if this work was in place _before_ he did all of his
testing. :)

 

--Nick

 

[Openslp-devel] What platforms are being tested?

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

I've discovered that my OS X setup at work isn't currently going to work
for testing openslp. Before I try to set something up at home, I thought
I'd check if anyone else was testing Mac?  Is anyone hitting the Windows
version?

While it was great that the work Jim Marshall did spurred on this release,
it would have been nice if this work was in place _before_ he did all of
his testing. :)

--Nick

Re: [Openslp-devel] Remote DOS crash in openslp

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

(Copying list)

Hi Richard,

Your patch is now committed.

I also committed a fix for a couple of compiler problems from the last patch
set that never made it into the code base for some reason. I'm fairly
certain tip compiles cleanly now. 

Sorry for any trouble this oversight caused.

John

> -----Original Message-----
> From: Richard Porter [mailto:Ric...@th...]
> Sent: Wednesday, December 12, 2012 4:01 AM
> To: joh...@gm...
> Subject: Remote DOS crash in openslp
> 
> Hi John
> 
> This is an additional patch to the set I just posted to openslp-devel.
> 
> We've recently performed some protocol fuzzing against openslp, and
> recorded a crash in SLPDProcessMessage().  What seems to be happening is,
> the SrvReg packet parser decides that the packet is not valid, and sets
> errorcode.  The lines marked 'TRICKY' then free the recvbuf as it was
> duplicated earlier.  Unfortunately, when the if statements unwind, the end
> of the function checks if errorcode is set and then tries to log the
now-freed
> recvbuf, which segfaults.  My fix is to set recvbuf=0 when it is freed,
which
> then short-circuits the SLPDLogMessage() function.
> 
> I've attached a patch, and a way to reproduce the crash.
> 
> - Richard
> 
> Consider the environment before printing this mail.
> 
> Thales e-Security Limited is incorporated in England and Wales with
company
> registration number 2518805. Its registered office is located at 2
Dashwood
> Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey
> KT15 2NX.
> 
> The information contained in this e-mail is confidential. It may also be
> privileged. It is intended only for the stated addressee(s) and access to
it by
> any other person is unauthorised. If you are not an addressee or the
> intended addressee, you must not disclose, copy, circulate or in any other
> way use or rely on the information contained in this e-mail. Such
> unauthorised use may be unlawful. If you have received this e-mail in
error,
> please inform us immediately on +44 (0)1223 723600 and delete it and all
> copies from your system.  Commercial matters detailed or referred to in
this
> e-mail are subject to a written contract signed for and on behalf of
Thales e-
> Security Limited.

[Openslp-devel] Ticket 114 and 115 patches applied to tip.

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

Openslp developers,

 

I've applied Matthew's changes from Ticket's 114 and 115. 

 

Please retest with code at revision 373fb89cc1ab

 

Thanks,

John

[Openslp-devel] all patches applied, project version updated

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

As far as I can tell, I've applied all patches submitted to me at this
point, including the suse patches.  I did not apply the following patches
from suse:

 

1.       03.extensions.diff

2.       11.openslp.truncate.diff

3.       18.openslp.use-TCPDIAG-for-checking-listeners

4.       20.openslp.initda.diff

 

(NOTE: I added the numbers to the front of the patch file names to track the
order in which they were applied to the original openslp 1.2.1 code base.)

 

I didn't apply these patches because they represent significant
modifications to existing functionality or significant enhancements to the
existing OpenSLP specification. The extensions.diff patch contains primarily
the mdns enhancement. I'd like to add mdns support after a little more
investigation into how we might do it more transparently. Since this is a
major addition, I decided not to add it until the next minor 2.x release -
probably 2.1.

 

The truncate.diff patch was not necessary, I felt, because it's purpose is
to ensure that inbound UDP packets are truncated to the max packet size (if
not explicitly allowed by a configuration parameter). The 2.0 code base uses
a calculated maximum transfer unit (mtu) size as the maximum allowable
packet size. Since the max packet size is calculated based on what the wire
will allow, it made little sense to me to check for packets larger than the
largest size allowed by the wire based on a runtime check of that maximum
size.

 

The use-TCPDIAG-for-checking-listeners.diff patch is based on code added by
extensions.diff, so it can't be applied until extensions is applied or at
least until mdns is implemented. When we implement mdns, we should just take
care to incorporate the logic in this patch in our version of mdns.

 

The initda.diff patch also represented a large chunk of new functionality
wherein the slpda comes up and pre-initializes itself to the entire contents
of another existing DA, configured in the properties file. This is a nice
feature also, but should be considered as a significant enhancement to be
added in a future release.

 

Please let me know if I've missed anything. I'm going to stop committing
now, so please grab the latest and build and test on your systems. I've done
some basic testing to ensure it all still pretty much works (at least on
linux), but these patches represent changes, and changes mean possible
errors. If all looks good to everyone in a week or so, we'll release 2.0.

 

Thanks

John