perfsonar development work

[Roland Karch <>]

Hi,

On Wed, Jan 26, 2011 at 09:46:14AM -0500, Jason Zurawski wrote:
> Hi All;
>
> I am migrating this to perfSONAR-dev since it brings up an important  
> client/server interaction issue that should be dealt with in the entire  
> consortium.

I can't comment on the specific implementation questions about the
redirects (OPPD doesn't do this I think), so I'll go straight to the
bottom:

> 2) What is the proper way to handle this if automatic redirection is not  
> an issue.  This decision could impact client interactions.

This brings us straight back to the question asked a few months ago, how
to handle error / status messages that aren't perfSONAR but rather
transport protocol related. At this point, I don't think we can afford
to ignore things like HTTP status codes, even if this puts an additional
burden on the user interface. A few services out there apparently
already use them, and even more can't guarantee that the software and
libraries they use will allow the service to always respond with a
proper perfSONAR message to report a problem.

> 3) What is being send to the LS for a service with a redirect in place -  
> the old URI or the new?  If the new URI is being sent, the old should  
> most likely be purged with a de-registration message.

I'd say the old service should deregister its URI upon reconfiguration
or when being shut down. Recommending the new service to explicitly
deregister any "compatibility" URIs isn't likely to provide much of a
benefit compared to the drawback of causing additional load on the
network and AS. If the old service for some reason didn't deregister,
it's a case for expiry within the AS.

> From the pSPS framework point of view, our non-action on the new  
> location is within boundary of the standard, but still leaves the user  
> with little information on what happened.  To address this we will be  
> looking into either:
>
>  1) An error message to relay the 'location' for 3xx errors
>  2) A non-automatic redirection (e.g. the user must confirm they wish to 
> use the new location)

Unless we agree not to use any HTTP status codes in general for
perfSONAR services, I'd say that providing as much information to the
user in case of an unexpected service response is indeed a reasonable
thing to implement.

With best wishes,
Roland
-- 
Roland Karch, DFN-Labor
Friedrich-Alexander-Universit�t Erlangen-N�rnberg
Regionales RechenZentrum Erlangen (RRZE)
Martensstra�e 1, 91058 Erlangen, Germany
Tel. +49 9131 85-27806, -28800, Fax: +49 9131 302941
mailto:
http://www-win.rrze.uni-erlangen.de/