Re: more proposed protocol changes

[Zachary Amsden <zach@xxxxxxxxxxxxx>]

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" <d.w.chadwick@xxxxxxxxxxxxx>
>Subject: Re: more proposed protocol changes
>To: Zachary Amsden <zach@xxxxxxxxxxxxx>, ietf-ldup@xxxxxxx
>Cc: 
>
>Date sent:      	Mon, 31 Jul 2000 17:05:30 -0700
>From:           	Zachary Amsden <zach@xxxxxxxxxxxxx>
>Subject:        	more proposed protocol changes
>To:             	ietf-ldup@xxxxxxx
>
>> 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