CollaborationWindow Class

Packages > @fluidframework/merge-tree > CollaborationWindow

Signature

export declare class CollaborationWindow

Properties

Property Details

clientId

Signature

clientId: number;

Type: number

collaborating

Signature

collaborating: boolean;

Type: boolean

currentSeq

Highest-numbered segment in window and current reference sequence number for this client.

Signature

currentSeq: number;

Type: number

localSeq

Highest-numbered localSeq used for a pending segment. Semantically, localSeqs provide an ordering on in-flight merge-tree operations: for operations stamped with localSeqs a and b, a < b if and only if a was submitted before b.

Signature

localSeq: number;

Type: number

Remarks

• This field is analogous to the clientSequenceNumber field on ops, but it’s accessible to merge-tree at op submission time rather than only at ack time. This enables more natural state tracking for in-flight ops.

It’s useful to stamp ops with such an incrementing counter because it enables reasoning about which segments existed from the perspective of the local client at a given point in ‘un-acked’ time, which is necessary to support the reconnect flow.

For example, imagine a client with initial state “123456” submits some ops to create the text “123456ABC”. If they insert the “C” first, then “B”, then “A”, their local segment state might look like this:

[
    { seq: 0, text: "1234" },
    { seq: 5, text: "56" },
    { localSeq: 3, seq: UnassignedSequenceNumber, text: "A" },
    { localSeq: 2, seq: UnassignedSequenceNumber, text: "B" },
    { localSeq: 1, seq: UnassignedSequenceNumber, text: "C" },
]

(note that localSeq tracks the localSeq at which a segment was inserted)

Suppose the client then disconnects and reconnects before any of its insertions are acked. The reconnect flow will necessitate that the client regenerates and resubmits ops based on its current segment state as well as the original op that was sent.

It will generate the ops 1. { pos: 6, text: “C” } 2. { pos: 6, text: “B” } 3. { pos: 6, text: “A” }

since when submitting the first op, remote clients don’t know that this client is about to submit the “A” and “B”.

On the other hand, imagine if the client had originally submitted the ops in the order “A”, “B”, “C” such that the segments’ local state was instead:

[
    { seq: 0, text: "1234" },
    { seq: 5, text: "56" },
    { localSeq: 1, seq: UnassignedSequenceNumber, text: "A" },
    { localSeq: 2, seq: UnassignedSequenceNumber, text: "B" },
    { localSeq: 3, seq: UnassignedSequenceNumber, text: "C" },
]

The resubmitted ops should instead be: 1. { pos: 6, text: “A” } 2. { pos: 7, text: “B” } 3. { pos: 8, text: “C” }

since remote clients will have seen the “A” when processing the “B” as well as both the “A” and “B” when processing the “C”. As can be seen, the list of resubmitted ops is different in the two cases despite the merge-tree’s segment state only differing in localSeq.

This example is a bit simplified from the general scenario: since no remote clients modified the merge-tree while the client was disconnected, the resubmitted ops end up matching the original ops exactly. However, this is not generally true: the production reconnect code takes into account visibility of segments based on both acked and local information as appropriate. Nonetheless, this simple scenario is enough to understand why it’s useful to be able to determine if a segment should be visible from a given (seq, localSeq) perspective.

minSeq

Lowest-numbered segment in window; no client can reference a state before this one

Signature

minSeq: number;

Type: number