实时云办公系统下文件管理的一致性维护方法

摘要

本发明涉及一种实时云办公系统下文件管理的一致性维护方法，在云环境下高效处理大量数据用到了负载均衡算法：首先，当协同人数很少，一台服务器就能够很快的处理完成，直接服务器处理完成即可，当协同人数过多达到设定的临界值，此时对数据进行分流，多台服务器同时工作，快速处理完成并将部分处理结果反馈到一台服务器上，进行最终处理，提出改进COT算法使其适应云环境下新的集中式架构，减少不必要的传输数据，减少查询转换时间来达到更高的实时性要求；将云存储下的文件模型改进成协同云办公文件管理系统，并针对文件模型中文件节点的三个操作Create，Delete，Rename将改进的COT算法应用到协同办公系统下文件管理中。

说明书

技术领域

本发明涉及一种计算机文件管理技术，特别涉及一种实时云办公系统下文件管理的一致性维护方法。

背景技术

云办公系统允许分布不同地域的用户通过计算机网络随时随地的在云环境下协同办公，文件管理是办公系统中的重要组成部分。传统的办公系统的文件管理一般是在单机环境下进行，工作效率较低，而利用云的强大处理数据能力和高效性，在云环境下的多人实时协同文件管理将显得高效且便捷，如图1所示单服务器环境和云环境比较示意图。

实时的协同工作要求在用户进行交互的过程中即时可见，即用户的编辑操作效果在各个站点即时可见，且各站点的文档状态保持一致性，并满足各用户的操作意图。常用的一致性维护技术有操作转换技术(OT)，地址空间转化算法(AST)和版本控制技术。文件系统是典型的树形结构，对于AST技术，回溯过程需要大量的操作来维持结构的变化，效率较低。而OT技术则能较好的解决非线性文档一致性的问题。基于OT思想的较好的控制算法有：dOPT，GOT，GOTO，COT等，其中GOT，GOTO只在线性文档的状态下适用，COT是基于上下文的操作转换控制算法，COT算法可以很好的适应树形文档的数据模型，但传统的COT算法是在P2P的环境下工作，有很大的局限性，首先，协同站点数在工作前确定，且不允许中途退出，其次，P2P环境下的COT在每次传输时都要附带一个文档状态的文本C(O)，当协同工作过长或操作过多时，C(O)就会变得很庞大，降低了实时性影响用户体验。在新的云环境C/S架构下，用户的流动性和大量性会对实时协同工作造成很大的干扰，这需要设计新的控制算法支持大量用户的动态加入和退出，并保证高可靠的实时性。

web应用是具有天然跨平台优势，利用网页来实现工作方便快捷，在基于OT技术的控制算法中，目前只有Google Wave所采用的Jupiter算法和TIPS协议是完整支持集中式架构的。传统的HTTP每次发送信息都带有完整的头信息，不满足要求低延时的应用。而HTML5规范的WebSocket协议可以实现实时的全双工通信，不用附加无用的HTTP头信息，这大大的降低了带宽的占用，提高了性能。

发明内容

本发明是针对云环境下新的架构体系和更高的实时性要求的问题，提出了一种实时云办公系统下文件管理的一致性维护方法，提出改进的Improved_COT算法，在WebSocket协议的基础上设计并实现系统原型CloudFile-System(云办公系统)，并将改进的算法应用到该系统中，主要解决文件管理中的三个典型的操作命令creat(创建一个新文件)，rename(改变文件名字)，delete(撤销一个文件)的冲突，使得云办公系统中的各个用户站点和服务器实现一致性的结果。

本发明的技术方案为：一种实时云办公系统下文件管理的一致性维护方法，具体包括如下步骤：

A建立数据模型：

定义1：树形文档复制空间,树形结构中各节点都是层次结构，T＝(N),N是树中的节点，节点N＝{N0，N1，N2，N3.....}表示树形文档中各节点的集合，N.param＝{name,PN,Depth}:表示节点N的属性集，其中name是节点名称，PN为路径，Depth为层级；

