[AG-TECH] AccessGrid 3: What information is available

[Ivan R. Judson]

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.

--Ivan

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.
>
> jh
>
> --
> "One day everything will be well, that is our hope. Everything's fine today,
>   that is our illusion."                              -- Voltaire
>
>