1.实时组编辑系统
单用户的文档编辑系统，如普通的文档编辑器，在人们生活中已经十分普遍。但近 年来随着Internet的发展和社会合作的需求，将这些单用户的编辑系统移植到多用户的环 境下，允许多个用户通过计算机网络同时浏览、编辑一个共享数据对象，使之能够在多用 户协同工作时发挥重要的作用，这样的需求也就自然而然地产生了，这种编辑系统称为组 编辑系统。
实时组编辑系统是组编辑系统中应用最广泛的一种，其必须满足实时性、分布式和提 供用户无限制编辑的特性。现在普遍采用全复制式结构来实现这种系统，也就是说，每个 用户都有一个文档数据副本，而且他们被允许并发地、同步地修改这份共享文档。这里有 三个条件必须被满足，那就是结果一致、因果一致和用户意图一致。结果一致指同一操作 集合在所有站点执行后，这些站点上的文档状态一致。因果一致指对于任意两个操作Oa和 Ob，如果在Ob的初始站点上，Oa在Ob生成前已被生成或执行，则在所有站点上Oa都应早于 Ob被执行。用户意图一致指对于任意操作O，其在所有站点上的执行效果都应保持O的原有 意图，同时O的执行效果不能影响那些与O并发的操作的执行效果。
2.大规模协同环境
尽管目前对实时组编辑的研究已经取得了很大的进展，然而，现有的对实时组编辑的 研究都还主要局限于小组协同(人数小于10)。在更大规模的协同环境中(人数大于10， 甚至成百上千)支持实时组编辑活动会遇到什么样的特殊问题？
比如远程Autocad教学的例子，学习者可以通过编辑修改一份共享AutoCAD文档数据，实 时地相互交流，不必再局限于白板、Instant Messenger等通用的协同交互工具，这样的交 流方式更为直接，往往也更有利于学习者表达自己的观点和想法。但这种远程教学学生群 规模庞大，可以认为是大规模协同环境。
3.因果与并发关系检测
全复制结构下的实时组编辑系统允许用户并发的编辑修改他们各自的文档数据副本。 两个操作具有因果关系指的是一个操作在另一个操作的产生之前已经执行；而两个操作并 发指的是这两个操作不存在因果关系。准确识别操作间的因果并发关系是正确维护实时组 编辑一致性的基础。实时组编辑应用中的因果并发关系判断主要涉及三方面的问题：
(1)判断一个操作是否因果就绪：网络传输具有不确定性，操作以它们的生成顺序先后发 出，却未必能按相同的顺序到达目标站点。
(2)找出所有之前执行过的与当前正在执行的远程操作并发的操作。本地站点收到从远程站 点发过来的这种操作时，首先需要对这种操作作转换，因为该操作从产生到传输完毕，本 地产生了新的操作。如果将该远程操作直接执行，会导致不一致的情况。那么转换就意味 着远程操作要根据本地操作作相应转换后再执行。
目前比较操作间的相互关系主要手段是比较时间戳。传统的时间戳是一个N维的向量， 向量的第i个元素记录的是第i个站点当前已执行操作个数。后来又有人提出直接因果先序 时间戳DCV。
4.DCV时间戳的优点和弊端
定义：直接因果先序关系()：给定两个任意的操作Oa和Ob，Oa直接因果先序于Ob， 记为OaOb，当且仅当(1)Oa→Ob并且(2)不存在一个操作Oc，满足Oa→Oc且Oc→ Ob。
定义：直接因果先序向量时间戳(Direct Causal Vector，简称DCV)：给定一个操 作O，假设O1，O2，...，Ok是所有直接因果先序于O的操作，O1是站点S1上产生的第N1个操作， O2是站点S2上产生的第N2个操作，Ok是站点Sk上产生的第Nk个操作，我们定义操作O的直 接因果先序向量时间戳为[(S1，N1)，(S2，N2)，...，(Sk，Nk)]，记为DCV(O)。
和传统向量时间戳相比，DCV表示方法比较明显的削减了每个操作所带的时间戳的规 模。参考图1，从左到右三条直线分别表示站点1，2，3上的操作顺序。图中的6个操作， O12直接因果依赖于O11，O21和O31，O32也直接因果依赖于这三个操作，O22直接因果依赖于O12 和O32。这6个操作的直接因果先序向量时间戳分别为DCV(O11)＝[]，DCV(O21)＝[]，DCV(O31) ＝[]，DCV(O12)＝[(1，1)，(2，1)，(3，1)]， DCV(O22)＝[(1，2)，(3，2)]和DCV(O32)＝[(1，1)，(2，1)，(3，1)]。
直接因果先序向量时间戳的优点在于其是一种动态时间戳，系统不为协同参与者预留 时间戳分量，一个从不修改共享文档数据的“只读”协同参与者并不会对时间戳的大小产生 影响。因此，在一个使用直接因果先序向量时间戳技术的实时组编辑系统中，操作的时间 戳大小总是小于等于实际参与修改共享文档数据的协同参与者的人数。
而这种时间戳的缺点在于，由于它是动态的时间戳，所以检测并发操作的时候需要比 较自己的直接因果先序操作和当前操作，才能得出结论，显得不是那么简洁明了。而且DCV 一定程度上反映并发程度，一旦并发性极高的情况下，DCV的规模会直线上升。所以在这 种大规模并发环境下要是能根据DCV特点修改相应的检测方法，或者缩小时间戳的规模， 都会对效率提高起到关键作用。

