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 > >
