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: '[email protected]'
Cc: [email protected]; [email protected]; 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:[email protected]]
Sent: Thursday, September 29, 2011 2:35 AM
To: Interoperability Documentation Help; [email protected];
[email protected]
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 [email protected]
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
[email protected]
https://lists.samba.org/mailman/listinfo/cifs-protocol
