Access Controls

[Derek Atkins]

<linas@linas.org> writes:

> It's been rumoured that Derek Atkins said:
> >  Again, see my long mail for a more "coherent" explanation.
> 
> Do you envision keeping one socket open for the entire session?
> Or can a socket be torn down and rebuilt without loosing the session?

I envision keeping one socket open for as long as possible.  It can be
torn down and rebuilt, however doing so would possibly lose session
state.

> I envision, for example, a gnucash client staying up for days or
> weeks, but the socket to the server going down, e.g. because some
> firewall or dslam router recycled.  Would I have to stop & restart
> the gnucash client, or just continue? What about events in that case?
> Do they get queued up in a pending queue, or simply discarded cause
> the client isn't listening?

In this case, the events would be discarded while the client was
"down" (as far as the server was concerned).  When the client
reconnected, it would have to revalidate it's data cache and setup new
callbacks.

> (the http world has trained us to think of socket connections as
> relatively fleeting, ephemeral things, and that's not bad; it just
> raises some interesting issues.)

It's not a world I completely buy.  The problem is that we're talking
about stateful sessions.  So, when do you throw out the state?  Or how
do you even define a "session"?  Obviously this is open to debate.  My
personal preference is to throw out the session state when the
connection goes away.  It also provides a clear definition of the
begining and ending of a session for both sides.  In addition, this
model still allows you to have a long-running client across multiple
'sessions'.

> --linas

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available