定义2：Depth是节点所处树形结构中的层级，根节点层级默认为0；

定义3：路径PN是节点Ni从根节点N0到Ni路径，定义的路径由根节点到上层父亲节点的路径加上该节点的名字命名组成，假设两个路径Ni.PN和Nj.PN会有以下rn1-rn4四种关系：

rn1:Ni.PN＝Nj.PN:表示节点Ni和Nj指向相同的节点，

rn2:Ni.PN∈Nj.PN:表示节点Ni是节点Nj的上层节点，

rn3:Nj.PN∈Ni.PN:表示节点Nj是节点Ni的上层节点，

rn4:Ni.PN≠Nj.PN&Ni.PN￠Nj.PN&Nj.PN￠Ni.PN：表示节点Ni和Nj没有直接关系，对节点操作没有影响,

对于一个已经建立的树形结构，对于任意两个路径Ni.PN和Nj.PN，进行如下路径关联：

1)对层级判断，如果Ni.Depth>Nj.Depth，则进入步骤2)

2)Ni.PN∈Nj.PN是否为真，如真，则进行rn2判断，如不真进行rn4判断；

3)对层级判断，如果Ni.Depth＝Nj.Depth，则进入步骤4)

4)Ni.PN＝Nj.PN是否为真，如真，则进行rn1判断，如不真进行rn4判断；

5)对层级判断，不满足1)或3)则进入步骤6)

6)Nj.PN∈Ni.PN是否为真，如真，则进行rn3判断，如不真进行rn4判断；B:转换函数:

针对文件管理过程中的三个常见操作创建create、改名rename和删除delete操作做转换函数，给定并发操作Oa和Ob分别操作于节点i和节点j，Oa在Ob后执行，在Ob的基础上对Oa进行操作转换，如此针对三种操作模型有9种转换函数，如下表：

表中⊙表示兼容操作，⊕表示冲突操作，

在以上9种情况下的转换函数的算法：

B1：Oa＝create(Ni,Ninew),Ob＝create(Nj,Njnew),在这种情况下，两者的操作没有冲突，执行效果不变；

B2：Oa＝rename(Ni.nameold,Ni.namenew),Ob＝create(Nj,Njnew),在此种情况下，两者操作没有冲突，执行效果不变；

B3：Oa＝delete(Ni),Ob＝create(Nj,Njnew),若节点i是j的上层节点或者同一节点时，则Oa的返回效果是删除除了节点i到节点j之外的所有节点，其他情况保留原始的执行效果；

B4：Oa＝create(Ni,Ninew),Ob＝rename(Nj.nameold,Nj.namenew),若节点i和节点j是同一节点，则操作Oa的作用节点i的路径更改为节点j的路径，其他情况下则保留原始的执行效果；

B5：Oa＝rename(Ni.nameold,Ni.namenew),Ob＝rename(Nj.nameold,Nj.namenew)若i和j是同一节点时，保留本地的rename操作，并对该节点进行标记；若i是j的下层包含节点，修改Ni的路径，再执行Oa；其他情况，直接执行Oa；B6：Oa＝delete(Ni)，Ob＝rename(Nj.nameold，Nj.namenew),是在Ob操作之后对Oa操作做操作转换，当i和j是同一节点时，保留Ob操作的效果，Oa操作执行效果为空；当i是j的下层包含节点时，对Ni的路径进行修改，再返回正确的执行效果；其他情况，保留原始的执行效果；

B7：Oa＝create(Ni,Ninew),Ob＝delete(Nj),若节点j是节点i的下层节点或者是同一节点，则修改Ni的路径，使其恢复被删除的节点j到节点i的路径,再返回正确的执行效果，其他情况下则保留原始的执行效果；

B8：Oa＝rename(Ni.nameold,Nj.namenew),Ob＝delete(Nj),若i和j是同一节点，rename操作的执行效果是对delete操作做undo操作且加上rename的执行效果，若i是j的下层包含节点，那么rename执行效果为空；其他情况rename为原始执行效果；

