Shibboleth Developers

[Chad La Joie <>]

On 1/7/11 3:23 AM, Lukas Hämmerle wrote:
> > 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

No, this is no longer how the metadata providers (for the IdP or SP) 
work.  They all do conditional GETs based on last modified times and 
ETags now.  So there is only ever one request per refresh cycle.

> 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">

My concern with this is that its yet another behavior to try to explain 
to the people.  The new refreshing semantics are already really hard to 
describe.  Adding more logic in just makes it worse.

> > 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?

Correct.  No socket negotiation, no SSL (if using an HTTPS connection), 
just straight HTTP processing.  And given what I said above with the 
conditional GETs that would likely be fairly low cost most of the time.

--
Chad La Joie
http://itumi.biz
trusted identities, delivered