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