B9：Oa＝delete(Ni),Ob＝delete(Nj)，若节点i是节点j的下层节点或者是同一节点，那么对操作Oa执行的效果就为空，其他情况为非冲突操作，执行效果不变；

C:Improved_COT算法:

在COT中，每次操作传输都带有C(O)，其中COT是基于上下文的操作转换算法，C(O)是COT中的各站点维护的文档状态,COT的工作核心是每次传到其他站点的操作执行COT(O,DS)，如下：

1)、可执行形式EO＝transform(O,DS-C(O))

2)、执行EO

3)、DS＝DS+{org(EO)}；

其中，DS是当前站点的文本状态，EO为操作O的可执行形式，org(EO)为操作O的原始形式，DS-C(O)代表着所有和操作O并发的并且已执行过的操作集合。首先将操作O与已执行过的并发操作进行包含转换得到可执行形式的操作EO，并执行，更新文本状态使其包含操作O的效果；

在协同工作开始后，在服务器端设置一个定时器Timer，TDS为在中心服务器上进行处理的操作序列，MDS为从各站点接受过来的操作序列集合，服务器每隔时间t向各站点发出接受DS'的请求，初始化MDS为DS’的集合，在云环境下高效处理大量数据用到了负载均衡算法：首先，当协同人数很少，一台服务器就能够很快的处理完成，直接服务器处理完成即可，当协同人数过多达到设定的临界值，此时对数据进行分流，多台服务器同时工作，快速处理完成并将部分处理结果反馈到一台服务器上，进行最终处理，这里设置一个临界值Limit表示当MDS的长度大于这个临界值的时候，处理过程使用handler(TDS)函数进行，最终将标记的序列FLAGCO发送到每个客户端；

在客户端接受到FLAGCO后，DS’副本进行标记，将生成新的DS’置为DS’-FLAGCO，这样每隔一个时间段服务器向每个站点发送一次请求，进行处理；

服务器端的hanlder(TDS)算法如下：

初始化CO0为TDS的第一个元素，依次与队列中的其他元素进行handler(DS1,DS2)处理，最终返回一个FLAGCO的序列，函数Handler(S1,S2)如下：

对来自两个站点的序列DS1和DS2处理如下，首先初始化两个为空的CO1和CO2，判断DS1和DS2是否有相同的队列长度，是，对DS1和DS2进行复制操作，产生DS1’和DS2’，对DS1’和DS2’中的操作按标记的序号进行排序操作，若DS1’和DS2’是相同的，则返回DS1，若不同维护一个DS’是找到DS1和DS2中的所有相同的元素，分别将DS1和DS2中的元素与DS’中的元素对比，存在DS’中的元素按在DS1和DS2中的顺序分别记录到CO1和CO2中，然后递归处理Handler(CO1,CO2)，直到找出满足条件的CO；

服务器端算法：线程1是为了监听用户的动态变化，每次有新的用户加入进来就给用户发送最新的文档副本，线程2接受各站点的操作进行Improved_COT算法处理，线程3将接收到的操作直接转发到其他站点；

客户端算法：线程1是在初次连接时接受来自服务器端的文档副本，线程2进行改进的COT控制算法，线程3是将产生的操作立即传到服务器端。

本发明的有益效果在于：本发明实时云办公系统下文件管理的一致性维护方法，提出改进COT算法使其适应云环境下新的集中式架构，减少不必要的传输数据，减少查询转换时间来达到更高的实时性要求；将云存储下的文件模型改进成协同云办公文件管理系统，并针对文件模型中文件节点的三个操作Create，Delete，Rename将改进的COT算法应用到协同办公系统下文件管理中。此外，开发了基于WebSocket的跨平台的实时云办公文件管理系统：CloudFileSystem来验证算法的可行性和有效性。

附图说明

图1为单服务器环境和云环境比较示意图；

图2为本发明云办公系统设计图；

图3为本发明文件结构示例图；

图4为本发明C/S架构站点工作图；

图5为本发明站点1OT转换过程图；

图6为本发明站点2OT转换过程图。

具体实施方式

一、基于WebSocket的系统设计：

