Subject: Re: more proposed protocol changes

From: Zachary Amsden <[email-masked]>
Date: Thu, 3 Aug 2000 15:03:16 -0700

You are correct.  That is why I explicitly specified that you
would also need a semantical change, "under no circumstances
should the update vector passed from a consumer to a supplier
via a startReplicationResponse be interpreted as the current
update vector of that consumer".  Rather, it is an "update
vector request".  You can instead use the update vector
returned from either a replicationUpdateResponse, or an
endReplicationResponse.  It actually makes more sense to use
that value anyway, since you will need to commit that update
vector as your known update vector for that consumer, since
you need to have confirmation that the consumer has committed
all the changes sent to it.

In any case, I don't think it is necessary to actually forbid
a consumer from taking having concurrent partial updates to
the same replica, as it states in the architecture draft.

---- Original message ----
>Date: Thu, 3 Aug 2000 13:38:55 +0100
>From: "David Chadwick" <[email-masked]>
>Subject: Re: more proposed protocol changes
>To: Zachary Amsden <[email-masked]>, [email-masked]
>Cc: 
>
>Date sent:      	Mon, 31 Jul 2000 17:05:30 -0700
>From:           	Zachary Amsden <[email-masked]>
>Subject:        	more proposed protocol changes
>To:             	[email-masked]
>
>> To accomodate simultanaeous LDUP partial updates to
>> the same replica, it would make sense to allow the sender
to
>> optionally send an update vector containing describing the
>> CSNs it is about to send.  This could be passed back to
other
>> suppliers for the same replica in the
startReplicationResponse
>> while the original replication is proceeding. 
>
>Zachary
>
>I worry about this sort of procedure, since the consumer is
saying 
>to the other suppliers that it has received the updates (from
the first 
>supplier) before it actually has. Once these suppliers store
that 
>update vector they will never attempt to update the consumer
with 
>these updates. Worse than that, if the connection with the
first 
>supplier breaks, the consumer now does not have the updates
it 
>has told everyone (except the first supplier) that it does
have. What 
>if the first supplier replicates with say the third supplier
and gets the 
>update vector from it before it restarts it link to the
consumer. The 
>first will now think that the consumer has the updates, wont
it?
>David

---

From: "Albert Langer" <[email-masked]>
Date: Mon, 7 Aug 2000 22:47:59 +1000

[Zachary...]

[Albert]
The architecture draft may have been written with the assumption
that allowing a consumer to take concurrent updates for the same
replica would not work because there was no ordering.

It MIGHT be possible to allow this when updates are ordered.
However you would need to carefully consider what happens in
triangular situations etc. If it is possible, the exact method
would need to be fully specified rather than just changing
MUST NOT to MAY. Note that that even without allowing concurrent
update sessions, accepting updates from more than one upstream
master is what makes X.500 DISP complicated to implement, despite
having a single master further upstream.

It would certainly be useful if this restriction could be removed
since it severely complicates scheduling. I suspect it cannot be
as Active Directory uses ordered updates but has that restriction.
If you believe it can be, please draft an explicit mechanism with
a semi-formal proof that the update vectors and purge mechanism
works correctly, including triangular situations.

---

From: "Steven Legg" <[email-masked]>
Date: Wed, 16 Aug 2000 12:55:22 +1000

Zach,

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Zachary Amsden
> Sent: Friday, 4 August 2000 8:03
> To: [email-masked]
> Cc: [email-masked]

I don't like this idea of passing on vectors to other suppliers
because it creates a dependency between concurrent replication sessions.
If the first supplier's replication session fails then the second and
subsequent suppliers' replication sessions must also fail because they will
have omitted changes that the consumer didn't end up getting from the first
supplier. Furthermore, the consumer must not revise it's Update Vector due
to the processing of changes from the second and subsequent suppliers
until the first supplier's replication session is successfully
concluded (so the other replication sessions can't finish until after
the first one does). I think it is better for each supplier to send
all the required changes so that their sessions can independently succeed
or fail. This is an issue of traffic volume rather than consumer load
since URP quickly dispenses with replication primitives that make no
change to the DIB because they have been processed before (e.g. through
one of the other sessions).

> the same replica, as it states in the architecture draft.

I don't think we need to forbid concurrent replication sessions
either, though implementations should have the option to decline a
second replication session.

Regards,
Steven