Hi Brian,
Well, I strongly disagree with you on this point. The cgi approach is
painful and keeping track of multi-preferences by client comes with
a large overhead. Additionally, it does not fit the architecture at
all and would require a significant rewrite not only of the selection
algorithm but the location caching mechanism; both of which are time
sensitive code. For more details, read the IPDPS paper on some of the
algorithms used by the cmsd in this regard:
Paper: http://xrootd.org/papers/Scalla_IPDPS12.pdf
Slides: http://xrootd.org/presentations/Slides_IPDPS12.pdf
Also, preferences give clients too much control and opens up the system
to abuse which we've seen happen in the panda system way above what
anyone expected. The consequence is that a large part of the system
winds up running sub-optimally.
Time zone selection provides a reasonable compromise at the first order
(at least in the US and less elsewhere). We do have a plan to do a
better static partitioning of the selection space based on known
connectivity constraints; but that has to wait for IPV6 support. Whether
or not is addresses query propogation is think is moot as it really is a
non-issue in practice.
In the mean time, Atlas is finding that the regional redirector mechanism
is quite powerful in solving site specific selection constraints and moves
issues closer to the location where they can be better solved. So, in the
end it means one has to look more closely on why it is that people want to
start at the global level as opposed to their local level which would
consistently give better results and seeing if there are ways to enforce
that.
Anway, I think the rebrokering is less than several years. That approach
best fits the system architecture and philosophy where the redirector
provides a reasonably good first guess and refinement occurs with
real-time data. Working on that problem now would also speed up the
time-line.
All that said, if you want to implement client-side preferences, I would
recommend it be done by fronting a redirector with a proxy. At least the
impact of algorithmic changes would be contained and provide a better
platform for tinkering.
Andy
P.S. Do not use the xmi plugin as we will be removing support for that in
the very near future. It worked out to be more complicated than it was
worth based on what people actually tried to do with it. No one uses it
now.
On Fri, 13 Jul 2012, Brian Bockelman wrote:
> On Jul 12, 2012, at 11:56 PM, Andrew Hanushevsky wrote:
>
>> Hi Brian,
>>
>> I think what you really want, on the first order, is time-zone selection. That is on our short-term plan. All servers currently report time-zone the old client does not but the new client will (we obviously can back-port to the old client). While this doesn't solve Nort/South issues it gets close enough for now. Our longer term plan is to have the client rebroker the selection based on actual server performance; which as you have noted is more important than the place your getting data from.
>
> What's "short-term" here? The preference plugin approach can be done in fairly short order.
>
> The timezone approach by itself is relatively inflexible (I can't give
> it to a student and ask them to play with the different idea) - it's
> pretty flexible though if implemented as an instance of the preference
> idea. It's also unclear whether you will also solve the query
> propagation issue when the timezone approach is implemented.
>
> I think the rebrokering is ultimately the way to go, but is several years out before being battle-hardened and widely deployed.
>
> Brian
>
> ########################################################################
> Use REPLY-ALL to reply to list
>
> To unsubscribe from the XROOTD-DEV list, click the following link:
> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1
>
########################################################################
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1
|
