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

No. WordCount doesn't include the ByteCount field. So 12 is right.

> 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/ -)----- 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

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]