[jcifs] holding open a connection

[Michael B Allen]

On Sat, 12 Jan 2002 06:29:05 -0500
Bruce Altner <baltner at hq.nasa.gov> wrote:

> Greetings:
> 
> In my trials to date with jCIFS I been holding the user auth information in 
> memory (servlet session) and reauthenticating with each call to the file 
> system. This has worked oK with just myself but as we get closer to 
> deployment day I'm starting to think that this approach will kill the 
> domain controller once the system is under load (anticipate 100-200 
> simultaneous users max). It is also a possible invitation to a denial of 
> service attack.
> 
> I have been toying with the idea of an xml-based caching mechanism but it 
> would need to be refreshed too often to be useful. If there were a way to 
> hold a network connection open, once authenticated, so that repeated 
> "logins" to the file servers were not necessary, that would be ideal. Does 
> this capability exist? Are the issues I've raised real concerns?
> 
> Thanks,
> Bruce

I'm not entirely sure what you mean Bruce. The jCIFS client does not
directly authenticate with the domain controller. Perhaps I can just
run through how this all works in the context of your question and we
can narrow down the reall issue from there.

When an SmbFile as provoked to retrieve information about it's peer
(the real file on a server somewhere) it asks the socket layer for an
appropriate SmbTransport. If one has already been extablished it uses
that. Then it will ask that SmbTransport for an SmbSession matching the
provided user credentials. If a matching SmbSession for that SmbTransport
has already been established it will use it. An analygous check is used
for an SmbTree (share) on that SmbSession. So this forms a tree of cached
SmbTransports (based on host address and port), SmbSessions (based on
username, password, and domain), and SmbTrees (based on share name).

With repect to your issue, when user credentials do NOT match an
established SmbSession, a new SmbSession is created by sending the
encrypted users credentials to the server hosting the file or directory of
interest. The file server will then contact the domain controller on your
behalf validating the users credentials. If successfull the SmbSession is
created. If not successfull, the SmbSession is failed to be established
and the error is traped, converted to an SmbAuthException and thrown.

So let me just make up a scenario here. Let say you have some servlets
and each provides access to a resource on the same smb server. Different
users will "login" providing different authentication credentials. For
the first user a new SmbTransport followed by and SMbSession and SmbTree
to the resorce will be create. THe second user however will only
need to extablish a new SmbSession and SmbTree. So the SmbTransport
will be shared. If we extend this idea, if with each call the same
user credentials are sublitted the *same SmbSession* will be used to
service the call. This is actually about as efficient as it get's I
think. However, it would not be very polite to keep these SmbTrees,
SmbSessions, and SmbTransports established forever. For this reason they
are dropped after short period of time. The jcifs.smb.client.soTimeout
property might be of particular interest to you. It controls when the
SmbTransport to a server is dropped along with any SmbSessions and
SmbTrees. The default is 15 seconds. You might increase this value.

Now after having said all that there may be an issue. I beleieve servlet
engines use separate ClassLoaders to load the environment for each
individual servlet instance. This will effectively cause an entirely
new jCIFS client instance to be created and may turn out to be horribly
slow, not to mention breaking all of the caching described above. It's
effectively the same as running an entirely new VM for each connection and
is a terrible waste. If you can figure out how to share a ClassLoader
between all of your servlet instances for creating SmbFiles this would
probably turn out to be far more efficient.

Mike





-- 
May The Source be with you.