[jcifs] Re: Maximum message size
Christopher R. Hertel
crh at ubiqx.mn.org
Sun Oct 6 01:11:52 EST 2002
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:
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.
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.
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
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
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
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?
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
More information about the jcifs