[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cifs-protocol
Subject:    Re: [cifs-protocol] [REG:111092948476937] FRSRPC: questions about
From:       Matthieu Patou <mat () samba ! org>
Date:       2011-11-07 10:11:39
Message-ID: 4EB7AEDB.50709 () samba ! org
[Download RAW message or body]

Obaid,

That's good for those questions.

Thanks.

Matthieu.

On 25/10/2011 18:09, Obaid Farooqi wrote:
> Hi Matthieu:
> Please find the answers to your questions as follows>
> 
> Q. Ok and what happen if a downstream partner tries to join when the schedule is \
> closed ? A. If the schedule is trigger schedule (sysvol connection between sites), \
> the upstream partner will ignore the schedule and join will be successful as \
> mentioned in Ms-FRS1 section "3.3.2.1.1   SYSVOL Connection ScheduleTimer": 
> "When a triggering schedule is used, the upstream partner ignores its schedule and \
> responds to any request by the downstream partner. When the schedule closes, the \
> upstream partner unjoins the connection only after the current contents of the \
> outbound log, at the time of join, have been sent and acknowledged." 
> For non-trigger schedule, the command is ignored if schedule is not open.
> 
> Q.>  By "upstream partner unjoins the connection" does not mean that upstream \
> partner sends CMD_UNJOIN_REMOTE command. This is in context of a normal sync and \
> refers to an internal state where upstream partner is in "join" state when \
> replication is going on and when replication is complete, the connection is in \
> "unjoin" state. The "unjoin" here refers to stuff like invalidating the join GUID, \
> incrementing the unjoin counters, freeing the outbound version vectors etc. Ok this \
> is clear, thanks for the precision. Should this information be added to the \
> FRS1.pdf ? 
> A. A mentioned in section 2.2.3.6.2   COMM_COMMAND (and on other places) that \
> CMD_UNJOIN_REMOTE is sent only for initial sync (VVJOIN). So in case of non-vvjoin \
> joins, unjoin is implicit. In case of trigger schedule, this "implicit unjoin" \
> happens when all the contents of outbound log at the time of join are synced. In \
> case of non-trigger schedule, the "implicit unjoin" happens at the close of the \
> schedule as mentioned in section 3.3.2.1.2: 
> "When the schedule closes, FRS unjoins the connection."
> 
> Q. Ok that was not 100% clear for me that when a schedule period is open it's for \
> 15 minutes at least (if you have only 1 period). Should this precision be added to \
> the document ? 
> A. This is mentioned in the document. In section "3.3.2.1.1   SYSVOL Connection \
> ScheduleTimer" it is stated that: "When set to one time per hour, replication MUST \
> start at 0:00 and ends at 0:15." 
> Please let me know if it answers your question.
> 
> Regards,
> Obaid Farooqi
> Escalation Engineer | Microsoft
> 
> 
> 
> -----Original Message-----
> From: Matthieu Patou [mailto:mat@samba.org]
> Sent: Friday, October 21, 2011 4:06 PM
> To: Obaid Farooqi
> Cc: pfif@tridgell.net; cifs-protocol@samba.org; MSSolve Case Email
> Subject: Re: [REG:111092948476937] FRSRPC: questions about schedule
> 
> On 21/10/2011 01:05, Obaid Farooqi wrote:
> > Hi Matthieu:
> > I am providing the answers in the Q&A format to your questions:
> > 
> > Q. Given the fact that, from my understanding, FRS is pushed based, what's the \
> > implication of this ? Because even if it's the downstream partner that is sending \
> > change notification it has to wait for the upstream to create a connection and \
> > once it's done it can start to send files. Also the unjoin command is send by the \
> > one who created the connection that is to say the downstream partner, so how can \
> > the upstream partner "unjoin" the connection ? 
> > A. I will use the following definitions (MS-FRS1 Glossary) of upstream and \
> > downstream partner to explain what the paragraph means. Downstream Partner: The \
> > partner that receives change orders, files, and folders. Upstream Partner: The \
> > partner that sends out change orders, files, and folders. 
> > The sentence "When a triggering schedule is used, the upstream partner ignores \
> > its schedule and responds to any request by the downstream partner." means that \
> > even if the schedule is closed as per the configuration, replication will \
> > continue till all the change orders in the outbound log are done. The "request by \
> > the downstream partner" is like CMD_SEND_STAGE that a downstream partner sends in \
> > the course of a sync. It does not mean that the exchange is initiated by \
> > downstream partner. The CMD_REMOTE_CO is still sent by upstream partner at the \
> > beginning of the schedule open.
> Ok and what happen if a downstream partner tries to join when the schedule is \
> closed ?
> > If the schedule is "non-triggering", the replication will stop even if there are \
> > outstanding change orders in the outbound log and upstream partner will ignore \
> > request from downstream partner to continue replication. 
> > By "upstream partner unjoins the connection" does not mean that upstream partner \
> > sends CMD_UNJOIN_REMOTE command. This is in context of a normal sync and refers \
> > to an internal state where upstream partner is in "join" state when replication \
> > is going on and when replication is complete, the connection is in "unjoin" \
> > state. The "unjoin" here refers to stuff like invalidating the join GUID, \
> > incrementing the unjoin counters, freeing the outbound version vectors etc.
> Ok this is clear, thanks for the precision. Should this information be added to the \
> FRS1.pdf ?
> > Q. Also can you clarify what's the meaning "when the schedule close" means \
> > exactly ? I understand that by default you have a schedule open every 15 minutes, \
> > but for how long it is open ? 
> > A. A schedule can only open at minutes 0, 15, 30 and 45 of any hour of the day. \
> > Once it is open, it is open for minimum 15 minutes. So, for example, you \
> > configured the schedule to open at 5:00PM and 5:15PM. In this case the schedule \
> > will open at 5:00PM and will close at 5:30PM and will be open for 30 minutes. If \
> > you configure contiguous 15 minutes periods then schedule will open at the \
> > beginning of the first 15 minute period and will close at the end of last 15 \
> > minute period. 
> > As mentioned in MS-FRS1 section "2.3.1.2   NTFRS Replica Set Object", the \
> > schedule is an 84-byte array. Each byte corresponds to two hours and the first \
> > byte corresponds to first two hours of Sunday. If the value of first byte is 0x0F \
> > and the rest of the bytes are all zero, the schedule will open at 0:00 on Sunday \
> > and will close on 1:00AM on Sunday.
> Ok that was not 100% clear for me that when a schedule period is open it's for 15 \
> minutes at least (if you have only 1 period). Should this precision be added to the \
> document ? 
> 
> Thanks.
> 
> Matthieu.
> > Please let me know if it does not answer your question.
> > 
> > Regards,
> > Obaid Farooqi
> > Escalation Engineer | Microsoft
> > 
> > Exceeding your expectations is my highest priority.  If you would like to provide \
> > feedback on your case you may contact my manager at nkang<at>   microsoft dot \
> > com. 
> > -----Original Message-----
> > From: Obaid Farooqi
> > Sent: Friday, September 30, 2011 2:30 PM
> > To: 'mat@samba.org'
> > Cc: pfif@tridgell.net; cifs-protocol@samba.org; MSSolve Case Email
> > Subject: RE:[REG:111092948476937] FRSRPC: questions about schedule
> > 
> > Hi Matthieu:
> > I'll help you with this issue and will be in touch as soon as I have an answer.
> > 
> > Regards,
> > Obaid Farooqi
> > Escalation Engineer | Microsoft
> > 
> > 
> > 
> > -----Original Message-----
> > From: Matthieu Patou [mailto:mat@samba.org]
> > Sent: Thursday, September 29, 2011 2:35 AM
> > To: Interoperability Documentation Help; pfif@tridgell.net; \
> >                 cifs-protocol@samba.org
> > Subject: FRSRPC: questions about schedule
> > 
> > Hello dochelp team,
> > 
> > In ms-frs1.pdf we have at paragraph "3.3.2.1.1 SYSVOL Connection ScheduleTimer"
> > 
> > SYSVOL connection between sites. SYSVOL replication is initiated between two \
> > inter-site members at the start of the 15-minute interval, assuming the schedule \
> > is open. The connection MUST be using a trigger schedule. When a triggering \
> > schedule is used, the upstream partner ignores its schedule and responds to any \
> > request by the downstream partner. When the schedule closes, the upstream partner \
> > unjoins the connection only after the current contents of the outbound log, at \
> > the time of join, have been sent and acknowledged. 
> > Given the fact that, from my understanding, FRS is pushed based, what's the \
> > implication of this ? Because even if it's the downstream partner that is sending \
> > change notification it has to wait for the upstream to create a connection and \
> > once it's done it can start to send files. 
> > Also the unjoin command is send by the one who created the connection that is to \
> > say the downstream partner, so how can the upstream partner "unjoin" the \
> > connection ? Also can you clarify what's the meaning "when the schedule close" \
> > means exactly ? I understand that by default you have a schedule open every 15 \
> > minutes, but for how long it is open ? 
> > 
> > Thanks.
> > 
> > Matthieu.
> > 
> > --
> > Matthieu Patou
> > Samba Team
> > http://samba.org
> > 
> > 
> > Microsoft is committed to protecting your privacy.  Please read the Microsoft \
> > Privacy Statement for more information.The above is an email for a support case \
> > from Microsoft Corp.REPLY ALL TO THIS MESSAGE or INCLUDE casemail@microsoft.com \
> > IN YOUR REPLY if you want your response added to the case automatically. For \
> > technical assistance, please include the Support Engineer on the TO: line. Thank \
> > you.
> 


-- 
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