大规模协同环境下的协同交互优化方法
阅读：864发布：2020-06-10
专利汇可以提供大规模协同环境下的协同交互优化方法专利检索，专利查询，专利分析的服务。并且本 发明 属于计算机支持的协同工作技术领域，具体为大规模协同环境下的协同交互优化方法。该方法使用一种Leader 站点 优先方法建立实时组编辑协同交互模型，包括：用户间协同交互模式的调整策略和Leader优先协同交互模型；通过限制各协同站点上远程操作的同步顺序，能够在高并发的大规模协同环境下，有效控制操作的直接因果先序向量时间戳的大小；通过将实时组编辑会话根据协同站点间的网络状况合理分区，并适当引入一些虚拟协同站点参与协同交互模型，能够继续保持用户间较高的协同 感知 性能。本发明有助于解决高并发大规模的协同环境下实时组编辑活动因果并发检测问题，大大提高组编辑活动的性能。，下面是大规模协同环境下的协同交互优化方法专利的具体信息内容。
1.大规模协同环境下的协同交互优化方法，其特征在于包括以下主要步骤：
步骤1：调整交互模式
在一个有着N个协同站点的实时组编辑环境中，任意给定一个整数M，2＜M＜N，假设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：设立Leader协同站点，设定影子操作
(1)选取一个站点设为Leader协同站点，用于协调域内各协同站点上操作的分发与同步，并生成一些虚拟的协同操作，这些站点只用作协同，不提供用户访问修改共享文档数据的操作界面和工具；
(2)协同站点上生成的关联与某个用户文档数据操作的虚拟协同操作，称为该操作的影子操作，要保证影子操作在某个操作产生后立即执行，中间不会执行任何其它操作；
步骤3：协同站点上的操作分发
(1)将用户文档数据操作从一个协同站点向另一个协同站点分发时，必须附带发送至少一个与之相关的影子操作；唯一的例外：用户协同站点向同一个稳定的实时组操作域中的Leader协同站点发送它的本地用户文档数据操作时，不需要附带相关的影子操作；
(2)给定一个Leader协同站点SL，假设ODoc是SL上新接收到的一个用户文档数据操作，ODoc的相关影子操作并没有随ODoc一起被发送到Leader协同站点SL上；则：
①ODoc没有在SL上执行过：SL应尽快地执行ODoc，为它生成一个影子操作ψ，然后将ODoc，附上新生成的虚拟协同操作ψ，一起向所有的其它协同站点分发；
②ODoc已经在SL上执行过：此时从SL的历史操作列表中找到与ODoc相关的影子操作，记为ψ，SL应立即将操作ODoc，附上ψ，一起向所有的其它协同站点分发；
步骤4：协同站点上的操作同步
(1)本地站点上收到的远程操作必须等到因果就绪后才可以被同步；
(2)在协同站点上，每同步一个远程的用户文档数据操作，紧跟着执行的总是一个与之相关的影子操作；
(3)给定一个Leader协同站点SL，O是SL上收到的一个远程用户文档数据操作；SL应该尽可能的推迟对操作O的同步，如果它在收到操作O的同时也收到了O的一个影子操作ψ。
大规模协同环境下的协同交互优化方法
技术领域
[0001] 本发明属于计算机支持的协同工作技术领域，具体涉及在大规模协同环境下协同交互优化方法。
背景技术
[0002] 1.实时组编辑系统
[0003] 单用户的文档编辑系统，如普通的文档编辑器，在人们生活中已经十分普遍。但近年来随着Internet的发展和社会合作的需求，将这些单用户的编辑系统移植到多用户的环境下，允许多个用户通过计算机网络同时浏览、编辑一个共享数据对象，使之能够在多用户协同工作时发挥重要的作用，这样的需求也就自然而然地产生了，这种编辑系统称为组编辑系统。
[0004] 实时组编辑系统是组编辑系统中应用最广泛的一种，其必须满足实时性、分布式和提供用户无限制编辑的特性。现在普遍采用全复制式结构来实现这种系统，也就是说，每个用户都有一个文档数据副本，而且他们被允许并发地、同步地修改这份共享文档。这里有三个条件必须被满足，那就是结果一致、因果一致和用户意图一致。结果一致指同一操作集合在所有站点执行后，这些站点上的文档状态一致。因果一致指对于任意两个操作Oa和Ob，如果在Ob的初始站点上，Oa在Ob生成前已被生成或执行，则在所有站点上Oa都应早于Ob被执行。用户意图一致指对于任意操作O，其在所有站点上的执行效果都应保持O的原有意图，同时O的执行效果不能影响那些与O并发的操作的执行效果。
[0005] 2.大规模协同环境
[0006] 尽管目前对实时组编辑的研究已经取得了很大的进展，然而，现有的对实时组编辑的研究都还主要局限于小组协同(人数小于10)。在更大规模的协同环境中(人数大于10，甚至成百上千)支持实时组编辑活动会遇到什么样的特殊问题？比如远程Autocad教学的例子，学习者可以通过编辑修改一份共享AutoCAD文档数据，实时地相互交流，不必再局限于白板、Instant Messenger等通用的协同交互工具，这样的交流方式更为直接，往往也更有利于学习者表达自己的观点和想法。但这种远程教学学生群规模庞大，可以认为是大规模协同环境。
[0007] 3.因果与并发关系检测
[0008] 全复制结构下的实时组编辑系统允许用户并发的编辑修改他们各自的文档数据副本。两个操作具有因果关系指的是一个操作在另一个操作的产生之前已经执行；而两个操作并发指的是这两个操作不存在因果关系。准确识别操作间的因果并发关系是正确维护实时组编辑一致性的基础。实时组编辑应用中的因果并发关系判断主要涉及三方面的问题： 判断一个操作是否因果就绪：网络传输具有不确定性，操作以它们的生成顺序先后发出，却未必能按相同的顺序到达目标站点。
[0009] (2)找出所有之前执行过的与当前正在执行的远程操作并发的操作。本地站点收到从远程站点发过来的这种操作时，首先需要对这种操作作转换，因为该操作从产生到传输完毕，本地产生了新的操作。如果将该远程操作直接执行。会导致不一致的情况。那么转换就意味着远程操作要根据本地操作作相应转换后再执行。
[0010] 目前比较操作间的相互关系主要手段是比较时间戳。传统的时间戳是一个N维的向量，向量的第i个元素记录的是第i个站点当前已执行操作个数。后来又有人提出直接因果先序时间戳DCV。
[0011] 4.DCV时间戳的优点和弊端
[0012] 定义：直接因果先序关系( )：给定两个任意的操作Oa和Ob，Oa直接因果先序于Ob，记为Oa Ob，当且仅当(1)Oa→Ob并且(2)不存在一个操作Oc，满足Oa→Oc且Oc→Ob。
[0013] 定义：直接因果先序向量时间戳(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)。
[0014] 和传统向量时间戳相比，DCV表示方法比较明显的削减了每个操作所带的时间戳的规模。参考图1，从左到右三条直线分别表示站点1，2，3上的操作顺序。图中的6个操作，O12直接因果依赖于O11，O12和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)]。
[0015] 直接因果先序向量时间戳的优点在于其是一种动态时间戳，系统不为协同参与者预留时间戳分量，一个从不修改共享文档数据的“只读”协同参与者并不会对时间戳的大小产生影响。因此，在一个使用直接因果先序向量时间戳技术的实时组编辑系统中，操作的时间戳大小总是小于等于实际参与修改共享文档数据的协同参与者的人数。
[0016] 而这种时间戳的缺点在于，由于它是动态的时间戳，所以检测并发操作的时候需要比较自己的直接因果先序操作和当前操作，才能得出结论，显得不是那么简洁明了。而且DCV一定程度上反映并发程度，一旦并发性极高的情况下，DCV的规模会直线上升。所以在这种大规模并发环境下要是能根据DCV特点修改相应的检测方法，或者缩小时间戳的规模，都会对效率提高起到关键作用。
发明内容
[0017] 本发明的目的在于提出一种在大规模协同环境下提高并发操作检测效率的协同交互优化方法。
[0018] 传统的向量时间戳可伸缩性差，于是我们对交互进行修改，提出了远程操作的调整方法，然后为了支持这种策略，提出了Leader优化的协同模型和在此模型下的分发与操作同步方法，尽可能地用一整套方案来提高大规模协同环境下组编辑效率。
[0019] 步骤1：交互模式的调整，远程操作执行顺序的调整
[0020] 在一个有着N个协同站点的实时组编辑环境中，任意给定一个整数M，2＜M＜N，我们总能通过下列调整将操作的直接因果先序向量时间戳大小控制在≤M的范围内。假设N个协同站点分别为S1，S2.S3...，SN，对每一个协同站点Si(1≤i≤N)，按照以下两个步骤调整交互模式
[0021] 1)对来自于Sj(o＜i-j＜M或i-j＜M-N)的操作，立即同步，只要它满足因果就绪条件。
[0022] 2)对来自于其它站点的操作，延迟对它的同步，直到收到一个来自于站点Sk(o＜i-k＜M或i-k＜M-N)的且直接因果依赖于它的操作。那么对于每一个协同站点Si(1≤i≤N)，其上产生的操作都只可能直接因果依赖于来自于站点Sj(o≤i-j＜M或i-j＜M-N)的操作，这些操作的直接因果先序向量时间戳的大小必然≤M。
[0023] 直接因果先序向量时间戳具有一个有趣的特性：在实时组编辑活动中，通过合理规范各协同站点上远程操作的同步顺序，可以有效地控制操作的直接因果先序向量时间戳大小。考虑图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)]。
[0024] 现在考虑执行顺序调整后的协同场景，也就是加上了图中的虚线，同样的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的直接因果先序向量时间戳大小减小了，其它操作的直接因果先序向量时间戳都没变，操作在各站点间分发，总的时间戳开销变小了。
[0025] 上面我们已经给出了一种用户间协同交互模式的调整策略，在使用直接因果先序向量时间戳技术的实时组编辑系统中，基于该策略调整用户间的协同交互模式可以灵活有效地控制住实时组编辑活动中的操作时间戳开销。现在考虑任意的协同站点Si，假设所有的站点Sj(o＜i-j＜M或i-j＜M-N)都一直处于不活跃的状态，不产生任何操作，按照上述规定，站点Si将不能同步任何收到的远程操作，协同站点Si上的协同用户将很长时间无法感知其它用户的操作情况。如果这样的情况在很多协同站点上发生，必然会影响用户间的协同效率。
[0026] 由此，本发明是建立一些虚拟的协同站点，称为Leader协同站点，并在这些虚拟协同站点上定期地生成一些虚拟的协同操作。通过引入虚拟的协同站点、虚拟的协同操作，参与调整协同交互模式，控制实时组编辑活动中的操作时间戳开销，可以避免影响用户正常的协同工作，因为虚拟协同站点的网络布局、虚拟协同站点上虚拟协同操作的生成频率都是我们可以根据需要随时调整的。通过规定，对于收到的远程用户文档数据操作(不包括Leader协同站点上生成的虚拟协同操作)，用户协同站点(不包括Leader协同站点)必须延迟对它的同步直到收到一个来自于Leader协同站点的且直接因果依赖于它的虚拟协同操作，可以确保，每一个新生成的用户文档数据操作都只直接因果依赖于同一个协同站点上生成的其它用户文档数据操作，或者Leader协同站点上生成的虚拟协同操作。这样，只需要控制好虚拟站点的数量就能有效地控制住每个用户文档数据操作的时间戳大小、控制住实时组编辑活动中的操作时间戳开销。
[0027] 步骤2：设立Leader优先协同站点
[0028] 1)选取一个站点设为Leader虚拟站点，用于协调域内各协同站点上操作的分发与同步，并生成一些虚拟的协同操作。这些站点只用作协同，不提供用户访问修改共享文档数据的操作界面和工具。
[0029] 2)协同站点上生成的关联与某个用户文档数据操作的虚拟协同操作，称为该操作的影子操作。在实现中，要保证影子操作在某个操作产生后立即执行，中间不会执行任何其它操作。
[0030] 在每个稳定的实时组编辑域中，都有一个Leader协同站点，这是一些虚拟的协同站点，用于协调域内各协同站点上操作的分发与同步，并生成一些虚拟的协同操作，辅助参与协同交互模型、控制实时组编辑活动中的操作时间戳开销。Leader协同站点不提供协同用户访问修改共享文档数据的操作界面和工具。为了区分，在下文中，我们用用户协同站点表示那些提供共享文档数据访问修改操作界面的直接面向协同参与者提供服务的真正的协同站点，另外，如果没有特殊说明，我们提到的协同站点，都同时指代用户协同站点和Leader协同站点。我们要求，每个稳定的实时组编辑域中都有可用的Leader协同站点。如果由于网络连接情况的变化，或是原有的Leader协同站点发生意外故障等，在一个稳定的实时组编辑域中没有了可用的Leader协同站点，系统应在一个尽可能短的时间内重新建立一个新的Leader协同站点。我们并不限制在每个稳定的实时组编辑域中的Leader协同站点的数量，然而，在一个稳定的实时组编辑域中建立多个Leader协同站点是毫无意义的，只会增加系统的开销，因此，应该尽可能保持每个稳定的实时组编辑域中都仅仅只有一个Leader协同站点。
[0031] Leader协同站点参与协同交互模型，会生成一些虚拟的协同操作。之所以称这些操作是“虚拟”的，因为它们作为协同操作却并不对共享文档数据作任何修改。为了区分，在下文中，我们用用户文档数据操作指代那些会对共享文档数据产生影响的真正的协同操作如Insert、Delete等，另外，没有特殊说明，我们提到的操作、远程操作、本地操作等都将同时指代用户文档数据操作和Leader协同站点上生成的虚拟协同操作。
[0032] Leader协同站点上生成虚拟协同操作，总是关联于一个用户文档数据操作ODoc，称作为ODoc生成影子操作；生成的虚拟协同操作，我们称之为ODoc的影子操作，或是与ODoc相关的影子操作。Leader协同站点为一个用户文档数据操作生成影子操作，总是在执行了该操作之后立即进行的，中间不会执行任何其它操作，给定一个用户文档数据操作O，以及它的影子操作ψo，必然有O ψo。Leader协同站点不提供协同用户访问修改共享文档数据的操作界面，不面向协同用户提供服务，因而，Leader协同站点上不会生成任何用户文档数据操作，即除了被称为影子操作的虚拟协同操作，Leader协同站点上不会生成任何其它类型的协同操作。
[0033] 步骤3：协同站点上的操作分发
[0034] 1)将用户文档数据操作从一个协同站点向另一个协同站点分发时，必须附带发送至少一个与之相关的影子操作。唯一的例外：用户协同站点向同一个稳定的实时组操作域中的Leader协同站点发送它的本地用户文档数据操作时，不需要附带相关的影子操作。
[0035] 相比传统实时组编辑系统一但产生操作则立即向其他站点发送的做法，这里按照分步骤(1)，用户协同站点将新生成的用户文档数据操作分发给其它协同站点，必须通过Leader协同站点间接地进行。后面可以看到，在我们的实时组编辑交互模型中，对远程用户文档数据操作以及它的相关影子操作的执行顺序与执行时间都有着严格的要求，此规则确保当用户协同站点收到一个远程的用户文档数据操作时，同时也收到了它的影子操作，从而可以简化相关的处理过程。
[0036] 2)给定一个Leader协同站点SL，假设ODoc是SL上新接收到的一个用户文档数据操作，ODoc的相关影子操作并没有随ODoc一起被发送到Leader协同站点SL上。
[0037] ①ODoc没有在SL上执行过：sL应尽快地执行ODoc，为它生成一个影子操作ψ，然后将ODoc，附上新生成的虚拟协同操作ψ，一起向所有的其它协同站点分发；
[0038] ②ODoc已经在SL上执行过：此时从SL的历史操作列表中找到与ODoc相关的影子操作(即直接因果依赖于ODoc的虚拟协同操作)，记为ψ。SL应立即将操作ODoc，附上ψ，一起向所有的其它协同站点分发。
[0039] 一个用户文档数据操作ODoc，没有附带与之相关的影子操作，被单独发送到Leader协同站点SL，这往往暗示(1)同一个稳定的实时组编辑域中的其它协同站点(除了ODoc的生成站点)都还没有执行过这个用户文档数据操作(2)操作的生成站点没有与ODoc相关的影子操作记录，则无法将该操作分发出去。我们制定操作分发规则，要求Leader协同站点SL尽快地处理ODoc将ODoc进一步分发给所有其它协同站点，是为了确保较高的协同感知性能。让协同用户尽快地尽可能实时地感知互相的行为操作和意向，这是实时组编辑系统的一个基本性能要求。
[0040] 步骤4：协同站点上的操作同步。
[0041] (1)本地站点上收到的远程操作必须等到因果就绪后才可以被同步。
[0042] 远程操作的同步顺序不能违背它们的因果先序顺序，每个远程操作都必须等所有它所因果依赖于的操作都执行后才能执行。这是实时组编辑一致性模型所要求的，在实时组编辑活动中永远都不应被违背。
[0043] (2)在协同站点上，每同步一个远程的用户文档数据操作，紧跟着执行的总是一个与之相关的影子操作。操作同步规则2是Leader优先协同交互模型的核心，是Leader优先协同交互模型能够实现灵活控制实时组编辑活动中时间戳开销的基础。
[0044] 分步骤(2)将确保：1.所有韵用户文档数据操作，除了同一个站点上产生的其它用户文档数据操作以及各Leader协同站点上产生的虚拟协同操作，不会直接因果依赖于任何其它操作。2.所有的虚拟协同操作(影子操作)，除了它所对应的用户文档数据操作以及各Leader协同站点上产生的虚拟协同操作，不会直接因果依赖于任何其它操作。总之，所有操作的直接因果先序向量时间戳大小都小于等于当前系统中的Leader协同站点的数量加1，也就是说，我们可以通过控制Leader协同站点的数量有效控制实时组编辑活动中的时间戳开销。
[0045] 下面是步骤(2)的实现。如果一个用户文档数据操作O，没有附带与之相关的影子操作，被单独发送到协同站点S(O之前没有在S上执行过)。则S必然是一个Leader协同站点。而且，协同站点S执行了操作O以后会不间断地立即生成一个虚拟协同操作ψ。ψ是O的影子操作，O和ψ在S上一先一后连续执行，如果协同站点S在收到用户文档数据操作O的同时，也收到了与之相关的影子操作，记为ψ，O ψ。假设ψ的生成站点是SL，在执行操作O并生成ψ之前，SL一直都很好地遵守着操作同步规则的规定，更具体的，SL上之前执行过的任意一个用户文档数据操作O’，其后都紧跟着执行了一个与之相关的影子操作ψ’，O’→ψ’。容易推断，O不仅是ψ的直接因果先序前继，也是唯一的直接因果先序于ψ的用户文档数据操作。O和ψ在S上一先一后连续执行，应该是可行的，也不会产生任何问题(不会干扰其它操作，主要是其它用户文档数据操作的执行)。
[0046] (3)给定一个Leader协同站点SL，O是SL上收到的一个远程用户文档数据操作。SL应该尽可能的推迟对操作O的同步，如果它在收到操作O的同时也收到了O的一个影子操作ψ。
[0047] 分步骤(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，这就与我们之前的推理发生了矛盾。
[0048] 上文中，N表示站点个数，Si表示标识为Si的协同站点。
[0049] 1)Oxy表示某个从站点x产生的第y个操作，
[0050] 2)ψ表示某个影子操作，
[0052] 图1：操作间因果并发关系。
[0053] 图2：远程操作执行顺序和因果先序时间戳。
[0054] 图3：操作分发与同步例子。
具体实施方式
[0055] 这里将给出一个详细的例子来说明具体实施方式。
[0056] 考虑图3中的协同场景。图上半部分从左到右五条竖直线分别表示站点1，2，3，4，5，下班部分的竖直线表示站点6。实时组编辑活动开始时，实时组编辑会话被划分成两个稳定的实时组编辑域，站点1和站点3同属于一个稳定的实时组编辑域，站点5属于另一个稳定的实时组编辑域，站点2和站点4分别为这两个稳定的实时组编辑域中的Leader协同站点。
[0057] 实时组编辑活动开始后不久，站点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。
2。
[0058] 站点3上对本地生成的第一个操作O31的处理也是类似的。留意站点2上收到来自于站点3的远程用户文档数据操作O31时的处理，此时，O11刚好执行完毕，站点2还未来的及为它生成一个影子操作，根据影子操作的生成方法——Leader协同站点为一个远程用户文档数据操作生成影子操作，必须在执行该操作之后立即进行，中间不能执行任何其它操作，因此，O31在站点2的同步不得不被延迟。
[0059] 生成操作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的同步也只能跟着被延迟。
[0060] 生成操作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相关的影子操作。在我们的协同交互模型中，系统中，针对每个用户文档数据操作一般只会产生一个影子操作，只有在例子中所示的突发状况下，才可能出现一个用户文档数据操作相关两个或更多影子操作的现象。
而对操作O51和操作O41，站点6直到最后也没有对它们进行同步。站点6对操作O12进行同步后，为它生成了一个新的影子操作O61，此后，如果站点5从故障中恢复过来，实时组编辑环境中将存在两个与操作O12相关的影子操作。在我们的协同交互模型中，系统中，针对每个用户文档数据操作一般只会产生一个影子操作，只有在例子中所示的突发状况下，才可能出现一个用户文档数据操作相关两个或更多影子操作的现象。
[0061] 图中注明了每个操作的直接因果先序向量时间戳，可以看出，正如我们在对操作同步步骤2和3的分析中所提到的，每个用户文档数据操作都只直接因果依赖于虚拟协同操作以及其生成站点上之前产生的用户文档数据操作(如果存在的话)，每个虚拟协同操作都只直接因果依赖于它所对应的用户文档数据操作以及其生成站点上之前虚拟协同操作。
[0062] 实际应用：将单机版的Autocad开发成支持实时组编辑的CoAutoCAD。
[0063] 为了支持大规模协同环境，适应各种协同活动，我们使用直接因果先序向量时间戳作为主要的因果并发检测工具，并采用了Leader优先协同交互模型。在我们的系统中，存在两类不同的协同站点：用户协同站点和Leader协同站点。用户协同站点为协同参与者提供访问共享文档数据的用户操作界面，为协同参与者参与实时组编辑活动提供必要的工具和操作平台；Leader协同站点主要负责协调协同用户间的操作分发与同步，并生成一些虚拟的协同操作，辅助参与协同交互模型、控制实时组编辑活动中的操作时间戳开销。目前CoAutoCAD已经做成产品。
| 标题 | 发布/更新时间 | 阅读量 |
|---|---|---|
| 用于对图像进行编码和解码的方法和装置 | 2020-05-15 | 531 |
| 一种过程控制系统信息安全防护的异常检测方法 | 2020-05-20 | 203 |
| 重叠块差异估计和补偿体系结构 | 2020-06-16 | 230 |
| 一种海洋生态环境损害因果关系判定方法 | 2020-05-17 | 211 |
| 一种基于功能磁共振成像的脑区效应连接分析系统 | 2020-05-24 | 566 |
| 基于匹配地震子波的物理小波的地震瞬时频率分析方法 | 2020-06-11 | 1011 |
| 一种保证事务一致性和线性一致性的分布式系统和方法 | 2020-05-13 | 779 |
| 信息的检索管理交流的方法和系统 | 2020-06-15 | 82 |
| Method and system for partitioning contention based resources in a wireless network | 2020-05-28 | 965 |
| ESTIMATION DE MOUVEMENT AU NIVEAU DU DÉCODEUR PAR MISE EN CORRESPONDANCE MODÈLES | 2020-05-31 | 843 |
高效检索全球专利专利汇是专利免费检索,专利查询,专利分析-国家发明专利查询检索分析平台，是提供专利分析，专利查询，专利检索等数据服务功能的知识产权数据服务商。
我们的产品包含105个国家的1.26亿组数据，免费查、免费专利分析。
分析报告
专利汇分析报告产品可以对行业情报数据进行梳理分析，涉及维度包括行业专利基本状况分析、地域分析、技术分析、发明人分析、申请人分析、专利权人分析、失效分析、核心专利分析、法律分析、研发重点分析、企业专利处境分析、技术处境分析、专利寿命分析、企业定位分析、引证分析等超过60个分析角度，系统通过AI智能系统对图表进行解读，只需1分钟，一键生成行业专利分析报告。
因果分区热门专利
QQ群二维码
意见反馈
意见反馈