more proposed protocol changes

[Zachary Amsden <zach@xxxxxxxxxxxxx>]

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.  This avoids
getting duplicate changes from multiple replicas over the
wire, and avoids the need to reschedule replications because
of "server busy" errors.

Another use for this would be for deciding whether to abort a
slower connection when a more preferred connection is going to
cover the same sequence.

It seems clear from the protocol-02 draft that there are no
commitments implied by the startReplicationResponse vector -
i.e under no circumstances should a supplier update it's known
vector based on this response.  All commitments should be made
via an endReplicationResponse or an unsolicited
ReplicationUpdateResponse.  So I see no problem with this
approach.

Alternatively, the consumer could send an immediate
replicationUpdateResponse, but there are two problems with
this:

1)  The current draft states that the response is sent when
the consumer wishes the supplier to stop sending updates.  I
disagree with this.  I see no reason the supplier should stop
if it has changes not covered by the suppliers vector, unless
abortUpdate is set.

2)  Sequencing -the supplier may have already queued a large
number of replicationUpdates, which defeats the purpose.

So that would be:

StartReplicationRequest ::= [APPLICATION 23] SEQUENCE {
	requestName 	[0] LDAPOID,
	requestValue	[1] OCTET STRING
}

requestValue ::= SEQUENCE {
	replicaRoot		LDAPDN,
	replicaID		LDAPString,
	replicationProtocolOID	LDAPOID,
	replicationInitiator	ENUMERATED
	{
		supplier (0),
		consumer (1)
	}
	replicatUpdateVector	Attribute OPTIONAL
}

Zach Amsden
zach@xxxxxxxxxxxxx