[AG-TECH] AccessGrid 3: What information is available
Ivan R. Judson
judson at mcs.anl.gov
Mon May 23 11:30:41 CDT 2005
Just a bit of an interjection here, but I *believe* (ie, I could be
mistaken) the intention for AG3 is to remove GSITCP from the system and
for secure connections to rely on SSL.
This should significantly improve stability; there's no use of delegation
in the AG Toolkit, and the single sign-on that's part of the AGToolkit
will hopefully be broader than the GSI Proxy model, it'll be more like
having a password manager that knows how to generate GSI proxy if needed.
On Mon, 23 May 2005, John Hodrien wrote:
> On Fri, 20 May 2005, Steve Smith wrote:
> > The problem is it's extremely easy to confuse globus about state. Try this:
> > login to an AG session on one machine, proceed to another machine and login
> > to another session. Now, on the first machine kill -9 the original session.
> > Notice that the session still exists in the other AG client. Restart the
> > session. You now have two instances of the first session; the old one will
> > remain for a few minutes.
> Personally I don't see that as a big deal. Potentially that also offers the
> ability to lose a connection (let's say your broadband connection died, and on
> reconnect gave you a different IP) and reconnect (since your client still has
> the endpoint reference to your WS-Resource you can just connect back in to the
> login you had before with all the state preserved, without the server even
> noticing that you've disappeared. The client could handle that so you'd not
> have to do *anything* to reconnect exactly where you left off.
> Also it means that you could even switch machine and hold onto your state,
> without having to do anything in particular at the server side. You could
> even have two connections to the same state from different machines
> concurrently, again without having to do *anything* special at the server end.
> I'm less bothered by your example where it's due to a bug at the client end
> (admittedly you killed it, but that's a mere detail). If you design your
> client as above (to try and restore state before creating a new session) then
> you'll always reuse available sessions, and only ever create when there's not
> one available to you.
> > Do again for three. Do in a loop to bog the server down to a crawl. (This
> > isn't hypothetical, by the way, I've seen this happen with a buggy client.)
> > This isn't a problem using the statefulness of a connection-oriented
> > protocol; killing the client causes the OS to kill the connection which
> > kills the session on the server.
> But even with TCP, if you don't send traffic down a connection you don't know
> it's disconnected (unless the client was able to close the socket before
> bailing out). So a buggy client can still shaft you can't it?
> > The irony is that Globus implements statefulness on top of stateless
> > protocols (HTTP/web-services), which are implemented by making and breaking
> > stateful connections (TCP). The question is why don't we just use the
> > extremely well understood semantics of TCP to maintain connection state?
> > I should point out that I'm not saying that there's a fundamental problem
> > with the globus/ws architecture itself, just that it's a poor match for the
> > AG.
> I personally don't see that as a biggie, but each to their own.
> "One day everything will be well, that is our hope. Everything's fine today,
> that is our illusion." -- Voltaire
More information about the ag-tech