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

[John Hodrien]

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