Home » Microsoft TechnologiesRSS

SMB2 Specification for Durable Open (Specs conflict)

Hello All,

I would just like to know what will server do if a client tries to reconnect (after network disruption) and then tries to recover a durable file (using SMB2_CREATE_DURABLE_HANDLE_RECONNECT create context).

 

From 3.3.7.1 Handling a Transport Disconnect (http://msdn.microsoft.com/en-us/library/cc246790%28v=PROT.13%29.aspx)

<<snip>>

If Open.OplockLevel is equal to SMB2_OPLOCK_LEVEL_BATCH, Open.OplockState is equal to Held, and Open.IsDurable is TRUE, the open MUST be preserved for a reconnect. The open MUST be removed from Session.OpenTable , Open.Connection is set to NULL, Open.Session is set to NULL, Open.TreeConnect is set to NULL, and Open.DurableOpenTimeOut is set to the current time plus an implementation-specific<297> default value.

<<snip>>

This clearly specifies that " Open.Connection is set to NULL" however in:

 

3.3.5.9.7 Handling the SMB2_CREATE_DURABLE_HANDLE_RECONNECT Create Context (http://msdn.microsoft.com/en-us/library/cc246784%28v=PROT.13%29.aspx)

<<snip>>

The processing changes involved for this create context are:

The server MUST look up an existing open in the GlobalOpenTable by doing a lookup with the FileId.Persistent portion of the create context.

If the lookup fails, the server MUST fail the request with STATUS_OBJECT_NAME_NOT_FOUND and proceed as specified in "Failed Open Handling" in section 3.3.5.9 .

If Open.IsDurable is FALSE and Open.IsResilient is FALSE or unimplemented, the server MUST fail the request with STATUS_OBJECT_NAME_NOT_FOUND and proceed as specified in "Failed Open Handling" in section 3.3.5.9 .

If Open.Connection is NULL, the server MUST fail the request with STATUS_OBJECT_NAME_NOT_FOUND and proceed as specified in "Failed Open Handling" in section 3.3.5.9 .

.... ....

<<snip>>

 

QUESTION:

Upon disconnection, the server will set Open.Connection to NULL but maintain that Open object.

But when client [reconnects and] sends SMB2_CREATE request (with SMB2_CREATE_DURABLE_HANDLE_RECONNECT create context) the server will check if that Open object has Connection. If non, the operation fails.

 

 

Is my understanding wrong?

 

Thank you very much!

 

 

6 Answers Found

 

Answer 1

Hi Z33p_it,

Thank you for your question  regarding [MS-SMB2] 3.3.5.9.7 Handling the SMB2_CREATE_DURABLE_HANDLE_RECONNECT Create Context.  One of the Open Specifications team will contact you shortly to discuss your questions.

Best regards,

Tom Jebo
Senior Support Escalation Engineer
Microsoft Open Specifications

 

Answer 2

Hello Sir Tom,

Thank you very much for your support!

This is a great help for me.

 

Regards,

z33p_it

 

Answer 3

Z33p_it,

 

[MS-SMB2] section  3.3.7.1 “Handling a transport  Disconnect” has undergone some maintenance.  The paragraph you cited has been removed  and replaced with “If the open  is not being preserved  for a reconnect, then Open.LocalOpen MUST be closed. The open is removed from Session.OpenTable, and the open is freed. Then the session  MUST be removed from GlobalSessionTable and freed.”

 

                We propose that Section 3.3.7.1 read in a future release, in its entirety, the text below.  The first bullet point remains the same, but the last three were added, including the last point, which is the new text related to your issue.

 

3.3.7.1 Handling a Transport Disconnect

 

When the transport indicates a disconnect, the server  MUST enumerate the sessions established over this connection  in GlobalSessionTable.

For every such session in the table, the server MUST deregister every tree connect object  in Session.TreeConnectTable by invoking the event, as specified in [MS-SRVS] section 3.1.6.7. The tree connect MUST then be removed from Session.TreeConnectTable and freed.

For every open in Session.OpenTable:

 

-If the server implements SMB 2.1 and supports leasing and if Open.IsResilient is TRUE, the open MUST be preserved for a reconnect. The open MUST be removed from Session.OpenTable, Open.Connection is set  to NULL, Open.Session is set to NULL, Open.TreeConnect is set to NULL, and Open.ResilientOpenTimeOut is set to the current  time plus Open.ResiliencyTimeout.

 

- If Open.OplockLevel is equal  to SMB2_OPLOCK_LEVEL_LEASE, Lease.LeaseState contains SMB2_LEASE_HANDLE_CACHING, Open.OplockState is equal to Held, and Open.IsDurable is TRUE, the open MUST be preserved for a reconnect. The open MUST be removed from Session.OpenTable, Open.Connection is set to NULL, Open.Session is set to NULL, Open.TreeConnect is set to NULL, and Open.DurableOpenTimeOut is set to the current time  plus an implementation-specific<295> default  value.

 

-If Open.OplockLevel is equal to SMB2_OPLOCK_LEVEL_LEASE, but Lease.LeaseState does not contain SMB2_LEASE_HANDLE_CACHING, Open.OplockState is equal to Held, and Open.IsDurable is TRUE, the open MUST be preserved for a reconnect. The open MUST be removed from Session.OpenTable, Open.Connection is set to NULL, Open.Session is set to NULL, Open.TreeConnect is set to NULL, and Open.DurableOpenTimeOut is set to the current time plus an implementation-specific<296> default value.

 

-If the Open is not being preserved for a reconnect, then Open.LocalOpen MUST be closed. The open is removed from Session.OpenTable, and the open is freed. Then the session MUST be removed from GlobalSessionTable and freed.

 

Any requests in Connection.RequestList MUST be canceled and freed.

 

Finally, the connection MUST be freed.

 

End of 3.3.7.1

 

Answer 4

Hello Sir Bryan,

 

Thank you very much for your answer.

I have follow-up question. I apologize for the inconvenience.

 

#######

For an example scenario, a durable  open was requested (without combination with lease) and was granted, but then disconnection  happened...

(NOTE: Dialect only being used is 2.002 NOT 2.1 -so no support with Leasing and file  resiliency)

 

Then under the new [proposed] Section 3.3.7.1, such scenario will be handled by the cases below:

  "Any requests in Connection.RequestList MUST be canceled and freed.

   Finally, the connection  MUST be freed."

 

I assume that in this case, "Open.Connection" will still be freed.

(should I assume that this will be set  to NULL?)

 

Therefore it may still fail  in SMB2_CREATE_DURABLE_HANDLE_RECONNECT.

Because according to the specification  of DURABLE HANDLE RECONNECT, server  must fail if the corresponding "connection" of the open  object (being referred by the FID in the DURABLE HANDLE RECONNECT request) is NULL.

 

Thank you very much in advance!

 

Regards

 

Answer 5

Z33p_it,

I'll research this for you and respond as soon as I can.

 

Answer 6

Z33p_it,

 

We have completed our review.  You are correct that if connection  is freed, then it shouldn’t be maintained as Open.Connection, since it wouldn’t be valid if freed.  Instead of the solution you proposed (to set  Open.Connection to NULL), we propose changing the text at 3.3.7.1 “Handling a Transport Disconnect” from “Finally, the Connection MUST be freed” To “Finally, the Connection MUST be freed, if it is not referenced by any object.”  We also propose removing bullet #4 at 3.3.5.9.7 “Handling the SMB2_CREATE_DURABLE_HANDLE_RECONNECT Create Context” that reads “4.  If Open.Connection is NULL, the server  MUST fail  the request  with STATUS_OBJECT_NAME_NOT_FOUND and proceed  as specified in "Failed Open Handling" in section  3.3.5.9.”  We would also add these two bullet points to 3.3.5.9.7 “Handling the SMB2_CREATE_DURABLE_HANDLE_RECONNECT Create Context” (I included the existing  step before and after the new text for reference):

 

7.  The server MUST set the Open.Connection to refer to the connection that received this request

<new text>

8.  The server MUST set the Open.Session to refer to the session  that received this request.

9.  The server MUST set the Open.TreeConnect to refer to the tree connect that received this request.

<end new text>

11.The server MUST regenerate Open.FileId (the volatile portion  of the SMB2_FILEID).

 

 
 
 

<< Previous      Next >>


Microsoft   |   Windows   |   Visual Studio   |   Follow us on Twitter