本发明采用C/S架构，分为服务器端和客户端。在服务器端维持一个储存全局总历史操作序列的历史缓冲区，在客户端维持一个动态变换的局部历史序列的历史缓冲区。每隔一个固定的时间，服务器从每个客户端获取最新的操作序列，并进行处理，得到最大子集返回给各客户端。每次传输的信息都会保证在很小的范围，可有效提高实时办公的效率。

服务器端设计：采用Docker技术在一台物理计算机上运行3个服务端程序，模拟云环境的分布式服务，利用eclipse IDE J2EE来作为开发环境，将项目部署到tomcat8.0上，通过网页来访问。

客户端设计：基于webSocket协议设计的好处，传输效率高，速度快，CloudFileSystem利用SSM搭建框架，通过Jquery Ajax来实现信息的传输，Ajax通过局部异步请求，大大降低了传输的代价，同时在文件的存放上利用datatable的设计来设计文件的存放，使得开发过程简洁高效，CloudFileSystem的所示,输入正确的信息登录进入云系统后，点击协同文件管理进入到协同工作的环境，如图2所示云办公系统设计图：左边显示的协同在线的人，右边是协同工作的区域。

二、云办公系统的一致性维护策略：

实时文件管理系统允许多个用户同时对同一文件夹节点进行操作，是典型的树形文档结构。针对文件夹的create，rename和delete操作，设计了转换函数和控制算法来实现文件的一致性维护。

1、数据模型

定义1：树形文档复制空间

树形结构中各节点都是层次结构，节点之间的关联关系：T＝(N),N是树中的节点，节点N＝{N0，N1，N2，N3.....}表示树形文档中各节点的集合，N.param＝{name,PN,Depth}:表示节点N的属性集，其中name是节点名称，下面将对属性PN和Depth进行定义。

定义2：层级(Depth)

Depth是节点所处树形结构中的层级，根节点层级默认为0。层级是用来判断操作节点的位置关系的直接属性.先通过判断层级的大小来确定PN的关系，会大大提高检索效率。

定义3：路径(PathName,简称PN)PN是节点Ni从根节点N0到Ni路径，路径是树形结构下的所有节点都具备的信息，本文定义的路径由根节点到上层父亲节点的路径加上该节点的名字命名组成，如图3中B节点的路径是A/B,B节点是D节点的父亲节点，D节点路径PN＝B.PN+"/"+D.Name,路径是判断节点信息的唯一标识，假设有两个路径Ni.PN和Nj.PN有以下关系：

rn1:Ni.PN＝Nj.PN:表示节点Ni和Nj指向相同的节点。

rn2:Ni.PN∈Nj.PN:表示节点Ni是节点Nj的上层节点，如Ni节点的路径为A/B，Nj节点的路径为A/B/D，A/B属于A/B/D,B是D的上层节点。

rn3:Nj.PN∈Ni.PN:表示节点Nj是节点Ni的上层节点，如Nj节点的路径为A/B，Ni节点的路径为A/B/D，A/B属于A/B/D,B是D的上层节点。

rn4:Ni.PN≠Nj.PN&Ni.PN￠Nj.PN&Nj.PN￠Ni.PN：表示节点Ni和Nj没有直接关系，对节点操作没有影响。如节点A/B/D和节点A/C/F,分别对这两个节点产生的操作不会发生冲突。

路径的确定是根据从根节点到当前节点的name加上“/”来确定的，路径的关系确定是根据字符串匹配策略来实现的，当两个字符串之间是包含关系，即一个字符串是另一个字符串的子字符串的时候，由上述定义2，3，设计算法：

对于一个已经建立的树形结构，对于任意两个路径Ni.PN和Nj.PN，进行如下路径关联：

1)对层级判断，如果Ni.Depth>Nj.Depth，则进入步骤2)

2)Ni.PN＝Nj.PN是否为真，如真，则进行rn2判断，如不真进行rn4判断；

3)对层级判断，如果Ni.Depth＝Nj.Depth，则进入步骤4)

4)Ni.PN＝Nj.PN是否为真，如真，则进行rn1判断，如不真进行rn4判断；

