<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
On 03/12/2010 10:15 AM, Michael B Allen wrote:
<blockquote
cite="mid:78c6bd861003120715r2f403ef9oe4e28bf87b7eaf6@mail.gmail.com"
type="cite">
<pre wrap="">On Thu, Mar 11, 2010 at 5:46 PM, Del Merritt <a class="moz-txt-link-rfc2396E" href="mailto:del@alum.mit.edu"><del@alum.mit.edu></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 03/11/2010 05:28 PM, Michael B Allen wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Thu, Mar 11, 2010 at 12:14 PM, Del Merritt <a class="moz-txt-link-rfc2396E" href="mailto:del@alum.mit.edu"><del@alum.mit.edu></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">A question was raised a while back about getting a DcerpcException with the
message "Fragmented request PDUs currently not supported":
<a class="moz-txt-link-freetext" href="http://article.gmane.org/gmane.network.samba.java/6745/match=fragmented+request+pdus">http://article.gmane.org/gmane.network.samba.java/6745/match=fragmented+request+pdus</a>
I am seeing this too, and it appears that the values for max_xmit and
max_recv are hardcoded to 4280 in jcifs/dcerpc/DcerpcHandle.java; I'm using
JCIFS 1.3.14 as a baseline.
Is there a reason for this limit? Is it something that should be negotiated
and just hasn't happened yet? I'm still learning the ins and outs of CIFS
as I am porting JCIFS to a J2ME environment.
</pre>
</blockquote>
<pre wrap="">Hi Del,
Those are just observed values.
</pre>
</blockquote>
<pre wrap="">
Sorry - would you elaborate?
</pre>
</blockquote>
<pre wrap="">
The values for max_xmit and max_recv are values that Windows clients
have been observed using. Windows is as Windows does. So we just copy
what Windows does and you should too.
</pre>
</blockquote>
<br>
Fair 'nuf.<br>
<br>
<blockquote
cite="mid:78c6bd861003120715r2f403ef9oe4e28bf87b7eaf6@mail.gmail.com"
type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Note that JCIFS supports fragmented response PDUs. It just doesn't
support fragmented *request* PDUs. It's somewhat unusual for a DCERPC
request to contain a lot of data. Usually it's the response that is
big.
</pre>
</blockquote>
<pre wrap="">
I am trying to send a large chunks of data (that when assembled will be
a "file") to another system that I discover via JCIFS. To minimize
overhead - mostly in the form of time spent - on the sending host, I'm
trying to make those chunks as big as is reasonable.
</pre>
</blockquote>
<pre wrap="">
I think you're confused. The DCERPC layer has nothing to do with
sending files. </pre>
</blockquote>
<br>
<br>
I probably am somewhat confused. What I am trying to do is to discover
systems with printers and then send data - a "file" - to a printer in
what is considered "RAW" mode.<br>
<br>
I do the send-the-data step currently thus:<br>
<ol>
<li>get a DcerpcHandle to the server's printer <br>
</li>
<li>loop sending the data with a class that extends DcerpcMessage in
4Kish chunks</li>
</ol>
The chunk size is dependent on max_xmit since I am using the DCERPC
layer. Sorry that's greatly simplified/reduced. To replicate the code
here would require lots of classes. At the protocol level - e.g., what
wireshark shows - I'm basically doing:<br>
<ol>
<li>a DCERPC bind to the host's \PIPE\spoolss</li>
<li>a SPOOLSS\OpenPrinter</li>
<li>a SPOOLSS\StartDocPrinter<br>
</li>
<li>a bunch of SPOOLSS/WritePrinter calls, and finally, when the data
is drained,<br>
</li>
<li>closing things down when it's all done<br>
</li>
</ol>
What would you recommend as an alternative? <br>
<br>
Thanks,<br>
-Del<br>
<br>
<blockquote
cite="mid:78c6bd861003120715r2f403ef9oe4e28bf87b7eaf6@mail.gmail.com"
type="cite">
<pre wrap="">The size of file stream writes is somewhat controlled
by the jcifs.smb.client.snd_buf_size and jcifs.smb.client.rcv_buf_size
properties. But you really don't want to mess with those values. Even
if you see an increase in performance by increasing the size of those
values, it is very possible that in another environment the result
could be a significant decrease in overall throughput. And in general,
you really should not change values of properties if you're not sure
about what they do.
Mike
</pre>
</blockquote>
<br>
</body>
</html>