Skip to Content.
Sympa Menu

shibboleth-dev - Re: [Shib-Dev] OnDemand MetadataProvider

Subject: Shibboleth Developers

List archive

Re: [Shib-Dev] OnDemand MetadataProvider


Chronological Thread 
  • From: Lukas Hämmerle <>
  • To:
  • Subject: Re: [Shib-Dev] OnDemand MetadataProvider
  • Date: Fri, 07 Jan 2011 09:23:32 +0100
  • Organization: SWITCH - Serving Swiss Universities

> You could create such an extension but when it comes down to it, it's
> really just a tradeoff. Either you want really fast updates and
> therefore have to have a short polling time (and deal with the load that
> creates) or you don't.

One advantage of Halm's proposed on-demand MetadataProvider would be
that the load on the metadata serving host is less heavy because a
provider would download metadata either during the regular polling (e.g.
1 hour) as is the case today or in case the provider received a request
for a (yet) unknown entity (e.g. a new AffiliationDescriptor
EntityDescriptor).

In the later case, the provider would first make a HEAD request and
first check whether metadata was changed and only if it changed the
provider would then refresh it. Since this download depends on some kind
of external (user) interaction, the on-demand metadata most probably
would not occur for many providers at the same time. Thus, the metadata
serving host would be less stressed than with a short polling interval

Instead of creating a new MetadataProvier, this on-demand feature could
just be a configuration option for the existing
FileBackedHTTPMetadataProvider MetadataProvier much like cacheDuration
or maintainExpiredMetadata. For example:

<MetadataProvider
id="URLMD"
xsi:type="FileBackedHTTPMetadataProvider"
maintainExpiredMetadata="false"
cacheDuration="3600"
onDemandRefresh="true"
>



> A different approach you could take is to look at the docs for the HTTP
> client that the provider is using. It does support socket keepalive and
> HTTP pipelining. Using both, or even just socket keepalive, would
> drastically reduce the cost of making a bunch of quick requests.

If I understand this correctly this would mean that with a short polling
interval (e.g. 1min) the provider could keep the http connection open,
which would save some handshaking overhead for the HTTP HEAD requests,
right?

Lukas

--
SWITCH
Serving Swiss Universities
--------------------------
Lukas Hämmerle, Software Engineer, Net Services
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 64, fax +41 44 268 15 68
,
http://www.switch.ch



Archive powered by MHonArc 2.6.16.

Top of Page