本发明的目的在于提出一种在大规模协同环境下提高并发操作检测效率的协同交互 优化方法。
传统的向量时间戳可伸缩性差，于是我们对交互进行修改，提出了远程操作的调整方 法，然后为了支持这种策略，提出了Leader优化的协同模型和在此模型下的分发与操作同 步方法，尽可能地用一整套方案来提高大规模协同环境下组编辑效率。
步骤1：交互模式的调整，远程操作执行顺序的调整
在一个有着N个协同站点的实时组编辑环境中，任意给定一个整数M，2＜M＜N，我 们总能通过下列调整将操作的直接因果先序向量时间戳大小控制在≤M的范围内。假设N 个协同站点分别为S1，S2，S3...，SN，对每一个协同站点Si(1≤i≤N)，按照以下两个步骤 调整交互模式
1)对来自于Sj(0＜i-j＜M或i-j＜M-N)的操作，立即同步，只要它满足因果就绪 条件。
2)对来自于其它站点的操作，延迟对它的同步，直到收到一个来自于站点Sk(0＜i-k ＜M或i-k＜M-N)的且直接因果依赖于它的操作。那么对于每一个协同站点Si(1≤i≤ N)，其上产生的操作都只可能直接因果依赖于来自于站点Sj(0≤i-j＜M或i-j＜M-N) 的操作，这些操作的直接因果先序向量时间戳的大小必然≤M。
直接因果先序向量时间戳具有一个有趣的特性：在实时组编辑活动中，通过合理规范 各协同站点上远程操作的同步顺序，可以有效地控制操作的直接因果先序向量时间戳大 小。考虑图2中的协同场景，共有3个协同站点：站点1、站点2和站点3，协同过程中，三个 站点共产生了6个协同操作：操作O11和O12产生于站点1，操作O21和O22产生于站点2，操作 O31和O32产生于站点3。三个站点都严格遵循传统的协同交互模式——本地操作产生后立即 被广播到所有其它协同站点，收到远程操作后，也是尽快地对它进行同步，只要它已经因 果就绪。6个操作之间的因果并发关系分别为：O11，O22和O32两两互为并发操作、O12和O32 互为并发操作、O21和O31，O32都互为并发操作、O11直接因果依赖于O21和O31、O12直接因果依 赖于O11和O22、O22直接因果依赖于O21和O31、O32直接先序依赖于O31；它们的直接因果先序 向量时间戳分别为：DCV(O11)＝[(2，1)，(3，1)]，DCV(O21)＝[]，DCV(O31)＝[].DCV(O12)＝[1，1)， (2，2)]，DCV(O22)＝[(2，1)，(3，1)]和DCV(O32)＝[(3，1)]。
现在考虑执行顺序调整后的协同场景，也就是加上了图中的虚线，同样的3个协同站 点，同样的6个操作，每个操作的生成时间、生成站点都与左图中的完全一致，然而，协 同交互模式有了稍许变化——站点1上，对于收到的来自于站点3的远程操作，并不立即对 它进行同步，而是一直延迟直到收到一个来自于站点2的直接因果依赖于它的操作，因此， 图2中可以看出，O31在站点1上的执行被延迟直到收到了操作O22。图中，6个操作之间的因 果并发关系分别为：O11，O22和O32两两互为并发操作、O11和O31互为并发操作、O12和O32互为 并发操作、O21和O31，O32都互为并发操作、O11直接因果依赖于O21、O12直接因果依赖于O11和 O22、O22直接因果依赖于O21和O31、O32直接先序依赖于O31；它们的直接因果先序向量时间 戳分别为：DCV(O11)＝[(2，1)]，DCV(O21)＝[]，DCV(O31)＝[]，DCV(O12)＝[(1，1)，(2，2)]，DCV(O22) ＝[(2，1)，(3，1)]和DCV(O32)＝[(3，1)]。和原图像比，调整只是对站点1上的远程操作同步顺序 作了稍许调整，结果却很明显，操作O11的直接因果先序向量时间戳大小减小了，其它操作 的直接因果先序向量时间戳都没变，操作在各站点间分发，总的时间戳开销变小了。
上面我们已经给出了一种用户间协同交互模式的调整策略，在使用直接因果先序向量 时间戳技术的实时组编辑系统中，基于该策略调整用户间的协同交互模式可以灵活有效地 控制住实时组编辑活动中的操作时间戳开销。现在考虑任意的协同站点Si，假设所有的站 点Sj(0＜i-j＜M或i-j＜M-N)都一直处于不活跃的状态，不产生任何操作，按照上述 规定，站点Si将不能同步任何收到的远程操作，协同站点Si上的协同用户将很长时间无法感 知其它用户的操作情况。如果这样的情况在很多协同站点上发生，必然会影响用户间的协 同效率。
由此，本发明是建立一些虚拟的协同站点，称为Leader协同站点，并在这些虚拟协同 站点上定期地生成一些虚拟的协同操作。通过引入虚拟的协同站点、虚拟的协同操作，参 与调整协同交互模式，控制实时组编辑活动中的操作时间戳开销，可以避免影响用户正常 的协同工作，因为虚拟协同站点的网络布局、虚拟协同站点上虚拟协同操作的生成频率都 是我们可以根据需要随时调整的。通过规定，对于收到的远程用户文档数据操作(不包括 Leader协同站点上生成的虚拟协同操作)，用户协同站点(不包括Leader协同站点)必 须延迟对它的同步直到收到一个来自于Leader协同站点的且直接因果依赖于它的虚拟协 同操作，可以确保，每一个新生成的用户文档数据操作都只直接因果依赖于同一个协同站 点上生成的其它用户文档数据操作，或者Leader协同站点上生成的虚拟协同操作。这样， 只需要控制好虚拟站点的数量就能有效地控制住每个用户文档数据操作的时间戳大小、控 制住实时组编辑活动中的操作时间戳开销。
步骤2：设立Leader优先协同站点
1)选取一个站点设为Leader虚拟站点，用于协调域内各协同站点上操作的分发与 同步，并生成一些虚拟的协同操作。这些站点只用作协同，不提供用户访问修改共享文档 数据的操作界面和工具。
2)协同站点上生成的关联与某个用户文档数据操作的虚拟协同操作，称为该操作的影 子操作。在实现中，要保证影子操作在某个操作产生后立即执行，中间不会执行任何其它 操作。
在每个稳定的实时组编辑域中，都有一个Leader协同站点，这是一些虚拟的协同站点， 用于协调域内各协同站点上操作的分发与同步，并生成一些虚拟的协同操作，辅助参与协 同交互模型、控制实时组编辑活动中的操作时间戳开销。Leader协同站点不提供协同用户 访问修改共享文档数据的操作界面和工具。为了区分，在下文中，我们用用户协同站点表 示那些提供共享文档数据访问修改操作界面的直接面向协同参与者提供服务的真正的协 同站点，另外，如果没有特殊说明，我们提到的协同站点，都同时指代用户协同站点和 Leader协同站点。我们要求，每个稳定的实时组编辑域中都有可用的Leader协同站点。 如果由于网络连接情况的变化，或是原有的Leader协同站点发生意外故障等，在一个稳定 的实时组编辑域中没有了可用的Leader协同站点，系统应在一个尽可能短的时间内重新建 立一个新的Leader协同站点。我们并不限制在每个稳定的实时组编辑域中的Leader协同 站点的数量，然而，在一个稳定的实时组编辑域中建立多个Leader协同站点是毫无意义的， 只会增加系统的开销，因此，应该尽可能保持每个稳定的实时组编辑域中都仅仅只有一个 Leader协同站点。
Leader协同站点参与协同交互模型，会生成一些虚拟的协同操作。之所以称这些操作 是“虚拟”的，因为它们作为协同操作却并不对共享文档数据作任何修改。为了区分，在下 文中，我们用用户文档数据操作指代那些会对共享文档数据产生影响的真正的协同操作如 Insert、Delete等，另外，没有特殊说明，我们提到的操作、远程操作、本地操作等都将 同时指代用户文档数据操作和Leader协同站点上生成的虚拟协同操作。
Leader协同站点上生成虚拟协同操作，总是关联于一个用户文档数据操作ODoc，称作 为ODoc生成影子操作；生成的虚拟协同操作，我们称之为ODoc的影子操作，或是与ODoc相关 的影子操作。Leader协同站点为一个用户文档数据操作生成影子操作，总是在执行了该操 作之后立即进行的，中间不会执行任何其它操作，给定一个用户文档数据操作O，以及它 的影子操作ψo，必然有Oψo。Leader协同站点不提供协同用户访问修改共享文档数 据的操作界面，不面向协同用户提供服务，因而，Leader协同站点上不会生成任何用户文 档数据操作，即除了被称为影子操作的虚拟协同操作，Leader协同站点上不会生成任何其 它类型的协同操作。
步骤3：协同站点上的操作分发
1)将用户文档数据操作从一个协同站点向另一个协同站点分发时，必须附带发送至少 一个与之相关的影子操作。唯一的例外：用产协同站点向同一个稳定的实时组操作域中的 Leader协同站点发送它的本地用户文档数据操作时，不需要附带相关的影子操作。
相比传统实时组编辑系统一但产生操作则立即向其他站点发送的做法，这里按照分步 骤(1)，用户协同站点将新生成的用户文档数据操作分发给其它协同站点，必须通过Leader 协同站点间接地进行。后面可以看到，在我们的实时组编辑交互模型中，对远程用户文档 数据操作以及它的相关影子操作的执行顺序与执行时间都有着严格的要求，此规则确保当 用户协同站点收到一个远程的用户文档数据操作时，同时也收到了它的影子操作，从而可 以简化相关的处理过程。
2)给定一个Leader协同站点SL，假设ODoc是SL上新接收到的一个用户文档数据操作， ODoc的相关影子操作并没有随ODoc一起被发送到Leader协同站点SL上。
①ODoc没有在SL上执行过：SL应尽快地执行ODoc，为它生成一个影子操作ψ，然后将 ODoc，附上新生成的虚拟协同操作ψ，一起向所有的其它协同站点分发；
②ODoc已经在SL上执行过：此时从SL的历史操作列表中找到与ODoc相关的影子操作(即 直接因果依赖于ODoc的虚拟协同操作)，记为ψ。SL应立即将操作ODoc，附上ψ，一起向 所有的其它协同站点分发。
一个用户文档数据操作ODoc，没有附带与之相关的影子操作，被单独发送到Leader协 同站点SL，这往往暗示(1)同一个稳定的实时组编辑域中的其它协同站点(除了ODoc的生 成站点)都还没有执行过这个用户文档数据操作(2)操作的生成站点没有与ODoc相关的影 子操作记录，则无法将该操作分发出去。我们制定操作分发规则，要求Leader协同站点SL 尽快地处理ODos、将ODoc进一步分发给所有其它协同站点，是为了确保较高的协同感知性 能。让协同用户尽快地尽可能实时地感知互相的行为操作和意向，这是实时组编辑系统的 一个基本性能要求。
步骤4：协同站点上的操作同步。
(1)本地站点上收到的远程操作必须等到因果就绪后才可以被同步。
远程操作的同步顺序不能违背它们的因果先序顺序，每个远程操作都必须等所有它所 因果依赖于的操作都执行后才能执行。这是实时组编辑一致性模型所要求的，在实时组编 辑活动中永远都不应被违背。
(2)在协同站点上，每同步一个远程的用户文档数据操作，紧跟着执行的总是一个 与之相关的影子操作。操作同步规则2是Leader优先协同交互模型的核心，是Leader优 先协同交互模型能够实现灵活控制实时组编辑活动中时间戳开销的基础。
分步骤(2)将确保：1.所有的用户文档数据操作，除了同一个站点上产生的其它用 户文档数据操作以及各Leader协同站点上产生的虚拟协同操作，不会直接因果依赖于任何 其它操作。2.所有的虚拟协同操作(影子操作)，除了它所对应的用户文档数据操作以 及各Leader协同站点上产生的虚拟协同操作，不会直接因果依赖于任何其它操作。总之， 所有操作的直接因果先序向量时间戳大小都小于等于当前系统中的Leader协同站点的数 量加1，也就是说，我们可以通过控制Leader协同站点的数量有效控制实时组编辑活动中 的时间戳开销。
下面是步骤(2)的实现。如果一个用户文档数据操作O，没有附带与之相关的影子 操作，被单独发送到协同站点S(O之前没有在S上执行过)。则S必然是一个Leader协同 站点。而且，协同站点S执行了操作O以后会不间断地立即生成一个虚拟协同操作ψ。ψ是 O的影子操作，O和ψ在S上一先一后连续执行，如果协同站点S在收到用户文档数据操作O 的同时，也收到了与之相关的影子操作，记为ψ，O ψ。假设ψ的生成站点是SL，在 执行操作O并生成ψ之前，SL一直都很好地遵守着操作同步规则的规定，更具体的，SL上 之前执行过的任意一个用户文档数据操作O’，其后都紧跟着执行了一个与之相关的影子操 作ψ’，O’→ψ’。容易推断，O不仅是ψ的直接因果先序前继，也是唯一的直接因果先序 于ψ的用户文档数据操作。O和ψ在S上一先一后连续执行，应该是可行的，也不会产生任 何问题(不会干扰其它操作，主要是其它用户文档数据操作的执行)。
(3)给定一个Leader协同站点SL，O是SL上收到的一个远程用户文档数据操作。SL 应该尽可能的推迟对操作O的同步，如果它在收到操作O的同时也收到了O的一个影子操作 ψ。
分步骤(3)的目的在于尽可能的减小Leader协同站点上生成的虚拟协同操作的直接 因果先序向量时间戳大小，减小每个虚拟协同操作给系统带来的额外开销。考虑在Leader 协同站点SLX上生成虚拟协同操作ψX，它所对应的用户文档数据操作为OX，ψ’X是SLX上 之前生成的一个虚拟协同操作。(2)决定了ψX不会直接因果依赖于除O以外的任何其它 用户文档数据操作，按操作同步规则则进一步确定，ψX不会直接因果依赖于除ψ’X以外 的任何其它虚拟协同操作。假设ψX还直接因果依赖于虚拟协同操作ψY(ψY≠ψ’X)，ψY 不可能产生于Leader协同站点SLX，它必然产生于SLX之外的其它Leader协同站点。假设SLX 上，在执行ψY之后生成ψX之前，还执行过操作O1，O2，...，Ok，由于ψYψX，O1，O2，...，Ok 中不存在一个操作因果依赖于ψY；另一方面，如果对ψY的同步严格遵循操作同步规则中 的规定，即对ψY的同步被推迟到直到收到一个被单独发送到SLX的且因果依赖于ψY的用户 文档数据操作Ot，容易判断，SLX对Ot的同步应该是在ψY之后在ψX之前，也就是说Ot∈{O1， O2，...，Ok}，而ψx→Ot，这就与我们之前的推理发生了矛盾。
上文中，N表示站点个数，Si表示标识为Si的协同站点。
1)Oxy表示某个从站点x产生的第y个操作，
2)ψ表示某个影子操作，
3)ODoc表示关联某个文档doc的操作。
附图说明
图1：操作间因果并发关系。
图2：远程操作执行顺序和因果先序时间戳。
图3：操作分发与同步例子。