5)对层级判断，不满足1)或3)则进入步骤6)

6)Ni.PN＝Nj.PN是否为真，如真，则进行rn3判断，如不真进行rn4判断。

2、转换函数

根据依赖关系及冲突兼容操作，给定并发操作Oa和Ob分别操作于节点i和节点j。Oa在Ob后执行，在Ob的基础上对Oa进行操作转换，如此针对三种操作模型有9种转换函数，如下表：

表中⊙表示兼容操作，⊕表示冲突操作。针对三大操作可能产生的几种冲突做出转换函数算法。上述各种情况是针对文件管理过程中的三个常见操作创建(create)，改名(rename)和删除(delete)操作做出的符合文件管理系统策略的几种转换函数。本文没有针对文件节点作讨论，设计了一个新的属性depth来加快操作转换的速率，在一些特殊的场合比如depth相等，那么直接比较depth,可以直接判断出是非冲突操作，另外由于云的特性，在一些操作并发冲突时，解决策略是每个操作附加一个时间标量属性来进行判断。

这里是以上9种情况下两个操作转换函数的算法：

1)Oa＝create(Ni,Ninew),Ob＝create(Nj,Njnew),在这种情况下，两者的操作没有冲突，执行效果不变。

2)Oa＝rename(Ni.nameold,Ni.namenew),Ob＝create(Nj,Njnew),在此种情况下，两者操作没有冲突，执行效果不变。

3)Oa＝delete(Ni),Ob＝create(Nj,Njnew),若节点i是j的上层节点或者同一节点时，则Oa的返回效果是删除除了节点i到节点j之外的所有节点。其他情况保留原始的执行效果。

4)Oa＝create(Ni,Ninew),Ob＝rename(Nj.nameold,Nj.namenew),若节点i和节点j是同一节点，则操作Oa的作用节点i的路径更改为节点j的路径。其他情况下则保留原始的执行效果。

5)Oa＝rename(Ni.nameold,Ni.namenew),Ob＝rename(Nj.nameold,Nj.namenew)若i和j是同一节点时，保留本地的rename操作，并对该节点进行标记；若i是j的下层包含节点，修改Ni的路径，再执行Oa；其他情况，直接执行Oa。6)Oa＝delete(Ni)，Ob＝rename(Nj.nameold，Nj.namenew),若i和j是同一节点时，保留Ob操作的效果，Oa操作执行效果为空；当i是j的下层包含节点时，对Ni的路径进行修改，再返回正确的执行效果；其他情况，保留原始的执行效果。

7)Oa＝create(Ni,Ninew),Ob＝delete(Nj),若节点j是节点i的下层节点或者是同一节点，则修改Ni的路径，使其恢复被删除的节点j到节点i的路径,再返回正确的执行效果。其他情况下则保留原始的执行效果。

8)Oa＝rename(Ni.nameold,Nj.namenew),Ob＝delete(Nj),若i和j是同一节点，rename操作的执行效果是对delete操作做undo操作且加上rename的执行效果，若i是j的下层包含节点，那么rename执行效果为空；其他情况rename为原始执行效果。

9)Oa＝delete(Ni),Ob＝delete(Nj)，若节点i是节点j的下层节点或者是同一节点，那么对操作Oa执行的效果就为空，其他情况为非冲突操作，执行效果不变。

3、Improved_COT算法设计

在COT中，每次操作传输都带有C(O)，其中COT是基于上下文的操作转换算法，C(O)是COT中的各站点维护的文档状态。随着协同工作的时间越来越长，C(O)中操作的数量也会越来越多，每次传输到服务器的操作的体积也越来越大，为了更好地做到实时性，设计合理有效的算法来减小C(O)的大小，又不影响COT的本质工作是保证实时性的重要前提。

COT的工作核心是每次传到其他站点的操作执行COT(O,DS)，如下

1)、可执行形式EO＝transform(O,DS-C(O))

2)、执行EO

3)、DS＝DS+{org(EO)}

