[jcifs] Re: Maximum message size

[Christopher R. Hertel]

Conrad Minshall wrote:
> 
> At 9:59 AM -0700 10/4/02, Christopher R. Hertel wrote:
> >Conrad Minshall wrote:
> >:
> >> CAP_LARGE_* potentially get you over 64k, while the ordinary maximums
> >> will be under 64k, and possibly *way* under 64k, depending on the
> >> parties involved.  That's my recollection anyway, from performance
> >> tuning earlier this year.
> 
> Oops.  I should never post after midnight :(
> 
> >That's what I was thinking.  You could get 65535 bytes total (including
> >the four byte session layer header) without CAP_LARGE_*.  The data field
> >can have 65535 bytes.
> 
> My recollection is better in the daytime.  CAP_LARGE_* means the server
> supports up to 64k using the SMB_COM_*_ANDX rpcs.  As it says in specs.

Actually, that's the problem.  The SNIA doc says two contradictory things.

> (In practice my client needed a hack to limit client requests to slightly
> less than 64k - for one of the servers, I don't recall which now, but I
> see I used 60k.)  The benefit of CAP_LARGE_* is when the server's max
> buffer size is small.  For instance I have an NT box here which claims
> 4356 as the max buffer size, but sets the large read capability.  (By
> the way it doesn't set large write.)  The 4356 limited the client max
> buffer size specified in my session setup and so reads were too slow.
> I didn't want to use "raw" reads, so the "large" read capability seemed
> the only way to decent performance.

Okay, there are a lot of things about that which I don't understand.  Pardon
my being dense, but what I *think* you're saying is not quite the same as
what I *think* the SNIA doc is saying.  ...I think.

Just to summarize some junk for reference:

  NegProt_Response.Capabilities
    CAP_LARGE_FILES  - this doesn't count.  It has to do with 64-bit file
                       offsets.  Ignore for now.
    CAP_LARGE_READX  - Server supports large reads.
    CAP_LARGE_WRITEX - Server supports large writes.

  NegProt_Response.MaxBufferSize
    The size of the largest buffer that the server has set aside for
    receiving messages.  This value is reported by the server to the
    client.  The client should not (in general) send anything larger.

  SessionSetupAndX.MaxBufferSize
    The size of the largest buffer that the client has set aside for
    receiving messages.  This value is reported by the client to the
    server.  The server should not (in general) send anything larger.

On page 70 of the SNIA doc (where SMB_COM_READ_ANDX is described) we have
this blurb:

  If CAP_LARGE_READX was indicated by the server in the negotiate
  protocol response, the request's MaxCount field may exceed the
  negotiated buffer size if Fid refers to a disk file. The server may
  arbitrarily elect to return fewer than MaxCount bytes in response.

That jibes with what you said.  So far so good.

Now here's the wierd bit...

Also on page 70 of the SNIA doc we have the record layout for the
SMB_COM_READ_ANDX request:

  UCHAR  WordCount;    Count of parameter words = 10 or 12
  UCHAR  AndXCommand;  Secondary (X) command; 0xFF = none
  UCHAR  AndXReserved; Reserved (must be 0)
  USHORT AndXOffset;   Offset to next command WordCount
  USHORT Fid;          File handle
  ULONG  Offset;       Offset in file to begin read
  USHORT MaxCount;     Max number of bytes to return
  USHORT MinCount;     Reserved for obsolescent requests
  ULONG  MaxCountHigh; High 16 bits of MaxCount if CAP_LARGE_READX;
                       else MUST BE ZERO
  USHORT Remaining;    Reserved for obsolescent requests
  ULONG  OffsetHigh;   Upper 32 bits of offset (only if WordCount is 12)
  USHORT ByteCount;    Count of data bytes = 0

The first thing I note about that structure is that the type of the
MaxCountHigh has *got* to be wrong.  The description of the field says
that it contains the "High 16 bits of MaxCount".  We don't need a 32-bit
field to store 16 bits.

Also the description of WordCount for this block says that the block is 10
or 12 words long (20 or 24 bytes).  If I count up the bytes following
WordCount I get 26, or 22 if I leave out the OffsetHigh field (which is the
optional field).  In other words, there are two extra bytes somewhere.  That
supports the theory that the MaxCountHigh field should be a USHORT, not a
ULONG.

Even so, we still have a problem.

  Why would we need the "High 16 bits of MaxCount if CAP_LARGE_READX"
  unless we could send more than 65535 bytes?

Chris -)-----

PS.  Thanks, everyone.  This is all very helpful.

-- 
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org