这里将给出一个详细的例子来说明具体实施方式。
考虑图3中的协同场景。图上半部分从左到右五条竖直线分别表示站点1，2，3，4，5， 下班部分的竖直线表示站点6。实时组编辑活动开始时，实时组编辑会话被划分成两个稳 定的实时组编辑域，站点1和站点3同属于一个稳定的实时组编辑域，站点5属于另一个稳定 的实时组编辑域，站点2和站点4分别为这两个稳定的实时组编辑域中的Leader协同站点。
实时组编辑活动开始后不久，站点1上生成了一个新的用户文档数据操作O11，遵循操作 分发规则1，站点1并没有立即将O11向所有的其它协同站点站点2、站点3、站点4以及站点5 广播，而是先发送给站点2——同一个稳定的实时组编辑域中的Leader协同站点。在站点2， 当接收到站点1发送过来的远程用户文档数据操作O11后，它立即为之生成一个影子操作O21， 并代为将操作O11，与O21一起，向实时组编辑环境中的所有协同站点广播。O11在协同站点间 的转发都始终附带着站点2为之生成的影子操作O21，O11到达站点3、站点4和站点5时，这三 个站点，从收到的数据包里，都可以直接找到它的影子操作O21。图中可以看出，三个站点 对O11和O21的同步都是一先一后连续的不中断地进行的，遵从操作同步步骤2。
站点3上对本地生成的第一个操作O31的处理也是类似的。留意站点2上收到来自于站点 3的远程用户文档数据操作O31时的处理，此时，O11刚好执行完毕，站点2还未来的及为它生 成一个影子操作，根据影子操作的生成方法——Leader协同站点为一个远程用户文档数据 操作生成影子操作，必须在执行该操作之后立即进行，中间不能执行任何其它操作，因此， O31在站点2的同步不得不被延迟。
生成操作O21后，站点2立即对O31进行同步，并为之生成影子操作O22。尽管操作O11和 O21先于操作O31和O22从站点2上被发出，然而，由于网络传输的不稳定性，操作O31和O22还 是先于操作O11和O21到达站点5。操作O22因果依赖于O11和O21。在所有的协同站点上，操作 O11和O21都应先于O22被执行，因此，在站点5上，操作O22的同步被延迟直到执行完操作O11 和O21之后。值得注意的是，尽管到达站点5时，操作O31已经是因果就绪的了(操作O31不因 果依赖于任何操作)，它在站点5上的同步也一起被延迟到了执行完操作O11和O21之后。这 是必须的，在站点5上，远程用户文档数据操作O31必须与至少一个它的影子操作一起先后 连续地被执行，这里O31只有一个影子操作O22，O22的同步被延迟了，O31的同步也只能跟着 被延迟。
生成操作O11后，在站点1上又产生了第二个用户文档数据操作O12，和O11一样，它也立 即被发往了站点2——同一个稳定的实时组编辑域中的Leader协同站点。O12在站点2上执 行后，站点2为它生成了影子操作O23，然而，O23并没有被成功的广播出去，在T时刻，站 点2突然发生故障。检测到站点2无法被连接上，一个新的Leader协同站点“站点6”被建立 起来，取代站点2，作为站点1和站点3的“Leader”。站点6新建后，立即与实时组编辑环境 中的其它协同站点进行同步，站点依次收到操作(远程操作)O51、O41、O11、O21、O31、O22 以及O12、其中操作O41是O51的影子操作、操作O21是O11的影子操作、操作O22是O31的影子操 作。操作O51、O41、O11、O21、O31以及O22在站点6上的同步都被尽可能地延迟：站点6上对操 作O11、O21、O31以及O22的同步被延迟直到收到操作O12——O12被发送到站点6时，并没有附 带它的影子操作，遵循操作分发规则2必须立即被同步，O12因果依赖于O11、O21、O31以及 O22，必须后于这四个操作被同步，从而迫使站点6终止延迟并立即同步O11、O21、O31以及 O22；而对操作O51和操作O41，站点6直到最后也没有对它们进行同步。站点6对操作O12进行 同步后，为它生成了一个新的影子操作O61，此后，如果站点5从故障中恢复过来，实时组 编辑环境中将存在两个与操作O12相关的影子操作。在我们的协同交互模型中，系统中，针 对每个用户文档数据操作一般只会产生一个影子操作，只有在例子中所示的突发状况下， 才可能出现一个用户文档数据操作相关两个或更多影子操作的现象。
图中注明了每个操作的直接因果先序向量时间戳，可以看出，正如我们在对操作同步 步骤2和3的分析中所提到的，每个用户文档数据操作都只直接因果依赖于虚拟协同操作以 及其生成站点上之前产生的用户文档数据操作(如果存在的话)，每个虚拟协同操作都只 直接因果依赖于它所对应的用户文档数据操作以及其生成站点上之前虚拟协同操作。
实际应用：将单机版的Autocad开发成支持实时组编辑的CoAutoCAD。
为了支持大规模协同环境，适应各种协同活动，我们使用直接因果先序向量 时间戳作为主要的因果并发检测工具，并采用了Leader优先协同交互模型。在我们的系统 中，存在两类不同的协同站点：用户协同站点和Leader协同站点。用户协同站点为协同参 与者提供访问共享文档数据的用户操作界面，为协同参与者参与实时组编辑活动提供必要 的工具和操作平台；Leader协同站点主要负责协调协同用户间的操作分发与同步，并生成 一些虚拟的协同操作，辅助参与协同交互模型、控制实时组编辑活动中的操作时间戳开销。 目前CoAutoCAD已经做成产品。