其中，DS是当前站点的文本状态，C(O)是操作O的上下文状态，EO为操作O的可执行形式，org(EO)为操作O的原始形式，DS-C(O)代表着所有和操作O并发的并且已执行过的操作集合。首先将操作O与已执行过的并发操作进行包含转换得到可执行形式的操作EO，并执行，更新文本状态使其包含操作O的效果。

在上述1)步骤中，操作O的执行条件是将DS与C(O)中的操作对比，在C(O)中没有的操作将与O进行操作转换，那么在一次次操作操作传输过程中，DS和C(O)靠前的操作将会进行一次次无用的比对，这浪费了时间和传输开销，删除前面的操作变得非常重要，保证C(O)中的操作不会过多而拥塞传输造成实时性降低。在服务器器端和客户端维护两个文档DS,DS',DS与COT中DS一致，DS'是一个动态变化的文档状态。在服务器端应用的改进的C(O)算法设计如下：

在Algorithm 1中协同工作开始后，在服务器端设置一个定时器Timer，TDS为在中心服务器上进行处理的操作序列，MDS为从各站点接受过来的操作序列集合，服务器每隔时间t向各站点发出接受DS'的请求。初始化MDS为DS’的集合，在云环境下高效处理大量数据用到了负载均衡算法。首先，当协同人数很少，一台服务器也能够很快的处理完成，直接服务器处理完成即可，当协同人数过多达到设定的临界值，此时需要利用云服务的特性，对数据进行分流，多台服务器同时工作，快速处理完成并将部分处理结果反馈到一台服务器上，进行最终处理，这里设置一个临界值Limit表示当MDS的长度大于这个临界值的时候，在单台服务器上处理这些操作的时间大于数据在服务器之间传输的往返时间和处理时间的总和，因往返时间一般是固定的，且分发到其他服务器的数据是较短的，所以Limit的值可以经过实验固定下来。处理过程使用handler(TDS)函数进行，最终将标记的序列FLAGCO发送到每个客户端。

在Algorithm 2中客户端接受到FLAGCO后，DS’副本进行标记，将生成新的DS’置为DS’-FLAGCO，这样每隔一个时间段服务器向每个站点发送一次请求，进行处理，当协同时间过长也不会影响用户的响应速度和处理速度，保证很好的实时性。

在服务器端进行处理时最重要的就是如何对数据的处理，服务器端的hanlder(TDS)是本文的重点算法如下：

初始化CO0为TDS的第一个元素，依次与队列中的其他元素进行handler(DS1,DS2)处理，最终返回一个FLAGCO的序列，函数Handler(S1,S2)如下：

对来自两个站点的序列DS1和DS2处理如下，首先初始化两个为空的CO1和CO2，判断DS1和DS2是否有相同的队列长度，是，对DS1和DS2进行复制操作，产生DS1’和DS2’，对DS1’和DS2’中的操作按标记的序号进行排序操作，若DS1’和DS2’是相同的，则返回DS1，若不同维护一个DS’是找到DS1和DS2中的所有相同的元素，分别将DS1和DS2中的元素与DS’中的元素对比，存在DS’中的元素按在DS1和DS2中的顺序分别记录到CO1和CO2中，然后递归处理Handler(CO1,CO2)，直到找出满足条件的CO。

时间t的设置要看网络的状态，本发明设计的是在云平台的环境下，即PC端上能够提供较好的网络状态，所以，服务器和客户端的传输不会出现掉包等情况，时间t,可以设置在2分钟左右，协同办公的人数不会太大，上限设置为50人，那么在5分钟左右的时间，假设每分钟每个站点有100个操作，C(O)中的操作数量也是10000个，这个数量不会影响传输的操作，当然在网络状态不稳定的情况，我们暂时没做考虑。

服务器端主要接受来自各站点的操作，同时将负责操作转发到其他服务器，并且每个服务器都负责不同的功能，能大大的提高操作处理的速度，服务器端算法设计如下：

在Algorithm 8中线程1是为了监听用户的动态变化，每次有新的用户加入进来就给用户发送最新的文档副本。线程2接受各站点的操作进行Improved_COT算法处理。线程3将接收到的操作直接转发到其他站点。

