[jcifs] max_xmit - why 4280?

Del Merritt del at alum.mit.edu
Thu Mar 11 15:46:32 MST 2010

On 03/11/2010 05:28 PM, Michael B Allen wrote:
> On Thu, Mar 11, 2010 at 12:14 PM, Del Merritt <del at alum.mit.edu> wrote:
>> A question was raised a while back about getting a DcerpcException with the
>> message "Fragmented request PDUs currently not supported":
>> http://article.gmane.org/gmane.network.samba.java/6745/match=fragmented+request+pdus
>> 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.
> Hi Del,
> Those are just observed values.

Sorry - would you elaborate?

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

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.


More information about the jCIFS mailing list