[cifs-protocol] [Pfif] FRSRPC: questions about schedule

[Steve French]

I would like clarification on the how the maximum number of cifs
simultaneous requests are enforced, and for which cifs operations they
apply to.  In part this is to avoid triggering a serious problem in
Windows 7 and Windows Vista (when they are run as a server) when
exceeding this limit on simultaneous requests.

What I have observed in my testing:
- Although Windows 7 and Vista allows more than 10 simultaneous SMB
write requests (and Windows 2008 allows more than 50 simultaneous
write requests), Windows 7 and Windows Vista appear to have problems
when 20 or 30 are in flight at one time.
- Windows does not enforce a limit on SMB Negotiate Protocol
- Windows seems to ignore checks on maximum simultaneous requests on
certain handle based operations (SMB writeX in particular) until after
the file is closed (the writes don't get an error, but the next
QueryPathInfo after the file is closed gets an error).

I need to understand on which requests (besides SMB Negotiate) I
should ignore MaxMpxCount.  In particular, SMB Echo, seems like an
obvious choice to ALWAYS allow to be sent by the client, since SMB
Echo is sent to make sure the server is alive (when for example the
limit on simultaneous requests has been reached due to slow opens, or
writes past end of file) and to prevent timeout.   If a client is
restricted from sending SMB Echo then there is no reasonably reliable
mechanism available to determine whether the server is dead or just
hung temporarily processing slow requests.

MS-CIFS is not clear on which commands MaxMpxCount is enforced.

I would like to ignore MaxMpxCount on (sending one of) SMBEcho (where
you could cause data integrity issues if you limited the ability to
check server state up/down) and SMBNegotiate (where it is obviously
not set yet) and SMBOplockBreak responses (since you can't guarantee
the order that these are received/sent from the server relative to
other frames which are being processed, and can cause the server
session to drop if you don't allow the client to send these) to the
server since there is no reasonable mechanism to limit these without
risking problems with prematurely taking down a slow session (perhaps
opens of offline files for example).

It looks like the safest way to handle this is for the client to limit
pending requests to the MaxMpxCount, with the exception of the three
SMB types listed above.

In previous versions of MS-CIFS there were mentions of different
processes, and uids on the negotiated tcp session and their relation
to the MaxMpxCount - and I would also like to verify whether the
limits are considered relative to some combination of the negotiated
tcp session and uid and/or pid as earlier discussions implied (or file
handle, as our testing hinted at).





-- 
Thanks,

Steve