Print

Print
I think a standard case is that a manger is visible inside and outside, while the server's aren't. Only the open (+ everything afterwards running on open files read,write,truncate.sync,close etc.) should go through an extra IO gateway (Proxy) while the rest can be handled by the manager in the same way for internal and external clients. The only thing to proxy is the direct IO on open files ... and the locate function of a file from outside should point to the gateway.

Cheers Andreas.




On Fri, Oct 1, 2010 at 8:06 PM, Andrew Hanushevsky <[log in to unmask]> wrote:
Hi Andreas,

That's fine but just opens? I woud think anybody comming in from he internal network should get redirected t something internal and avoid the external node. Does that make sense or do you want fine grained control? If so, is there a particular worrisome request path that I'm missing?

Andy


On Fri, 1 Oct 2010, Andreas-Joachim Peters wrote:

Hi,
I have a question considering the proxy support (which actually comes from
Doug/ATLAS).
Is there an existing implementation/configuration allowing to direct
internal site traffic via the site redirector to disk servers while
external site traffic via one (or several) proxy server to
redirector/diskservers. Eg. is there a 'switch' to redirect external clients
to a proxy gateway and
internal clients directly? I couldn't figure that out even reading the
source code .... looks like there is none ....

If not, would you consider adding an OFS directive which redirects 'opens'
to a proxy gateway based on IP ranges/maskes or just an internal and
external IP mask.

The internal flow of an open would than be

open@manager=>open@server

the external flow

open@manager=>open@proxy:=>XrdClient(=>open@manager=>open@server)

while all other meta commands would only go via the manager.

Cheers Andreas.