[cifs-protocol] [MS-SMB2] Compound/async request handling, 117061615905952

[Moritz Bechler]

Hi,

> 
> Just a quick note that I'm actively researching this for you.  I got a bit of a backlog with the Plugfest, but this is my primary issue now.
Thanks.

> 
> I'll have more research for you later as I'm presently doing a code review.  But, overall, I would be concerned not by just what a Microsoft client or Microsoft server would, could or does do, but that there is general buy-in across the board by all other non-Microsoft clients and servers.  You may be well-served by keeping all edge conditions as simple and straight-forward as possible by avoiding all but the most logical related compounding: where the file handle is inherited by the result of a create as its compound parent.  For instance, I see that the TID and SID of a related compound request is inherited by its parent request, but I'm not sure yet if its parent itself could be the TreeConnect or SessionSetup where the result of that transaction will populate down.  I'll know soon as I'm in that code; I think it will.  However, I guess what I'm saying in this message is that other servers may not have considered this type of transaction (TreeConnect/TreeTransaction) and by packing too many requests together may cause interop issues with other server implementations.
> 

Yes, that is more or less what I concluded (e.g. the
TreeConnect/SessionSetup compounded requests are working as one might
expect with Microsoft servers but weren't with samba) - so they cannot
be used generally. These are pretty easy to spot as they either always
fail or don't. What troubles me more is async processing, because this
is decided by the server and might depend on special conditions. The
examples I have listed are cases specified to be processed
asynchronously so they can also be avoided - but following the logic I
see in product behavior for these something as simple as

CREATE/READ/CLOSE (or WRITE,IOCTL,QUERY_INFO,... instead of the READ)

might suddenly fail if the server decided to go async for the READ (say,
that it might choose async when the backend read hits some time limit)
and they are not handled like a CREATE is. These would probably be
considered server bugs if they failed as they are likely to be actually
used by clients. Right now it seems like it is up to the client to guess
which requests are handled in which way (whether they can go async and
whether they will fail if they are not last in a chain).


regards

Moritz

-- 
AgNO3 GmbH & Co. KG, Sitz Tübingen, Amtsgericht Stuttgart HRA 728731
Persönlich haftend:
Metagesellschaft mbH, Sitz Tübingen, Amtsgericht Stuttgart HRB 744820,
Vertreten durch Joachim Keltsch