[jcifs] NtlmSsp - Closing sessions?

[Allen, Michael B (RSCH)]

> -----Original Message-----
> From:	Bazyl, Steven [SMTP:sbazyl at rsasecurity.com]
> Sent:	Wednesday, December 18, 2002 8:18 PM
> To:	'Michael B. Allen'
> Cc:	jcifs at samba.org
> Subject:	RE: [jcifs] NtlmSsp - Closing sessions?
> 
> 
> > 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)).
> 
> Yes, apps in Java can support (tens-of-)thousands of concurrent 'users'.
> Details of that aside, isn't it just one transport thread per domain
> controller regardless of the number of sessions?
> 
	True. I wasn't thinking of jCIFS I guess. Rather I'm concerned with your
	claim that an application server written entirely in Java can handle
	"thousands" of clients concurrently. The Java IO model does not provide
	a way to multiplex IO across many file descriptors. Even the select(2)
	call from UNIX is limited to about 1024 by default. The poll(2) function can
	handle quite a bit more. So with Java you have to use one thread for each
	client's socket right? This limits the number of clients to less than 1000.
	After that the beast becomes horribly slow and/or runs out of memory
	available to a single process. This would be true in C so I am only drawing
	inference to Java. If you use some core demultiplexer written in C or maybe
	explore new IO features from Java 1.4 it's possible to go above a 1,000 but
	writing a server that handles 10,000 clients in C is considered somewhat
	difficult although very possible. Sure, you can open tens-of-thousands of
	sockets but you will not be able to do reasonable IO on them. I would love
	to hear how you do it though.

>   I just did some testing of
> authenticating a small number of users and there is only 1 transport thread
> as expected.  Its the SmbSession objects that keep building up, however,
> which is why I wanted the logoff call.
> 
> Anyway, please give yourself some credit -- JCifs actually performs pretty
> well as far as just authenticating goes (at least in a single thread...I'll
> try some multithreaded tests later :)  Could it be faster, probably, but it
> works pretty well all things considered!
> 
> > 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.
> 
> The only thing I'm intersted in (as the thread subject implies) is
> incorporating the NTLM authentication functionality into a product.  Anyway,
> it turns out that the modifications are pretty small for my needs - just
> adding one method to SmbTransport:
> 
	Looks reasonable but I cannot guarantee it will work. Test thoroughly.

>     /**
>     * Authenticate against a domain controller.  Unlike logon(), this does
> not establish
>     * a long-lived session for the user -- its purpose is simply to validate
> the user password.
>     *
>     * @param dc Domain Controller to authenticate against
>     * @param auth User authentication info
>     * @throws SmbException if authentication fails.
>     **/
>     public static void authenticate( UniAddress dc, 
>                                      NtlmPasswordAuthentication auth )
> throws SmbException {
>         SmbSession session = null;
>         try {
>              // Don't register SmbSession with transport since we want this
> to be stateless
>              // As for side-effects, this appears to only be an issue if the
> transport thread
>              // is interrupted.  Any other failures, such as socket
> timeouts, result in 
>              // calling the SmbTransport.tryClose() and SmbSession.logoff()
> methods with the
>              // error flag set to true in which case the logoff is
> effectively a no-op save a
>              // few bits of cleanup.  But since we're discarding the session
> anyway its
>              // probably no big deal.
>              session = new SmbSession( SmbTransport.getSmbTransport( dc, 0
> ), auth );
>              session.getSmbTree( "IPC$", null ).treeConnect( null, null );
>         } finally {
>              if( session != null ) {
>                  // Terminate the session
>                  session.logoff( false );
>                  session = null;
>              }
>         }
>     }
> 
> Again, thanks for your assistance :)