[prev in list] [next in list] [prev in thread] [next in thread]
List: cifs-protocol
Subject: Re: [cifs-protocol] Precisions for FRSRPC
From: Matthieu Patou <mat () samba ! org>
Date: 2011-10-21 21:08:44
Message-ID: 4EA1DF5C.9090804 () samba ! org
[Download RAW message or body]
On 27/09/2011 19:06, Edgar Olougouna wrote:
> Matthieu,
>
> Question 3:
>
> The documentation didn't explain very well or I didn't understand how to find the \
> parent of a replicated object, after my investigation it seems that the objectGUID \
> of replicated object is the same on all the replica and a downstream partner use \
> this information when it needs to compare 2 files/folders for modifications or when \
> it needs to find where to store/change/delete a file or folder. It seems also that \
> for the sysvol replica, it's the GUID of the NTDS object that is used as GUID of \
> the frsRootPath. Can you confirm or precise the correct information about this ?
>
> Response:
>
> Please let me know whether the following answers Question #3, otherwise please \
> further detail your clarification request and provide references in MS-FRS1. There \
> are Guid details of a replicated object that propagate in a change order. Details \
> of FileGuid, OldParentGuid and NewParentGuid are documented in MS-FRS1 Sections \
> 3.3.4.4.6 CMD_REMOTE_CO and 3.3.4.4.7 CMD_SEND_STAGE (see references).
> References:
>
> MS-FRS1
>
> 3.3.4.4.6 COMM_COMMAND Is CMD_REMOTE_CO
> http://msdn.microsoft.com/en-us/library/714aa502-fbaa-4a03-a386-28dbb607080e(v=PROT.13)
>
> Both CMD_REMOTE_CO_DONE and CMD_SEND_STAGE MUST include a change order in their \
> packets. Following are common details for those change orders (these details are \
> not listed in sections 3.3.4.4.6.1 and 3.3.4.4.6.2). …
> FileGuid: MUST be CO_IN.FileGuid.
> OldParentGuid: MUST be the local replica tree root GUID if the parent is the \
> replica tree root; otherwise, set it to CO_IN.OldParentGuid.
> NewParentGuid: MUST be the local replica tree root GUID if the parent is the \
> replica tree root; otherwise, set it to CO_IN.NewParentGuid.
>
> 3.3.4.4.7 COMM_COMMAND Is CMD_SEND_STAGE
> http://msdn.microsoft.com/en-us/library/dd340857(v=PROT.13).aspx
> ChangeOrderCommand MUST be copied from the CMD_SEND_STAGE, except for the \
> following fields: …
> • COMM_REMOTE_CO.OldParentGuid MUST be set to the local replica tree rootGUID if \
> the parent is the replica tree root; otherwise, keep the original value from the \
> CMD_REMOTE_CO packet received. • COMM_REMOTE_CO.NewParentGuid MUST be set to the \
> local replica tree root GUID if the parent is the replica tree root; otherwise, \
> keep the original value from the CMD_REMOTE_CO packet received.
> 3.1.1.5 IDTable
> http://msdn.microsoft.com/en-us/library/dd358590(PROT.13).aspx
>
> Object ID: GUID assigned to each file or folder. The Object ID uniquely identifies \
> the file or folder within the replica set and across all members of the replica \
> set. Parent Object ID: Object ID of the folder that contains this object.
> Version Number: Identifies the version of the file or folder. The file version \
> number is a monotonically increasing unsigned long that gets incremented each time \
> the file or folder has changed and is replicated. The file version number is \
> updated each time the file is closed after being modified. The server uniquely \
> identifies the files on the local file system. If NTFS is being used, the server \
> uses the reference number as the unique key to identify the files. If this protocol \
> is being implemented on a different file system, the vendor is free to choose a way \
> to uniquely identify a file in a file system.<31>
> 3.1.1.3 Member Object (Replica Member Object)
> http://msdn.microsoft.com/en-us/library/dd358146(v=PROT.13).aspx
> Replica Tree Root GUID: Object ID for the replica tree root in the IDTable.
>
> 1.1 Glossary
> http://msdn.microsoft.com/en-us/library/2e457199-2dc1-46c3-8aa6-b2d8e016f95c(v=PROT.13)#file_guid
>
> File GUID: An identifying property of a file or folder in a replica tree. FRS \
> creates and manages fileGUIDs, which, along with the file version number and file \
> event time, are stored in the IDTable. Each file and folder stores its file GUID as \
> part of its attributes; therefore, corresponding files and folders across all \
> replica set members have the same file GUID.
Yes presented like this it's more obvious.
Thanks.
Matthieu.
> Regards,
> Edgar
>
> -----Original Message-----
> From: Edgar Olougouna
> Sent: Thursday, September 22, 2011 9:57 AM
> To: 'mat@samba.org'; 'pfif@tridgell.net'; 'cifs-protocol@samba.org'
> Subject: RE: Precisions for FRSRPC
>
> Matthieu,
>
> Question 2:
>
> In paragraph "2.3.1.2 NTFRS Replica Set Object" msFRS-Topology-Pref:
> Attribute not used by FRS.
> It seems that it's as when you create a replication of a DFS replica this attribute \
> is set and changing the value in the interface has changed the value stored in the \
> AD database. Does this mean that what ever the topology is set to the replication \
> scheme is always the same ? If so can you clarify it or point me to the place of \
> the documentation where it's specified ? Is it the same for FRS replication of DFS \
> replica and for SYSVOL ?
> Answer:
>
> As a result of our investigation on this inquiry, a future release of MS-FRS1 will \
> be updated to reflect the following description. First, let's me answer your \
> questions, and then I will provide more details.
> Q 2.a) Does this mean that whatever the topology is set to the replication scheme \
> is always the same ? Ans. msFRS-Topology-Pref attribute of NTFRS Replica Set \
> Object is used by FRS in Windows Server 2003 (W2K3) and not beyond that, and it is \
> used to decide what connection to establish (see details).
> Q 2.b) If so can you clarify it or point me to the place of the documentation where \
> it's specified ? Ans. We will update MS-FRS1 as necessary to clarify the use of \
> attribute msFRS-Topology-Pref in W2k3.
> Q 2.c) Is it the same for FRS replication of DFS replica and for SYSVOL?
> Ans. Yes, there is no related specific behavior for DFS replication and SYSVOL \
> replication.
> Details on ms-FRS-Topology-Pref Attribute in Windows Server 2003
> ------------------------------------------------------------------------------------------
> The ms-FRS-Topology-Pref attribute is a setting used for NTFRS topology selection. \
> When an FRS member gets added to - or deleted from - the replica set, this \
> attribute is referred, and adjustments are made to the connections between the \
> existing FRS members in the replica set. The possible values and their meaning can \
> be described as follows: Value Description
> 1 FRS_RSTOPOLOGYPREF_RING
> FRS sorts members based on their ‘site', such that members on the same site are \
> neighbors. Then, for any two neighbors N1 and N2, it establishes a connection from \
> N1 to N2, and from N2 to N1. 2 FRS_RSTOPOLOGYPREF_HUBSPOKE
> The msFRS-Hub-Member attribute identifies a special node called a ‘hub' node \
> (let's denote this node H). In this replication topology, for each member M such \
> that M is not a hub node, there is a connection established between M and H, and \
> between H and M.
> NOTE: The msFRS-Hub-Member attribute will be updated in the protocol document. It \
> is currently described as ‘Attribute not used by FRS', similarly to \
> ms-FRS-Topology-Pref. 3 FRS_RSTOPOLOGYPREF_FULLMESH
> Connections are established between all pairs of nodes.
> 4 FRS_RSTOPOLOGYPREF_CUSTOM
> The user chooses the connections through the UI.
>
> Let me known whether this helps.
>
> Thanks,
> Edgar
>
> -----Original Message-----
> From: Edgar Olougouna
> Sent: Wednesday, September 14, 2011 4:22 PM
> To: 'mat@samba.org'; pfif@tridgell.net; cifs-protocol@samba.org
> Subject: RE: Precisions for FRSRPC
>
> Matthieu,
>
> Please find my update as follows.
>
> Question 1:
>
> In paragraph "2.2.3.9 DATA_EXTENSION_RETRY_TIMEOUT" we have information about \
> FirstTryTime and Count related to REMOTE_CO command, but it seems that it's not \
> explained how the client should use this information nor when the server should \
> increase the Count attribute.
> Answer:
>
> Upon investigation, I have filed a technical document bug on this. The following \
> logic will reflect in a future release of the MS-FRS1 document. The following \
> describes the retry timeout processing rules of FirstTryTime and Count when \
> handling change orders, from client and server sides.
> At the client side(downstream partner) the FirstTryTime and Count fields are used \
> when the downstream has a CO (let us call it X) which it is not able to install \
> because the CO corresponding to its parent folder has not arrived/has not been \
> installed. In this case, it checks the following conditions: a. \
> (X->Count> MaxRetryCount) b. (CurrentTime - X->FirstTryTime> \
> MaxRetryTimeOut) If either of a. or b. is true, then we abort installing X, remove \
> the ID table entry created for the file/folder corresponding to it (if any), and \
> remove the pre-install file/folder corresponding to it (if any).
> At the server side(upstream partner), for every CO X in the outbound log such that \
> X has finished installing on that machine and X is not a Directed CO (where the \
> Directed CO flag is defined in 2.2.3.2 Change_Order_Command), if CurrentTime - \
> X->FirstTryTime> OutlogChangeHistoryTime (this is defined in 3.1.1 Abstract Data \
> Model) , then X is removed from the outbound log and it's corresponding staging \
> file is deleted. If the GVSN of X is not present in the Version Vector object \
> (where the Version Vector object is defined in the glossary), then it is added it \
> to it.
> Question 2:
>
> In paragraph "2.3.1.2 NTFRS Replica Set Object" msFRS-Topology-Pref:
> Attribute not used by FRS. It seems that it's as when you create a replication of a \
> DFS replica this attribute is set and changing the value in the interface has \
> changed the value stored in the AD database. Does this mean that what ever the \
> topology is set to the replication scheme is always the same ? If so can you \
> clarify it or point me to the place of the documentation where it's specified ? Is \
> it the same for FRS replication of DFS replica and for SYSVOL ?
> Update:
>
> I have investigated this issue and filed a technical document bug. I am working \
> with the product team and will update you as soon as I have news.
> Question 3:
>
> The documentation didn't explain very well or I didn't understand how to find the \
> parent of a replicated object, after my investigation it seems that the objectGUID \
> of replicated object is the same on all the replica and a downstream partner use \
> this information when it needs to compare 2 files/folders for modifications or when \
> it needs to find where to store/change/delete a file or folder. It seems also that \
> for the sysvol replica, it's the GUID of the NTDS object that is used as GUID of \
> the frsRootPath. Can you confirm or precise the correct information about this ?
>
> Update:
>
> I am still investigating this and will update you soon.
>
> Regards,
> Edgar
>
> -----Original Message-----
> From: Matthieu Patou [mailto:mat@samba.org]
> Sent: Friday, September 02, 2011 6:13 PM
> To: Interoperability Documentation Help; pfif@tridgell.net; cifs-protocol@samba.org
> Subject: Precisions for FRSRPC
>
> Hello Dochelp,
>
>
> In paragraph "2.2.3.9 DATA_EXTENSION_RETRY_TIMEOUT" we have information about \
> FirstTryTime and Count related to REMOTE_CO command, but it seems that it's not \
> explained how the client should use this information nor when the server should \
> increase the Count attribute.
>
> In paragraph "2.3.1.2 NTFRS Replica Set Object" msFRS-Topology-Pref:
> Attribute not used by FRS. It seems that it's as when you create a replication of a \
> DFS replica this attribute is set and changing the value in the interface has \
> changed the value stored in the AD database. Does this mean that what ever the \
> topology is set to the replication scheme is always the same ? If so can you \
> clarify it or point me to the place of the documentation where it's specified ? Is \
> it the same for FRS replication of DFS replica and for SYSVOL ?
>
> The documentation didn't explain very well or I didn't understand how to find the \
> parent of a replicated object, after my investigation it seems that the objectGUID \
> of replicated object is the same on all the replica and a downstream partner use \
> this information when it needs to compare 2 files/folders for modifications or when \
> it needs to find where to store/change/delete a file or folder. It seems also that \
> for the sysvol replica, it's the GUID of the NTDS object that is used as GUID of \
> the frsRootPath. Can you confirm or precise the correct information about this ?
>
> Thanks.
> Matthieu.
>
> --
> Matthieu Patou
> Samba Teamhttp://samba.org
> Private repohttp://git.samba.org/?p=mat/samba.git;a=summary
>
>
--
Matthieu Patou
Samba Team
http://samba.org
_______________________________________________
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic