none
Client sending too many requests with SMB2 (2.002) RRS feed

  • Question

  • Hi,

    We are implementing an SMB2 server adhering to dialect 2.002. We successfully completed implementation of all of the verbs except SMB2_CHANGE_NOTIFY. When we are testing against an Win-7 client, we found client continuously sending SMB2_CREATE/SMB2_QUERY_INFO requests even when no operations are being performed. SMB2_CREATE requests are particularly targeted to the directory we are seeing in the explorer. So, we could see this issue even by just mapping a share itself, need not do anything else. Has anyone observed this?

    At this point we are struck as we are not sure if it is due to some improper/incomplete implementation of the verbs we have done till now or because we are not supporting certain features like SMB2_CHANGE_NOTIFY etc.,

    I can send a packet trace if anyone wants to look at it and help us. Please specify the mail id to send the trace.

    Thanks,

    Rahul


    • Edited by S Rahul Kumar Friday, August 1, 2014 3:34 PM Corrected few sentences
    Friday, August 1, 2014 1:55 PM

Answers

  • Hi, Rahul,

    Application layers, in this case Explorer, has no idea of the underlying transport that services its requests.  This is all abstracted many layers above both SMB (all dialects prior to SMB 2.002)  and SMB2/3 (SMB 2.002 and following).  The application is largely going to behave according to its own behavior regardless of the eventual dialect that is used on-the-wire.

    At best, the application only knows the folder is “remote” (not “local”) and may have the ability to implement fewer features if the folder is remote.

    The questions you are raising involves application behavior and is beyond the scope of this forum, which is focused on the support of the Open Specifications (the actual technical documents, such as [MS-CIFS], [MS-SMB] and [MS-SMB2]).  The registry entries mentioned in the article and cited by you belong to Explorer itself, not SMB/SMB2.  Accordingly, these questions would be best asked in an Explorer forum.

    The article does correctly identify, as an aside, the enhancements of SMB2, which was a clean-slate, re-write of the SMB protocol.  Each application request will translate into some corresponding protocol request.  I believe the author’s point was that SMB2 offers more efficiencies (round trips, buffer sizes, compounding, etc.)  Given the same type of response, the application should behave similarly according to its own rules (i.e., if change notify is not supported, then what?).  It should be emphasized that the article, written in 2007, was reflective of Explorer at that time in the author’s frame-of-reference at that moment.  It may not represent the Explorer of today.

    Since you are a developer implementing a SMB2 server, I suspect that you may have a number of questions that are within the scope of the protocol specifications themselves.  We would be happy to work with you on those, as they come up, either through this forum or via the e-mail alias “dochelp (at) microsoft (dot) com”.  However, this forum is not the best source for answers regarding the inner-workings of upper-layer applications like Explorer.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    • Marked as answer by S Rahul Kumar Wednesday, August 20, 2014 9:58 PM
    Tuesday, August 19, 2014 10:57 PM
    Moderator

All replies

  • Hello Rahul -

    Thank you for contacting Microsoft support. I'll be assisting you with this inquiry. Please send your network trace to my attention at - dochelp at Microsoft dot com. I'll work with you through email and update this thread with the outcome.

    Regards.


    Tarun Chopra | Escalation Engineer | Open Specifications Support Team

    Friday, August 1, 2014 4:40 PM
  • Closing notes - We worked offline through dochelp and found that implementing change_notify at server side resulted in traces similiar to windows - windows. Without change_notify, with IE as application on client, nothing was broken; it's just extra PDUs were exchanged with server. Based on our analysis, we have concluded
    that it's an application specific behaviour and NO document change is required.


    Tarun Chopra | Escalation Engineer | Open Specifications Support Team

    Monday, August 11, 2014 5:34 PM
  • Hi Tarun,

    Sorry I was away for a while, hence couldn't respond at earliest.

    As mentioned in the offline discussion the issue was resolved the moment SMB2_CHANGE_NOTIFY was implemented. It did took a bit extra effort for us to figure it out that SMB2_CHANGE_NOTIFY is the issue.

    I am posting some of our observations related to this issue in this thread (not sure if I can do so still).

    According to article " http://blogs.technet.com/b/askperf/archive/2007/09/21/windows-explorer-and-smb-traffic.aspx ", similar issue should be seen even with older dialects like "NT LM 0.12". But we haven't noticed this issue from the same client even when our server adhered to old dialect "NT LM 0.12" and didn't support "NT_TRANSACT_NOTIFY_CHANGE" verb/request.

    Also the same article recommends dialect SMB 2.002 or later to avail some improvements. Does that mean the issue should no longer be seen or has lesser impact with SMB 2.002 or later versions?  If so, we are seeing the issue with SMB 2.002, so completely confused.

    As mentioned in the article, when we set "NoRemoteRecursiveEvents" and "NoRemoteChangeNotify" values on the client side the issue was no longer seen even with "SMB 2.002". So, we feel the issues pointed out in the article are still valid even for "SMB 2.002" or later dialects.

    Thanks,

    Rahul


    S Rahul Kumar

    Tuesday, August 19, 2014 1:01 PM
  • Hi, Rahul,

    Application layers, in this case Explorer, has no idea of the underlying transport that services its requests.  This is all abstracted many layers above both SMB (all dialects prior to SMB 2.002)  and SMB2/3 (SMB 2.002 and following).  The application is largely going to behave according to its own behavior regardless of the eventual dialect that is used on-the-wire.

    At best, the application only knows the folder is “remote” (not “local”) and may have the ability to implement fewer features if the folder is remote.

    The questions you are raising involves application behavior and is beyond the scope of this forum, which is focused on the support of the Open Specifications (the actual technical documents, such as [MS-CIFS], [MS-SMB] and [MS-SMB2]).  The registry entries mentioned in the article and cited by you belong to Explorer itself, not SMB/SMB2.  Accordingly, these questions would be best asked in an Explorer forum.

    The article does correctly identify, as an aside, the enhancements of SMB2, which was a clean-slate, re-write of the SMB protocol.  Each application request will translate into some corresponding protocol request.  I believe the author’s point was that SMB2 offers more efficiencies (round trips, buffer sizes, compounding, etc.)  Given the same type of response, the application should behave similarly according to its own rules (i.e., if change notify is not supported, then what?).  It should be emphasized that the article, written in 2007, was reflective of Explorer at that time in the author’s frame-of-reference at that moment.  It may not represent the Explorer of today.

    Since you are a developer implementing a SMB2 server, I suspect that you may have a number of questions that are within the scope of the protocol specifications themselves.  We would be happy to work with you on those, as they come up, either through this forum or via the e-mail alias “dochelp (at) microsoft (dot) com”.  However, this forum is not the best source for answers regarding the inner-workings of upper-layer applications like Explorer.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    • Marked as answer by S Rahul Kumar Wednesday, August 20, 2014 9:58 PM
    Tuesday, August 19, 2014 10:57 PM
    Moderator
  • Bryan S. Burgin,

    Thank you for the prompt reply. It indeed clarified certain things related to the application behavior.

    regards,

    Rahul


    S Rahul Kumar

    Wednesday, August 20, 2014 9:58 PM