[jcifs] NtlmSsp - Closing sessions?

Michael B. Allen miallen at eskimo.com
Thu Dec 19 08:28:26 EST 2002


On Wed, 18 Dec 2002 15:21:41 -0500
"Bazyl, Steven" <sbazyl at rsasecurity.com> wrote:

> Thanks for the info.  The issue that concerns me with the servlet filter is
> that thousands of users could be authenticating in a short period of time
> and the transport might not ever be idle long enough to close out all the
> sessions.  The number of sessions and the time need to look them up (since
> its just iterates through the list) will continue to grow until there is a
> lull in activity long enough to timeout the transport.  I suppose I could
> set the timeout to be very short, but that might then introduce some
> additional overhead with having to reestablish connections more frequently.

This will not work with "thousands of users". It might work with
200. 1000 users would require well over 1GB of ram just to hold the
stacks of transport threads. Even if you do not use jCIFS at all I would
be surprised to see anything written in Java support more than a couple
hundred concurrent users. Not without a demultiplexer (e.g. select(2)).

> Quick question on the LGPL - if I do make changes to JCifs and include the
> modified library in a close application, am I only obliged to release the
> JCifs modifications/source or does it prevent me from keeping the app
> closed?

Correct. The LGPL only requires that you reciprocate changes to the
library itself. The 'L' in LGPL stands for Library (or more recently
this was changed to mean Lesser).

But if you just stick 'public' in front of all the methods and build a
closed source DCE/RPC implementation I will not be happy.

> 
> 
> > -----Original Message-----
> > From: Michael B. Allen [mailto:miallen at eskimo.com]
> > Sent: Wednesday, December 18, 2002 12:05 PM
> > To: Allen, Michael B (RSCH)
> > Cc: Bazyl, Steven; jcifs at lists.samba.org
> > Subject: Re: [jcifs] NtlmSsp - Closing sessions?
> > 
> > 
> > Incedentally the NtlmHttpFilter sets 
> > jcifs.smb.client.soTimeout to 5 min:
> > 
> >   Config.setProperty( "jcifs.smb.client.soTimeout", "300000" );
> > 
> > On Tue, 17 Dec 2002 18:53:40 -0500
> > "Allen, Michael B (RSCH)" <Michael_B_Allen at ml.com> wrote:
> > 
> > > All operations performed under the same credentials are 
> > multiplexed over the same
> > > session. So for any domain/username/password combination 
> > there is one
> > > SmbSession. If there is no activity on the SmbTransport 
> > associated with the
> > > SmbSession for jcifs.smb.client.soTomeout milliseconds or 
> > longer, all SmbSessions
> > > will be logged off and the SmbTransport will be closed. 
> > Currently I do not feel these
> > > details should be exposed to the user. Only in certain 
> > pathological cases would the
> > > number of unused SmbSessions become prohibitively 
> > expensive. It is not perfectly
> > > clear to me that your requirements fall into this category 
> > but for now we are requiring
> > > users to make the necessary changes to the code themselves. 
> > For example, one easy
> > > modification that could be made is to simply add something like:
> > > 
> > >     public static SmbSession getSmbSession( UniAddress 
> > server, NtlmPasswordAuthentication auth ) throws SmbException {
> > >         return SmbTransport.getSmbTransport( server, 0 
> > ).getSmbSession( auth );
> > >     }
> > > 
> > > to SmbSession and publicize logoff(). But I would profile 
> > the default deallocation behavior
> > > and determine with certainty that such a modification is 
> > really necessary.
> > > 
> > > > -----Original Message-----
> > > > From:	Bazyl, Steven [SMTP:sbazyl at rsasecurity.com]
> > > > Sent:	Tuesday, December 17, 2002 5:44 PM
> > > > To:	'jcifs at lists.samba.org'
> > > > Subject:	[jcifs] NtlmSsp - Closing sessions?
> > > > 
> > > > I'm interested in using the NtlmSSP interface but while 
> > looking through the
> > > > source I noticed that it is not possible to terminate 
> > individual sessions
> > > > (nor even get an SmbSession reference - its not part of 
> > public API.)  This
> > > > may be a problem if handling lots of authentications, 
> > particular when the
> > > > primary interest is in initial authentication (such as 
> > with the servlet
> > > > filter) rather than a prolonged/interactive sessions.  I 
> > just want to do
> > > > something like the following:
> > > > 
> > > > ...
> > > > SmbSession session = null;
> > > > try {
> > > >   session = SmbSession.logon( dc, authinfo );
> > > > } catch( SmbAuthException e ) {
> > > >   // handle invalid login...
> > > > } catch( SmbException e ) {
> > > >   // handle general failure...
> > > > } finally {
> > > >   if( session != null ) {
> > > >     session.logoff();
> > > > }
> > > > 
> > > > 
> > > > Any thoughts on making the following changes?
> > > > 
> > > > - Change SmbSession.logon to return the SmbSession instance.
> > > > - Make SmbSession.logoff(...) public.  Also have it 
> > remove the session from
> > > > the SmbTransport's list of sessions.
> > > > 
> > > > -Steve

-- 
A  program should be written to model the concepts of the task it
performs rather than the physical world or a process because this
maximizes  the  potential  for it to be applied to tasks that are
conceptually  similar and, more important, to tasks that have not
yet been conceived. 



More information about the jcifs mailing list