[jcifs] holding open a connection

Bruce Altner baltner at hq.nasa.gov
Sun Jan 13 17:51:06 EST 2002


I continue to be amazed at the level of help you provide to me and others 
on this list. Thanks for the detailed writeup, which addressed the very 
issues I was concerned about. It seems that the 
SmbTransport/SmbSession/SmbTrees provides just what I needed, although the 
15 seconds timeout seems awfully short. What would the effect of increasing 
this to, say, 10 minutes, do?
Is that an eternity in this context?

As for the possible problems you describe with servlets, I think that we 
are OK. There is only one instance ever created of a given servlet..as 
different users come in new threads are created or are taken from a thread 
pool to handle their requests. But this brings up a related question, 
then...is jCIFS thread safe? Will I need to synchronize jCIFS method calls?


At 05:29 PM 1/12/2002 -0500, you wrote:
>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.
>May The Source be with you.

More information about the jcifs mailing list