[jcifs] About disconnection.

[Eric Glass]

Not sure if I follow what you are saying below; you can try setting
the jcifs.smb.client.ssnLimit property to "1"; that will limit
connections to a single session and may eliminate the error you are
seeing with signing.  That will open additional connections for each
new session though; i.e. it won't disconnect any sooner.  But if you
are just trying to eliminate the signing error that might do it.

On 8/29/06, tetsu.soh at nts.ricoh.co.jp <tetsu.soh at nts.ricoh.co.jp> wrote:
>
>
> >
> > That might be a signing code error in jCIFS, or possibly a config
> > thing... signing in SMB is per-connection, not per-user, so multiple
> > users would not matter (the key is based on the credentials of the
> > first user authenticated on the connection; subsequent users  do
> > signing with the same key).
> >
> > >  First, I opened a connection using user AAA, do some stuff, and "logou
> > t".
> > >  And then, I "login" as user BBB to do some thing. But this time, the S
> > MB
> > >  signing will failed.
> > >
> > >  I think the reason is that although I did "logout" action, I cannot cl
> > ose
> > >  connection to release all resources.
> > >  So, when I did login again with different user, the jcifs re-used the
> > >  connection and also the session key.
> > >
> > >  So, to release all resources, the choice we have are 1) we shutdown
> > >  application everytime we did "logout" 2) we wait for a while.
> > >  Any advice about that?
> > >
> > >  Thanks.
> > >
> > >
> > >
>
>  Yes, exactly.
>
>  So how can I fix this "bug"? It seems that session key is decided by
>  negotiation.
>  Can we de-couple Negotiation from connection?
>  Then we have: connection (1) ---- (1,*) negotiation (1) -----(1)user
>
>  Or multiple users share same session key is not unsafe. In this case, job
>  will be simple.
>
>  Thanks
>
>
>