[jcifs] RE: threaded network crawler code examples (transport problem)

Dan Dumont Dan at canofsleep.com
Mon Jul 28 14:26:49 EST 2003

I just sent this message to the list.  It is awaiting approval because of
the attachment size, sorry bout that.  It's a bit big.



I forgot to mention that you should comment out the following code.  It's a
jdk1.4 workaround to jcifs taking forever to connect to a host that's not

Sorry, I caught this after posting.


      SocketAddress socketAddress = new InetSocketAddress(ip, 139);

      Socket sock = new Socket();

      sock.connect(socketAddress, timeout);



-----Original Message-----
From: Dan Dumont [mailto:Dan at canofsleep.com] 
Sent: Monday, July 28, 2003 12:18 AM
To: 'jcifs at lists.samba.org'
Subject: threaded network crawler code examples (transport problem)


Ok, Chris said I should post an example here so I am.  Now, this problem
might not be apparent on small networks.  You really need a large network to
test it.



The source files are in the jar, I am using an older version of jcifs that I
modified, yes, but no one has been talking to me about this issue so I am
assuming it has gone uncorrected in the newer version.


You can run the network crawler by typing    java -jar jcifstest.jar ipfile


Ex      java -jar ips.txt 70




Now, this is a description of the problem with the jcifs package

The maxmpxcount variable gets decremented when it meets a deficient server.
However, this adversely affects the performance (actually that running) of
any other thread that wants to use the transport.  


Mike has told me that you don't want to have a transport for each thread,
but that is the only solution that will make this code work correctly.  I
modified the transport to never decrement maxmpxcount and while may get a
lot of transports, you get the performance you expect from multiple threads
running independently.


The multithreaded example that Mike has provided works great with the
unmodified transport because it only deals with one host.   Whereas this
code comes into contact with a wide variety of hosts.


To see the problem in its entirety, you may need a large network.  (it's
been a while since ive tested using the original package, and I forget if it
needed actual hosts that time out, or if it will err the same way with non
existent hosts. I believe the latter to be the case)


But in any case, try the current version of jcifs and let my code fly on a
file filled with 10.0.*.* or something along that size.   Set the thread
count around 80.


I have included a sample ip text file, and again, the source is in the jar
along with the modified jcifs that I am using.



-------------- next part --------------
HTML attachment scrubbed and removed

More information about the jcifs mailing list