在第一篇关于 （服务器模型）prototype server的文章中，我们没有机会谈安全机制（security）.想了解google wave的安全机制手段（security measures）先必须了解 客户端-服务器交互协议（client-server protocol）和 服务器-服务器交互协议（server-server protocol），又称联邦协议（federation）。这篇文章里面，我们将讨论客户端-服务器交互协议（client-server protocol）。
客户端-服务器交互协议是基于操作转化（ Operation Transformation） (简称 OT )的。 如果你熟悉数据库， 当2个用户试图更新同一数据，他们在相同时间读那一数据，然后向系统发出他们的更新。最后，我们会失去2个更新中的一个。为了防止这种不一致性（inconsistency）的发生 ，数据库使用交易（transaction）. 什么是交易（transaction）简而言之, 当某人试图用数据时, 该数据会被锁起来，如果其他人试图使用该数据的话，他们必须等待前面的人使用完毕.对于例如银行之类的系统，交易（transaction）是个不错的方案，任何数据的损失都是难以承受的.但是，如果我们要开发一个实时（real time） 多人合作编辑程序, 交易不是一个好的选择方案. 操作转化（OT)让用户并行（parallel）编辑同一个文本而且实时发送他们的更新。操作转化（OT)的基本理论就是让用户尽可能快发送数据，服务器尽可能快地接受发送数据。
操作转化的基本示意图
如上图所示, 用户们在同一时间段对同一文件（该文件包含数据abc）进行操作.：用户O1在文档的0位置加入数据X； 与此同时，用户 O2 删除了文档位置 2上的数据 “c”.服务器同时接受了两个用户的更新操作请求. 如果我们先处理第一用户 O1的请求然后处理用户 O2的, 那么结果和我们所期待的(xabc + del[2] = xac)将不同. 因为这个原因，我们需要一个顺序标签（order tag）. 顺序标签（order tag）只是一个 时间标志（time reference）用来为信息流（message stream）中每一个操作排序。服务器所做的就是根据用户的操作修改文档而且向其他用户广播（broadcast）这个更新。服务器必须知道每一个用户更新操作的时间顺序，并根据这些信息合理地更新文档。这就是操作转化（OT）的基本工作原理。在Wave的操作转化（OT）中，特殊的是用户不能尽可能快地发送数据.如果这被允许的话，每个用户必须存储对每个服务器的空间状态（space state），这就意味这密集地内存使用，而且这会把服务器的算法复杂化：因为服务器必须在不同的空间状态（space state）间，转化用户的操作。Wave的的操作转化（OT）是：用户发出操作而且要等待服务器回复。这一微小的改变使得服务器只需要存储一个空间状态（space state），这个空间状态包含了用户的操作历史。客户端所要做的就是缓冲所要用户的操作直到系统回复了上一个操作。这解决方案的小问题就是用户看到每一个其他用户操作大概会间隔一轮的时间（1 round trip time）。如果一轮的时间短的话，这不是大问题，否则更新就会需要一段时间。
在了解Wave的操作转化（Wave OT）之后, 我们可以讨论客户-服务器交互协议（ client-server protocol）。操作就是wavelets上的变化.我们可以把Wavelet的状态（ wavelet state）理解一系列影响它的操作。客户端和服务器就是与一个wavelet交互对文件的改动。 服务器的责任就是向该wavelet中的所有用户（对于大多数情况，所有用户指的就是该wave里所有的参与者，对于私人之间的消息private messages，所有用户指的是该wavelet之内的所有参与者）广播（broadcast）。 客户端在接受来自服务器的变动后，把新的变动写到客户端自己那一份的Wavelet。所有用户必须一模一样的根据接受到的操作去改动，这样才能保证用户之间状态的一致。
如我们之前所说的，Wave 操作转化（OT）要求所有操作排序。在 in Wave 操作转化中，客户端必须等待服务器的回复，然后发出新的操作。用户负责去对新的操作们排序，序列号必须是根据服务器提供的版本号码（version number）。一个参与者“打开”一个wavelet（wavelet “open”）就意味着主动地向该wavelet交互操作。去打开一个wavelet，客户端就发出一个打开请求（ Open Request） (包含Wave ID 和 Wavelet ID). 服务器回应该wavelet的序列化的状态（serialized state） 和该版本时的历史哈西 （history hash）.这一切都是为对新操作的排序和获得wavelet中的数据。
在正常交流中, 客户端发送 (一个或多个操作序列 Sequence of one or more operations) 和版本号（Version Number）.服务器回复一个新的版本号和历史哈西（History hash）. 服务器能发送其他用户的更新,这种情况时，服务器发送 Delta, 版本号和历史哈西（History hash）. 如果客户端和服务器交流失败, 在再次连接时，客户端和服务器必须同意一个共同的wavelet状态（state。客户端重新开启wavelet, 发送一列之前接受的历史哈西（ history hashes）。客户端发送: Wave ID, Wavelet ID, 一列客户端所知的历史哈西（ history hashes）。服务器回复该列历史哈西（history hashes）中最近的可以识别一个，和wavelect上最近的历史哈西（history hash）和一系列 of deltas。如果2组历史哈西（ history hashes ）一致，用户和服务器是同步的。如果历史哈西不一致，或者服务器不能识别任何一个客户端发送的历史哈西, 客户端和服务器必须同意在一个共同的wavelet状态（state），客户端必须重载（reload）该wave以获得一个新的共同状态（common state。这就是google wave中重载页面的请求的原因。
- client-server data diagram
如今的google Wave 联邦模型服务器（Federation Prototype Server）没有安全识别用户和服务器之间的功能。客户端相信他们的服务提供者（wave服务器）来正确的处理他们的数据。google员工期待有一天wave支持用户签名（user signature) 。 我们相信这完全必要，如果Wave在公司环境中使用。
以上就是第一部分，在第二部分中，我们将讨论服务器与服务器的交互协议（server-server protocol）和他们的安全机制。
置于浪尖之上！ Stay on the top of the wave!
标签: ack, 客户端-服务器 交互协议, 客户端-服务器, hash tree, OT, protocol client, schema, wave ot, wavelet
If you like what you see, please, support us:
Posts that may be of your interest:
- Understanding Wave protocol – Part II
- (English) Google Wave Federation protocol updates
- Wave Federation
- Wave Federation Prototype Server
- (English) Access Control in Wave
Understanding Wave protocol – Part I
在第一篇关于 （服务器模型）prototype server的文章中，我们没有机会谈安全机制（security）.想了解google wave的安全机制手段（security measures）先必须了解 客户端-服务器交互协议（client-server protocol）和 服务器-服务器交互协议（server-server protocol），又称联邦协议（federation）。这篇文章里面，我们将讨论客户端-服务器交互协议（client-server protocol）。
客户端-服务器交互协议是基于操作转化（ Operation Transformation） (简称 OT )的。 如果你熟悉数据库， 当2个用户试图更新同一数据，他们在相同时间读那一数据，然后向系统发出他们的更新。最后，我们会失去2个更新中的一个。为了防止这种不一致性（inconsistency）的发生 ，数据库使用交易（transaction）. 什么是交易（transaction）简而言之, 当某人试图用数据时, 该数据会被锁起来，如果其他人试图使用该数据的话，他们必须等待前面的人使用完毕.对于例如银行之类的系统，交易（transaction）是个不错的方案，任何数据的损失都是难以承受的.但是，如果我们要开发一个实时（real time） 多人合作编辑程序, 交易不是一个好的选择方案. 操作转化（OT)让用户并行（parallel）编辑同一个文本而且实时发送他们的更新。操作转化（OT)的基本理论就是让用户尽可能快发送数据，服务器尽可能快地接受发送数据。
操作转化的基本示意图
如上图所示, 用户们在同一时间段对同一文件（该文件包含数据abc）进行操作.：用户O1在文档的0位置加入数据X； 与此同时，用户 O2 删除了文档位置 2上的数据 “c”.服务器同时接受了两个用户的更新操作请求. 如果我们先处理第一用户 O1的请求然后处理用户 O2的, 那么结果和我们所期待的(xabc + del[2] = xac)将不同. 因为这个原因，我们需要一个顺序标签（order tag）. 顺序标签（order tag）只是一个 时间标志（time reference）用来为信息流（message stream）中每一个操作排序。服务器所做的就是根据用户的操作修改文档而且向其他用户广播（broadcast）这个更新。服务器必须知道每一个用户更新操作的时间顺序，并根据这些信息合理地更新文档。这就是操作转化（OT）的基本工作原理。在Wave的操作转化（OT）中，特殊的是用户不能尽可能快地发送数据.如果这被允许的话，每个用户必须存储对每个服务器的空间状态（space state），这就意味这密集地内存使用，而且这会把服务器的算法复杂化：因为服务器必须在不同的空间状态（space state）间，转化用户的操作。Wave的的操作转化（OT）是：用户发出操作而且要等待服务器回复。这一微小的改变使得服务器只需要存储一个空间状态（space state），这个空间状态包含了用户的操作历史。客户端所要做的就是缓冲所要用户的操作直到系统回复了上一个操作。这解决方案的小问题就是用户看到每一个其他用户操作大概会间隔一轮的时间（1 round trip time）。如果一轮的时间短的话，这不是大问题，否则更新就会需要一段时间。
在了解Wave的操作转化（Wave OT）之后, 我们可以讨论客户-服务器交互协议（ client-server protocol）。操作就是wavelets上的变化.我们可以把Wavelet的状态（ wavelet state）理解一系列影响它的操作。客户端和服务器就是与一个wavelet交互对文件的改动。 服务器的责任就是向该wavelet中的所有用户（对于大多数情况，所有用户指的就是该wave里所有的参与者，对于私人之间的消息private messages，所有用户指的是该wavelet之内的所有参与者）广播（broadcast）。 客户端在接受来自服务器的变动后，把新的变动写到客户端自己那一份的Wavelet。所有用户必须一模一样的根据接受到的操作去改动，这样才能保证用户之间状态的一致。
如我们之前所说的，Wave 操作转化（OT）要求所有操作排序。在 in Wave 操作转化中，客户端必须等待服务器的回复，然后发出新的操作。用户负责去对新的操作们排序，序列号必须是根据服务器提供的版本号码（version number）。一个参与者“打开”一个wavelet（wavelet “open”）就意味着主动地向该wavelet交互操作。去打开一个wavelet，客户端就发出一个打开请求（ Open Request） (包含Wave ID 和 Wavelet ID). 服务器回应该wavelet的序列化的状态（serialized state） 和该版本时的历史哈西 （history hash）.这一切都是为对新操作的排序和获得wavelet中的数据。
在正常交流中, 客户端发送 (一个或多个操作序列 Sequence of one or more operations) 和版本号（Version Number）.服务器回复一个新的版本号和历史哈西（History hash）. 服务器能发送其他用户的更新,这种情况时，服务器发送 Delta, 版本号和历史哈西（History hash）. 如果客户端和服务器交流失败, 在再次连接时，客户端和服务器必须同意一个共同的wavelet状态（state。客户端重新开启wavelet, 发送一列之前接受的历史哈西（ history hashes）。客户端发送: Wave ID, Wavelet ID, 一列客户端所知的历史哈西（ history hashes）。服务器回复该列历史哈西（history hashes）中最近的可以识别一个，和wavelect上最近的历史哈西（history hash）和一系列 of deltas。如果2组历史哈西（ history hashes ）一致，用户和服务器是同步的。如果历史哈西不一致，或者服务器不能识别任何一个客户端发送的历史哈西, 客户端和服务器必须同意在一个共同的wavelet状态（state），客户端必须重载（reload）该wave以获得一个新的共同状态（common state。这就是google wave中重载页面的请求的原因。
如今的google Wave 联邦模型服务器（Federation Prototype Server）没有安全识别用户和服务器之间的功能。客户端相信他们的服务提供者（wave服务器）来正确的处理他们的数据。google员工期待有一天wave支持用户签名（user signature) 。 我们相信这完全必要，如果Wave在公司环境中使用。
以上就是第一部分，在第二部分中，我们将讨论服务器与服务器的交互协议（server-server protocol）和他们的安全机制。
置于浪尖之上！ Stay on the top of the wave!
标签: ack, 客户端-服务器 交互协议, 客户端-服务器, hash tree, OT, protocol client, schema, wave ot, wavelet
If you like what you see, please, support us:
Posts that may be of your interest: