Hi John,
Thanks for the explanation. I think its quite clear now. In our
case we dont have an DA. So its just SA in the n/w. All static reg for SA (from
slp.reg) with 65535 set always retains that service. It never expires. However
if the reg is done dynamically SLPReg method it is noted to expire after 65535
secs. That was the whole confusion is all about. I did read in the RFC that MAX
timeout is 65535 however i didnt chance upon a point where 65535 is special
value that will retain the service forever. I think i missed it. Let me
re-read. Thanks!
Regards,
Varun
On Tuesday, September 07, 2010 09:29:06 am John Calcote wrote:
> Varun,
>
> Clients (SLP UAs - client library linked with service application) are
> supposed to register services with the local SLP SA - local means on the
> same box. If there is no SA, then clients (UAs) will register with a
> remote SA/DA. Clients (applications/services) must re-register before
> their specified registration times expire. This is usually done by
> scheduling an application-level timer event or a background thread to
> call the library registration function again before the service times out.
>
> Often the timeout is set to some smaller value, such as a half hour or
> less. That way, if the application/service goes down hard (process is
> killed or segfaults without a chance to deregister properly), the
> registration will die, within a short time period, of its own accord.
> This is the primary reason why you can't just register a service that
> never expires: The protocol designers wanted to ensure that a situation
> can't arise wherein many dead services are still incorrectly being
> advertised.
>
> DA's, on the other hand, can advertise hard-coded services indefinitely
> because they are the definitive source of advertising information for
> those services. A DA doesn't need to deregister its advertised services
> before it goes down because if the DA goes down hard (is killed or
> segfaults), it will simply cease to advertise services that have been
> registered with it.
>
> The 18 hour maximum comes from the fact that the service lifetime field
> of the registration message is only 16 bits wide. The maximum unsigned
> value that can be represented in 16 bits is 65535. This value, divided
> by 60 seconds per minute, and again divided by 60 minutes per hour (3600
> seconds per hour) gives a maximum lifetime value of 18 hours.
>
> You should read the protocol RFC to understand the details. It's pretty
> clearly written and fairly easy to understand, even for folks who aren't
> experts in protocol design.
>
> http://www.ietf.org/rfc/rfc2165.txt
>
> Regards,
> John
>
> On 9/6/2010 9:28 PM, Varun Chandramohan wrote:
> > Hi John,
> >
> > Iam a bit confused. Richard had suggested that this value
> > will be retained only if my daemon runs as DA. When i run it as SA it is
> > not remembered. It will expire after 18hrs. Atleast thats what i understood
> > from what he said. Can you clarify Richard? Secondly, Iam trying to
> > understand the bit in RFC which says MAX of 18hours only, what does that
> > mean?
> >
> > Regards,
> > Varun
> >
> > On Tuesday, September 07, 2010 05:26:14 am John Calcote wrote:
> >> Hi Varun,
> >>
> >> Looks like you found a bug - 65536 / 3600 is exactly 18 hours. Without
> >> looking at the code, I'd guess that the value 65536 is being interpreted
> >> literally in seconds, rather than as a special value that indicates "no
> >> expiration".
> >>
> >> John
> >>
> >> On 9/5/2010 9:55 PM, Varun Chandramohan wrote:
> >>> No one has a clue?
> >>>
> >>> On Thursday, September 02, 2010 10:52:44 am Varun Chandramohan wrote:
> >>>> Hi All,
> >>>>
> >>>> I have a doubt, My slpd daemon does static registration from
> >>>> slp.reg file. Its observed that these registration gets removed from
> >>>> slpd after 17+ hours. I went through the code and searched the RFC.
> >>>> I found this below.
> >>>>
> >>>> The <entry> is a URL Entry (see section 4.3). The Lifetime defines
> >>>> how long a DA can cache the registration. SAs SHOULD reregister
> >>>> before this lifetime expires (but SHOULD NOT more often than once per
> >>>> second). The Lifetime MAY be set to any value between 0 and 0xffff
> >>>> (maximum, around 18 hours). Long-lived registrations remain stale
> >>>> longer if the service fails and the SA does not deregister the
> >>>> service.
> >>>>
> >>>> So i assumed that slpd is working as per RFC. But then i saw this.
> >>>>
> >>>> http://ocw.novell.com/suse-linux-enterprise-server-engineers/suse-linux-network-services/3057_06_manual.pdf
> >>>> look at the statement marked in bold
> >>>>
> >>>> The OpenSLP Registration File Syntax
> >>>> nservice-url. (required) This option defines the service URL.
> >>>> The syntax is described in “The OpenSLP Service URL Syntax” on 6-14.
> >>>> nlanguage-tag. (required) This option uses the (two character) language
> >>>> tags as specified by RFC 1766 (such as en, fr, and de).
> >>>> nlifetime. (required) This option defines the lifetime of the
> >>>> registration in seconds.
> >>>> The value must be between 0 and 65535.
> >>>> Use 65535 if you want the registration maintained for the life of slpd.
> >>>> nservice-type. (optional) This option defines the type of service being
> >>>> registered.
> >>>> This option is ignored by OpenSLP, because service-url must conform to
> >>>> the SLP Service URL format.
> >>>> nscope-list. (optional) This option is a list of comma-delimited scopes
> >>>> to register the service in.
> >>>> If it is omitted, the service is registered in all scopes specified by
> >>>> the slp.conf file.
> >>>> By default, this is the DEFAULT scope on SLP version 2 systems.
> >>>> nattrid. (optional) This option lists the attributes to register along
> >>>> with the service.
> >>>> Any string but scopes or SCOPES can be used as an attributeThe
> >>>> registration file format is easy to understand. Each registration
> >>>> consists of several lines with the format #comment ;comment
> >>>> service-url,language-tag,lifetime,service-type scopes=scope-list
> >>>> attrid=val1 attrid=val1,val2,val3 The options mean
> >>>>
> >>>>
> >>>> Can someone explain me? Is it possible to have a static reg done that
> >>>> wont get removed after 17+ hours?
> >>>>
> >>>> Regards,
> >>>> Varun
> >>>>
> >>> ------------------------------------------------------------------------------
> >>> This SF.net Dev2Dev email is sponsored by:
> >>>
> >>> Show off your parallel programming skills.
> >>> Enter the Intel(R) Threading Challenge 2010.
> >>> http://p.sf.net/sfu/intel-thread-sfd
> >>> _______________________________________________
> >>> Openslp-devel mailing list
> >>> Openslp-devel@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/openslp-devel
> >>
>
>
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Openslp-devel mailing list
Openslp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openslp-devel
