Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: Michael B. Allen (miallen_at_ESKIMO.COM)
Date: Sat Oct 05 2002 - 13:20:47 CDT
On Sat, 5 Oct 2002 11:01:21 -0500
"Christopher R. Hertel" <crhnts.umn.edu> wrote:
> 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
> > >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
> > 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.
> 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
> 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
No. WordCount doesn't include the ByteCount field. So 12 is right.
> optional field). In other words, there are two extra bytes somewhere.
> 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?
> 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/ -)----- crhubiqx.mn.org
> OnLineBook -- http://ubiqx.org/cifs/ -)----- crhubiqx.org
> Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
> contains important info including how to unsubscribe. Save time, search
> the archives at http://discuss.microsoft.com/archives/index.html
-- A program should be written to model the concepts of the task it performs rather than the physical world or a process because this maximizes the potential for it to be applied to tasks that are conceptually similar and more importantly to tasks that have not yet been conceived.
---------------------------------------------------------------- Users Guide http://discuss.microsoft.com/archives/mailfaq.asp contains important info including how to unsubscribe. Save time, search the archives at http://discuss.microsoft.com/archives/index.html