Sanity check.

[Christopher R. Hertel]

Just a quick sanity check, if any of you have the time.  In my book I'm
trying to describe the MaxBufferSize and MaxRawSize fields in the NegProt
response.  I neither want or need to go into great depth, but I do need to
be as close to correct in my descriptions as SMB allows.  If anyone has
any constructive criticism on the notes below please send it along.

Looking forward to your replies.

Chris -)-----


MaxBufferSize

    MaxBufferSize is the size (in bytes) of the largest message that the
    server can receive.  Keep in mind that the transport layer will
    fragment and defragment packets as necessary. It is, therefore,
    possible to send very large SMBs and let the lower layers worry about
    ensuring safe, fast, reliable delivery.

    How big can an SMB message be?

    In the NT LM 0.12 dialect, the MaxBufferSize field is an unsigned
    longword. As described much earlier on, however, the Length field in
    the NBT SESSION MESSAGE is 17-bits wide and the naked transport header
    has a 24-bit Length field. So the session headers place slightly more
    reasonable limits on the maximum size of a single SMB message.

MaxRawSize

    This is the maximum size of a raw data buffer.

    The X/Open doc describes the READ RAW and WRITE RAW SMBs, which were
    introduced with the Extended 1.0 version of SMB (the MICROSOFT
    NETWORKS 3.0 and LANMAN1.0 dialects). These were a speed hack. For a
    large read or write operation, the first message would be a proper
    SMB, but subsequent messages would be sent in "raw" mode, with no SMB
    or session header. The raw blocks could be as large as MaxRawSize
    bytes in length. Once again, the transport layer was expected to take
    care of fragmentation/defragmentation and the re-sending of any lost
    packets.

    Raw mode is not used much any more. Among other things, it conflicts
    with message signing because there the raw messages have no header in
    which to put the MAC signature. Thus, the field is considered obsolete.


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