HCI-11.ppt

* * 群件体系结构（续） 复制式体系结构中每个参与者的计算机都运行一个应用程序拷贝，每个应用程序拷贝都与其它的拷贝进行通讯并尽量保持数据结构的一致性。每个拷贝都需要处理自己的反馈，并且根据接受的来自其他拷贝的消息更新屏幕 与集中式体系结构相比，复制式体系结构更难实现，如上面提到的保持各个拷贝间的数据结构的一致性就是存在的问题。如两个用户Jane和Sam在同一时刻分别键入一个键，Jane的机器会先处理Jane的击键再处理Sam的击键，而Sam的机器正相反，这就导致了不一致。这一问题形成的原因是竞争 * * 群件体系结构（续） 这种竞争问题是分布计算中普遍存在的问题，解决方法是回滚某个拷贝或所有拷贝的动作，等待各个拷贝重新执行被回滚的动作，但是如果结果已经显示在某个用户的屏幕上就不能再执行回滚了，某些并发控制机制如加锁机制能保证不发生这类问题 复制式体系结构与集中式体系结构相比，优点是本地反馈。但是客户端程序并不是完全被动的，它也可以处理一定的反馈。事实上，服务器通常称为保存共享数据的存储器，而客户端执行大多数的应用程序功能。另一方面，复制式体系结构中很少将所有的拷贝同等对待，或者有一个特殊的拷贝，或者有一个小的服务器处理系统中数据的输入输出。因此，两种体系结构本质上是相同的 * * 共享窗口体系结构 共享窗口体系结构与通用的群件体系结构有很多相似之处，同时也有很多特性 想象一个用户应用程序被位于不同计算机上的多个参与者共享，单用户应用程序正常地通过窗口管理器X与用户交互，如图9.11。共享窗口管理器的作用就是截获应用程序与窗口管理器X之间的调用 User Xevents Xlib calls Application X 图9.11 单用户应用程序 * * 共享窗口体系结构（续） 想象应用程序同往常一样发送一个绘制命令给窗口管理器时，该绘图命令会被发送到一个特殊的应用程序桩，应用程序桩把绘图命令从窗口管理器库(Xlib)发送到每个参与者所在计算机中的用户桩。在每个参与者计算机上都运行着一个窗口管理器拷贝，而且绘图命令被送到每个拷贝上。同样的，如果用户击键或执行其他动作引发了事件管理器事件(Xevent)，该事件会被传送到用户桩，然后是应用程序桩，最后传到应用程序。如图9.12所示 * * 共享窗口体系结构（续） 图9.12 共享窗口体系结构 Xlib calls Xevents User 1 X Application Application stub User stub1 User 2 X User stub2 User n X User stub n …… …… * * 共享窗口体系结构（续） 对于输入来说，必须有某种形式的令牌控制机制，尤其对于鼠标输入 可以在应用程序桩处决定各用户的事件流之间如何整合。例如简单的忽略所有非令牌获得者的事件或者将各用户的击键按到达的先后顺序依次排列。如果对令牌的申请和释放是通过组合键来完成的，那么应用程序桩必须监督事件流并判断是否是对令牌的命令 用户可以使用用户桩向界面添加自己的元素，如令牌申请按钮，其他参与者的指示器(如指示当前令牌获得者)等 * * 反馈传递和网络流量 反馈传递是指某个用户的动作在其他用户的屏幕上的反馈。对反馈传递的要求没有反馈那样严厉。以客户端-服务器体系结构为例来说明反馈传递 想象某用户刚刚敲了一个字符，该字符很快显示到了该用户的屏幕上，而且其他的客户端也需要知道该字符的输入，这样在一个n个参与者的群件系统中每个用户动作至少产生n-1个网络消息。如果对于每个字符，每个鼠标动作都这样处理，网络流量会变得尤其庞大。 一种解决方法是使用一个广播代替n-1条消息，但是很多网络协议仅只持点对点消息。 另一种解决方法是增加消息的粒度，对用户的快速反馈是必要的，但是对其他用户的更新频率可以稍低一些，服务器可以保持多个字符值然后发送一条消息，仅每个消息更新一个字符块 对字符块大小的选择也很重要。如果参与者之间可以相互交谈(面对面交谈或者通过音频、视频连接)，通常在交谈过程中会涉及屏幕内容，此时若因字符块太大而导致超过几秒的延迟将让人难以忍受 * * 图形工具集 现存的图形工具集对于创建单用户界面很有效，但是如果要创建群件系统的界面就很困难了 许多交互小组件会脱离应用程序的控制。如下面的生成弹出式菜单的命令 sel=do_pop_up(“new”,”open”,”save”,”exit”,0);当用户输入了一个选择之后，构建相应的弹出菜单(1代表新建，2代表打开…)，但是在等待用户输入选择的过程中应用程序无法监视网络 现在已经开发出一些工具能够对群件系统的界面开发提供有效的帮助。 * * 群件系统的健壮性和性能 在群件系统中四个主要的问题源： 1. 网络、工作站或操作系统