客户端主要接受来自服务器转发不同客户端的操作然后直接执行COT就可以了，算法如下：

在Algorithm 6中线程1是在初次连接时接受来自服务器端的文档副本。线程2进行改进的COT控制算法。线程3是将产生的操作立即传到服务器端。

三、实例说明：

本节针对上述在文件管理中的转换函数给出实例论证，如图5所示，给出两个客户端站点S1，S2和服务器端站点Server，3个站点初始文档状态一致为如上图3所示，S1上给定操作O1＝rename(N2.B,N2.K)，将第三个节点的名字由B改为K，S2上给定操作O2和O3，O2＝delete(N5)，删除节点E，O3＝create(N2,J)，在节点B上创建进的子节点J。操作效果如图4所示：

站点1上先立即执行执行O1，此时文档状态DS＝{O1}，在发送给服务器，接受来自服务的操作O2，O3，C(O2)＝{}，根据COT的六条性质C(O2)包含DS但C(O2)≠DS，O2要与DS-C(O2)中的操作做操作转换，由上述转换函数的算法TR(dl，rn)判断O2'为先改变节点E的路径，在执行删除操作，当O3到来，C(O3)＝{O2}，如上情况，DS-C(O3)＝O1，由上述算法TR(cr，rn)对O3进行操作转化得到O3'为改变节点路径，再执行创建子节点操作，执行效果如图5。

站点2上立即执行本地操作O2，O3，此时文档状态DS＝{O2，O3}，在接收到来自服务器端转发S1的操作O1，C(O1)＝{}，满足性质C(O1)DS但C(O1)≠DS,此时O1要与DS-C(O1)中的操作依次进行操作转换，由上述TR(rn，dl)和TR(rn，cr)得到O1'＝O1，执行效果如图6。服务器端的操作执行顺序跟站点1的一致，这里不再说明。

由上述可知，最后两个站点的文档结构一致，数据在不同站点的维护了一致性，由此可见算法是正确可行的。

四、算法复杂度分析：

设每秒在每台机器上产生的操作数量为N，一起协同工作的站点数为S，在平均情况下，协同工作时间为T，服务器设定时间为t，Improved_COT的C(O)大小是N×S×T-FLAGCO(T/t)，由上述算法可知，FLAGCO是服务器每隔时间t进行的一次标记操作，在本文设定无丢包环境下，所有操作可以被正确接受和处理，即FLAGCO是在时间t的范围内的一个值为N×S×t，综上得知Improved_COT的C(O)大小近似为N×S×t。一般情况下N和S是在一个变化不大的区间变化的可看作固定值，所以Improverd_COT是与t是一个线性的关系，即空间复杂度为O(t)，在进行OT转换操作时并没有改变，进行OT的时间复杂度是跟C(O)有关的，所以Improved_COT在时间复杂度是跟空间复杂度一致的，随着时间的增大，Improved_COT的性能将是非常稳定的。

相比于在P2P环境下传统的COT算法，在云环境下Improved_COT算法有以下几点优势：

1.云环境下采用的集中式架构支持大量用户动态的在线协同工作。

2.随着协同时间的增加，Improved_COT算法可以有效的减少C(O)的长度，在云环境下，利用云的优势，将大量分析计算的工作集中在服务器端，各站点用户只需要处理长度很小的C(O)进行COT操作，这对整个实时的环境性能有巨大的提升。

五、CloudFileSystem系统：

CloudFileSystem是一个web环境的应用，本系统采用SSM(SpringMVC+Spring+Mybatis)框架来搭建的一个web系统，通过eclipse IDE J2EE部署到tomcat8.0上来实现访问，同时为了体现云特性，采用Docker技术在一台物理计算机上运行3个服务端程序，模拟云环境的分布式服务。而用户可以根据系统的提示，输入正确的信息，登录进入云系统后，点击协同文件管理进入到协同工作的环境中即可进行办公，界面会显示协同在线的人，以及协同工作的区域。