|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: Conrad Minshall (conrad_at_APPLE.COM)
Date: Fri Oct 04 2002 - 17:09:28 CDT
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.
(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.
-- Conrad Minshall ... conradapple.com ... 408 974-2749 Alternative email addresses: rad
acm.org and conrad
mac.com.
---------------------------------------------------------------- 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 ]
apple.com ... 408 974-2749
Alternative email addresses: rad