[jcifs] threaded network crawler code examples (transport pro blem)

Allen, Michael B (RSCH) Michael_B_Allen at ml.com
Tue Jul 29 10:36:06 EST 2003

> -----Original Message-----
> From:	Christopher R. Hertel [SMTP:crh at ubiqx.mn.org]
> :
> > As I have explained on at least two occations the maxMpxCount is *static*.
> > It is initialized to 1 and it is not increased until the client
> > successfully negotiates with the first server. This is not correct but
> > after the first negotiation the client will handle requests concurrently.
> > So the net effect after a long crawling operation is  ... well nothing.
> For my part, I just want to understand the issue.  It seems that clearing 
> the air on this would be a benefit to everyone.  If nothing else, once I 
> understand it I should be able to explain it in terms that should, I hope, 
> put a stake in its evil heart.
> So... If I understand you, the maxMpxCount static value is upped to match
> the maxMpxCount of the first server, is that right?  Is that the first
> server with which it correctly negotiates?
	Pretty much yes. In Java 'static' means there's only one instance of the
	variable. Think of it as a global variable in C. So maxMpxCount is shared
	by all transports. It's initialized to 1. So you must successfully negotiate
	once to set it to a higher value. It's actually updated each time the client
	negotiates with a server. This is sort of a bug but it will not produce the results
	Dan is claiming to be seeing.

> > What Dan is doing with his modified version of jCIFS is removing the
> > maxMpxCount constraint altogether. This violates the CIFS spec and it will
> > permit the creation of an unlimited number of threads which would likely
> > result in doing little more than wasting large amounts of resources
> > because when you add more threads at some point performance *decreases*.
> The term "session" was used in the earlier message.  That term is overused
> in this area of CIFS, so it would not surprise me if I've got something
> confused.
> MaxMpxCount, as I understand it, should limit the number of multiplexed
> requests (and, therefore, threads) per transport connection to a given
	There is one thread per transport. There may be many SmbSession's to a
	server on that transport.

> server.  If you remove the MaxMpxCount entirely then you could overrun the
> server by sending more requests at one time than it is prepared to handle.  
> Typically, though, servers serialize the requests and handle them anyway.
	How so? I believe all servers handle requests asynchronously. You can
	check this easly using jCIFS. If you sent request A and request B on a
	particular transport you can get a response to B before you get a response
	to A.
> The MID and PID values would result in the response getting back to the
> correct thread.

> Also, if you set up multiple transport-level sessions between the client 
> and the server, and have one thread per, then you've got a kludge on your 
> hands but it would work.
	JCIFS only opens one transport per server (unless it has multiple interfaces
	or multiple servers running on different ports).

> I gotta read Dan's code...
	It's your time.


More information about the jcifs mailing list