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

[Allen, Michael B (RSCH)]

> -----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.
> 
	Right.

> 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.

	Mike