[Spread-users] Sess_recv_client_auth: BUG! Session is alreadyauthorized (status 0x1)

Jonathan Stanton jonathan at cnds.jhu.edu
Wed Oct 24 09:49:49 EDT 2001

On Wed, Oct 24, 2001 at 12:03:59PM +0100, Ben Laurie wrote:
> Jonathan Stanton wrote:
> > 
> > If anyone has any comments on this, or is able to verify that it fixes any
> > connection problems they have I would appreciate hearing about it.
> I'm probably missing something, but it looks to me like the patch
> doesn't actually fix the problem, just makes it fatal! In order to fix
> it, surely the close(mbox) must be moved from Sess_kill() to
> Sess_handle_kill()? Or am I talking rubbish?

My fix was not to delay the close until sess_handle_kill, but was rather to
make the data structure that uses fds as keys not include any fds that are
in a closed state. 

data structures:

Sessions[session number] // indexed by session number, sorted order by
session name -- is transient and can change often
Session_index[fds] // indexed by file descriptor of the daemon. Stable as
long as connection is conected. Can be reused once closed.

The new rule in Sess_update_session_index() now rebuilds the session_index
array when called to only include processes that are in OP state (meaning
they are connected and not closed) or PREAUTH state (before OP state when
they are not authenticated yet and so are not fully established)

So when a new connection comes in and is accepted in Sess_accept, the
fd/mbox returned may overlap one already in session_index (because of a
killed connection) but when we move this new connection into the correct
location in sessions (sorted by name), we also update session_index to only
include the current connections (in sess_accept_continue()) So from now
until the closed connection is completely cleanedup in sess_handle_kill the
closed connection is still in the Sessions[] array but is not in the
session_index array. And we always lookup current sessions only from the
session_index array because the sessions[] array is guaranteed to change so
session numbers are not stable accross function calls. So we will never
confuse the closed connection with the new connection using the same mbox
because only one will ever be in the session_index array.

So I think this is ok, but I'm definitely interested in hearing if I've
convinced you :-)

The reason not to delay the close until sess_handle_kill is partly
historic, partly to cleanup our used resources as soona s possible. The
two step close it to cleanup our state of group membership, but the session
itself is done as soon as the client closes.


Jonathan R. Stanton         jonathan at cs.jhu.edu
Dept. of Computer Science   
Johns Hopkins University    

More information about the Spread-users mailing list