Remove samba specific read/write sizes

[Stefan (metze) Metzmacher]

Hi Jeremy,

while working on adding smb2 support to source3/libsmb
I noticed the strange write and read sizes we're using for
SMB1.

I've done some tests and found out that windows servers,
support writex (with CAP_LARGE_WRITEX from the server)
with sizes up to 131007 (0x1FFBF), resulting in a pdu size of 0x1FFFF.

I'm wondering why we just use 65534 (0xFFFE) against windows,
while using 130048 (0x1FC00) against Samba.

ReadX (with CAP_LARGE_READX) has a bug in windows and truncates the read
size
to 0xFFFF. We also implement this bug, unless the client sends
CAP_LARGE_READX
in the first session setup. But relying on CAP_LARGE_READX from the
client is wrong.
CAP_LARGE_READX is only send by the server in the negprot response.

So we have a special behavior for samba clients, which is bad.
It makes the code much more complex and captures can't be compared.

If samba as client uses the unix extentions, we can serve much larger reads,
so I think we should stop using the CAP_LARGE_READX samba behavior,
but in the server we need to still support old 'smbclient' binaries,
which would break otherwise.

In future we'll get SMB 2.10 LARGE_MTU support and get very large reads
without unix extentions.

Are you ok, which the attached patches?
http://gitweb.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master3-libsmb

There're a patch which causes cli_pull/push() to round the chunk size to
a page size
of 1024 bytes, but I'm not sure if we really need that one, or if we
better read and
write as much as we can.

metze
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cli-read-write-sizes-01.patches.txt
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20110912/c6ce3f1d/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20110912/c6ce3f1d/attachment.pgp>