CN1342280A - 用于被复制的服务器的协议 - Google Patents

Abstract

一种容错客户机－服务器系统包括主服务器、备份服务器和客户机。客户机将请求发送给主服务器,主服务器接收并处理请求,其中包括以与任何备份处理无关的方式将响应发送给客户机。所述响应包括主服务器的状态信息。主服务器还执行备份处理,备份处理包括周期性地将主服务器状态信息发送给备份服务器。客户机接收来自主服务器的响应并将主服务器状态信息发送给备份服务器。所述主服务器状态信息包括自从最近将主服务器状态信息从主服务器传至备份服务器以来主服务器业已处理的所有请求－应答对。可根据预定的时间间隔周期性地启动主服务器中的用于执行备份处理的装置。另外,可在主服务器中的用于存储主服务器状态信息的存储器被填加至预定量时启动上述用于执行备份处理的装置。

Description

用于被复制的服务器的协议

背景

本发明涉及容错服务器系统，具体地说，本发明涉及包括冗余服务器的容错服务器系统。

可以使用容错计算机或分布式体系结构来实现远程通信系统中的服务的高度可利用性。但是，使用这种冗余会对其它系统属性产生负面影响。例如，使用硬件层次的冗余会增加成本、物理体积、能耗、出错率等。这就不可能在一个系统内使用多层冗余。

例如，分布式系统可包括计算机之间的复制，以便增强其坚固性。如果每个计算机均是容错的，则成本就会加倍。此外，如果以软件的方式保持备份拷贝，则为了能从软件出错中进行恢复，就分布式系统中的多个备份而言，额外存储器的成本会随着容错硬件的成本而加倍。因此，为了保持低成本，建议避免使用多层冗余。由于这种结构选择的结果是仅使用一层冗余，故应选择成尽可能地弥补多种错误和其它故障。

硬件出错或软件出错会导致故障。硬件出错的特征在于是永久的或者是暂时的。在每一种情况下，这类错误都可由容错计算机来弥补。由于计算机硬件的快速发展，系统中集成电路和/或器件的总数会不断地下降，每种集成电路和器件均会在可靠性方面不断地改进。总之，当前硬件错误不是系统故障的主要原因，并且，在将来更不会是这样。因此，更难以证明需要用独立的冗余即容错计算机只去处理潜在的硬件错误。

就软件错误而言，上述内容也是不成立的。软件的复杂性不断增加，并且，对较短开发时间的要求会阻止在所有可能的配置、操作模式和类似的情况下对日益复杂化的软件进行测试。较好的测试方法应该是充分地调试正常情况。就仅在非常特定偶然情况下出现的错误即所谓的“海森缺陷”(“Heisenbuggs”)而言，并不存在有可能或经济地执行完全测试这样的例外。相反，这种类型的错误需要由系统内的冗余来弥补。

进程的松散连接复制几乎可以弥补所有的硬件和软件错误，包括暂时错误。作为一个实例，I.Lee和R.K.Iyer发表《IEEE软件工程学报》1995年5月的Vo1.21，No.5中的“串行保护系统中的软件可靠性”指出，尽管将设置检查点设计到系统内以弥补硬件错误，但设置检查点(即将当前状态拷贝至备用计算机)和重启动(即通过例如读出自最后一个检查点以来出现的事务的日志而从最后一个检查点状态开始执行，然后开始处理新的检查点)在某些位置能弥补软件错误的75％至96％。所述报告中的说明是，在测试期间未识别出的软件错误是错综复杂的并且是由非常特殊的条件所触发的。这些条件(例如存储器状态、时间、竞争条件等)在备份进程接管之后不会在该进程中重新出现，因此，软件错误不会重新出现。

网络中复制的问题在于，存在有诸如仲裁中心资源之类的少数服务，这些服务不适于分散。这种类型的服务必须在一个进程中加以实现并且就效率而言需要将其数据保持在堆栈内。为了获得冗余信息，必须在分布式网络内复制这种类型的进程。在高性能远程通信控制系统中，必须用非常低的开销并在不导致任何额外延迟的情况下进行这种复制。

发明概要

所以，本发明的一个目的是提供用于实现容错客户机-服务器系统的方法和设备。

依照本发明的一个方面，可在这样一种容错客户机-服务器系统中实现上述和其它目的，所述系统包括主服务器、备份服务器和客户机。客户机将请求发送给主服务器。主服务器接收并处理请求，包括以与主服务器所执行的任何备份处理无关的方式将响应发送给客户机，其中，所述响应包括主服务器的状态信息。通过以与备份处理无关的方式发送响应，可以获得较高层次的并发操作，从而使得系统更有效率。主服务器还执行备份处理，包括周期性地将主服务器状态信息发送给备份服务器。客户机接收来自主服务器的响应并将主服务器状态信息从客户机发送给备份处理器。

在本发明的另一个方面中，所述主服务器状态信息包括自从最近将主服务器状态信息从主服务器传至备份服务器以来主服务器业已处理的所有请求-应答对。

在本发明的又一个方面中，所述主服器将主服务器状态信息存储在存储装置内。可以响应存储装置被填加至预定量从而进行在主服务器中执行备份处理的操作。

在又一个实施例中，可根据预定的时间间隔来周期性地进行在主服务器中执行的备份处理操作。

附图简述

通过连同附图阅读以下详细说明会理解本发明的上述目的和优点，在附图中：

图1是说明冗余服务器在客户机-服务器应用中的用途的框图；

图2是说明容错客户机-服务器应用中的消息流的图；

图3是说明本发明一个方面的客户机、主服务器与备份服务器之间的消息流的框图；

图4a和4b说明了利用与进程通信的因果次序关系所实现的效率改进。

详细说明

以下就附图详细说明本发明的各种特征，在附图中，相类似的部分用相同的标号表示。

图1是说明冗余服务器在客户机-服务器应用中的用途的框图。具体地说，示出了多个客户机应用程序C。主服务器S101在第一处理器103上运行。独立于第一处理器103的第二处理器105以与主服务器S101相并行的方式运行备份服务器S’107。一般地说，主服务器S101和备份服务器S’107在处理了任何来自客户机应用程序C的特定请求之后出现的一个虚拟时刻T应具有相同的内部状态，因此，在其中的某一个出故障时，另一个可在没有任何一个客户机应用程序C注意到问题的情况下进行接管。(由于备份服务器S’107跟踪主服务器S101，故备份服务器S’107会比主服务器S101更晚地实时地到达上述虚拟时刻)。被复制的服务器进程的存在对使用该服务器的客户应用程序C来说应是不可见的。为了实现这种策略，需要解决下列问题：

寻址：客户应用程序C应在与主服务器S101或备份服

      务器S’107(或它们两者)是否执行该业务无

      关的情况下以一致的方式对服务器进行寻

      址。

复制与同步：    来自不同客户应用程序C的输入请求以及出错

                和修复通知，会因为处理器之间物理网络的不

                同而按不同次序到达主服务器S101和备份服

                务器S’107。然而，这些请求应该按照相同次

                序分类。

出错和修复通知：服务器进程出错和新服务器进程的开始必须能

                由仍在工作的服务器检测到。

状态传递：      当服务器进程在出错之后重新开始时，正在工

                作的服务器必须在能开始处理请求之前将其

                内部状态传给新的服务器。

在解决上述问题时，本发明的最佳实施例力图达到下列目标：

--仅解决复制问题一次。实施复制具有多种缺陷并且检验起来很复杂。存在有必须加以弥补的多种可能的错误。

--仅增加低开销并仅将这种开销施加于与被复制的进程的通信。

--在正常操作下，在出故障时和在重整合新进程时，最坏情况的响应时间均应该是事先知道的并被保持于可接受的水平。

--不应将额外的消息添加给临界的定时路径。许多通常的实施技术都违背这一目标。例如，主服务器必须将消息发送给辅助服务器并在将应答发回客户机之前取回一个应答。应该避免这点，从而使系统的实时响应时间不能因所增加的冗余而减慢。

--对多个客户和动态客户进行处理。远程通信应用就一个服务器而言一般具有多个可能的客户机。这就意味着不能使用例如在服务器进程出错或恢复时必须对客户机中的信息进行更新的算法。而且，客户机进程一般具有短的寿命(它们仅在一个呼叫期间存在)。这就意味着不能使用需要服务器始终监视客户机的算法。

为了使得协议更为简单，本发明的最佳实施例实施了几条限制。通过使得协议更为一般化可很容易地提高这些限制中的某些限制。但是，它们所包含的内容有利用说明所涉及的基本机理。这些限制是：

--仅涉及两个服务器：主服务器和备份服务器。本领域的技术人员将会看出，可使协议扩展成包括更多的内容。

--一次容许一个错误，即一个客户机或服务器出故障。所述系统必须在容许另一个错误之前进行恢复(例如通过启动一次冷待机)。

--简单的网络配置。不考虑例如将网络分解成两个网络、每个网络中有服务器对中的一个的复杂网络出错情况。

--没有大的消息。块数据传输及类似的工作可能使缓冲区或队列溢出。

--软实时响应。在正常情况下(即在没有任何出错服务器的情况下)，就使用非复制服务器的系统而言，可以确保有大致相同的响应时间。但是，在出错、恢复和重新集成时必须接受较长的响应时间。应该仍能保证这些较长的响应时间不超过预定的最大时间量。

--确定的服务器操作。正如将要更详细地说明的那样，备份服务器会接收到来自主服务器的周期性的更新消息。在备份服务器中对这些更新消息的处理必须是确定性的，以便保证能在发送更新消息时达到与主服务器相同的内部状态。服务器软件不可以包括诸如调用时钟(时钟会根据被调用的时间的不同而返回不同结果)之类的不确定的系统调用，因为，这种调用会使备份服务器达到与主服务器不同的内部状态。

因此，备份服务器的状态必须100％地由其从主服务器那里接收的信息所指定。这一点可通过以下两种方式之一来获得：

a)提供给主服务器的请求还被传给备份服务器，然后，备份服务器通过对请求作相同的处理而达到与主服务器相同的状态；或者

b)将处理的结果(即主服务器所产生的对客户机的应答以及服务器内部状态的变化)发送给备份服务器。

--仅有简单的应用程序。在对后述的本发明协议的说明中，复制服务器不可以请求来自其它服务器的服务。协议必须能扩展，以便对这种情况进行处理。在一种这类扩展中，第二服务器能检测到：请求来自复制服务器并遵循相同(或相类似)的协议。

以上提出了需要加以解决的四个问题。以下说明本发明对这些问题之一的解决方案即复制与同步。在一个最佳实施例中，将复制和同步实现为在客户机与服务器之间所使用的通信协议的一部分。这种方法的优点是：

--在设计协议时仅实施一次。

--复制相对应用程序是隐藏的。协议可对复制服务器进行寻址。

本发明的协议设计成用于能有效地实现预定的复制和同步：

1)可以有两种可选实现方式：

a)实现方式可以是所述通信方法的延伸。这就意味着对于主服务器中处理来自客户机的请求不存在有额外的系统调用。

b)作为另一种方式，所述协议可包括在协议栈中。这就意味着可以进行更有效的实施。

用现有操作系统上的软件层来实现容错的所谓“中间件”方案得益于第一种可选方案(即可选方案“a”)但并不得益于第二种方案(即可选方案“b”)。

2)可在实时临界循环之外进行服务器之间的复制，客户机获得应答的速度可以与主服务器S101响应的速度一样快。

3)使将保持冗余所需的额外信息，附加到应答中以便使开销最小。

4)周期性地对备份服务器S’107进行更新/监听，以便使开销最小并能确保出错之后的恢复时间不超过预定的最大值。可由主服务器但不能由备份服多器加以处理的请求的数量，将受到可在两次周期性更新之间到达的请求的数量的限制。

5)可在I/O处理器中支持上述复制，以便使主处理器中根本没有开销。

所说的协议能保证被处理的请求以及与处理上述请求的次序有关的信息总是被保存在两台独立计算机中的独立位置处。这种策略基于以下两种事实：

1)可以在比以通常方式进行的较晚一些时间生成主服务器状态的冗余拷贝，而同时仍然保持容错。也就是说，在通常的系统中，要在将应答发送给客户机之前将服务器状态信息从主服务器传递给备份服务器。但是，本发明认识到，这是一种保守的方法，因为，在将应答发送给客户机之前，不会有其它处理器看到这种结果。因此，可认为在对请求进行处理之前主服务器业已出现了崩溃。这种情况持续至客户机接收到应答时。对生成服务器状态的冗余拷贝以便进行容错来说，这是最后的可能时间。

2)包括有三种独立的部分：请求服务的客户应用程序C、主服务器S101以及备份服务器S’107。在任何时间都足以将关键信息保存在两个冗余拷贝内。但是，这些拷贝不需要仅用主服务器S10’和备份服务器S’107来保存(如在通常的两阶段提交协议中那样)。相反，客户机也可用于(暂时)保存信息。

就简单的服务器应用程序而言，复制是以图2所示的消息流为基础的。客户应用程序C通过在客户机处理器中运行的协议栈205来访问主服务器101。配对的协议栈215、215’还在主服务器和备份服务器处理器PR01和PR02上运行。将请求201从客户应用程序C传绐主服务器S101。主服务器S101的协议栈215将一序列号与请求联系起来，然后对该请求进行处理。作为对请求进行处理的结果，主服务器S101能生成一应答消息203并立即通过协议栈215将它发送给客户应用程序C。依照本发明的一个方面，服务器的协议栈215可执行这样的附加功能：将输入的请求201存储到一个队列中，该队列的内容通过备份路径209周期性地与备份服务器S’107的协议栈215’进行信息交流。依照本发明的又一个方面，供给客户机C的应答消息203还包括这样的信息，该信息指示在输入的请求序列(自最后一次清除以来)中的一个什么样的点处对客户机的请求201进行了处理(即序列号)。

当客户机的应用程序协议栈205接收到应答消息203时，该协议栈就做两件事：1)将应答消息203传给客户应用程序C；以及，2)将可能包含例如原始请求以及应答的消息207发送给备份服务器协议栈215’，所述备份服务器协议栈215’则将上述消息传给备份服务器S’107。在某些实施例中，备份服务器的协议栈215’可以将确认消息211发送给客户协议栈205，从而确认接收到了客户的消息。

除了备份服务器接收来自客户应用程序协议栈205的信息以外，不论主服务器协议栈205中的队列何时达到了预定值或者当经过了预定的时间量时，都通过备份路径209将主服务器协议栈215中的队列清除成与备份服务器S’107一致。除了将这种必要的冗余信息提供给备份服务器S’107以外，清除操作还起监听的作用，以便将主服务器S101仍处在激活状态的指示给备份服务器S’107。清除/监听之间的时间可设定用于在出错时进行恢复的最大时间。

备份服务器S’107在不能接收到来自主服务器S101的一个或多个监听信息时接管执行权并开始接收来自客户机C的请求。

应该被传给备份服务器以便确保能进行恢复的信息是：a)原始请求，以及b)被添加在应答消息内的序列号。利用这种信息，备份可(在崩溃之后)对处于同样次序(所述请求按该次序由主服务器来加以处理)的请求进行排序分类，然后，执行同样的处理过程。尽管就来自主服务器协议栈215的信息而言，序列号不太重要(因为一般可按进行处理的次序来传递输入请求的拷贝)，但是，可将同样的信息从客户应用程序协议栈205和主服务器协议栈215传给备份服务器S’107。

将整个的主服务器应答消息(包括序列号)传给备份对备份服务器来说可以提高检错性能。除使用用来对消息次序进行排序的序列号以外，备份服务器S’107还可以通过比较自己的应答与来自主服务器S101的应答而验证它是否与主服务器相同步。但是，应该注意，就这一目的而言，传送这种信息的替代信息(例如应答的检查和)就足够了。

就检错而言，可从源(即通过客户机C或通过来自主服务器S101的周期性更新值)或从这两者传递完全的应答信息。在一个实施例中，仅通过来自主服务器协议栈215的周期性更新值来传递完全的应答信息，以便使必须通过客户机的协议栈205经由较长路径的信息量达到最少。

还存在有以文本方式将序列信息添加给应答消息的多种替代形式。一种替代形式是仅添加处理请求的序列号。另一种替代形式是包括自最后一次周期性更新以来的整个请求序列。这些替代形式用于同样的目的，并且，每种形式均可被认为是“服务器状态信息”，因为，每种形式都限定了备份服务器S’107必须采取的操作的次序，以便获得与主服务器S101的状态相同的状态。

以下说明出错的情况以及本发明如何对它们进行处理。在应答发送之前主服务器崩溃

在这种情况下，客户机C不会接收到来自主服务器S101的确认信息(即应答消息203)。作为响应，客户机C的协议栈205将原始请求201重新传送给主服务器S101和辅助服务器S’107。否则(即在无错状态下)，客户应用程序C仅将请求发送给主服务器S101。(应该注意，客户应用程序通常不知道与容错有关的活动，因为，它仅对单个的逻辑服务器进行寻址。客户机处理器中的协议栈205管理地址翻译以及与两个服务器S101和S’107之间的通信。)如果辅助服务器S’107错过了来自主服务器S101的监听信息，则它就进行接管。否则，它就简单地丢弃从自客户机C接收的请求。在发送应答之后但在将信息清除到备份之前主服务器崩溃

可以从客户机的协议栈205所提供的更新消息中检索出这样的信息，该信息是将备份服务器S’107更新成发送最后一次应答时存在的状态所需要的。从主服务器S101到客户机C的“应答路径”中的消息包含对客户应用程序的应答以及对备份服务器S’107的更新信息。客户应用程序仅需要接收来自客户机C的应答信息而不是附加的更新信息。如图2所示，(通过备份服务器的协议栈215’)将更新信息从客户机协议栈205传给备份服务器S’107。这种更新信息是备份服务器S’107在另外的情况下借助于由主服务器S101直接传送的周期性更新值而接收到的同样信息。在已存在的消息中增加某些额外信息的成本与必须为其发送额外消息相比是较小的。在发送初始请求之后客户机崩溃

在这种情况下，在主服务器清除其队列时，备份服务器S’107接收用于更新自身的信息。主系统崩溃

主服务器S101以及在同一处理器103中执行的任何客户机都将丢失。备份服务器S’107执行来自上次被清除的队列中的其余命令，然后对正在主服务器处理器103之外执行的客户机一直进行更新到在上一次应答给出的那个点。消息丢失

在认为接收处理(或处理器)出错之前，重新传送未获得立即确认的消息一次或两次。

以下参照图3详细说明客户机的协议栈205。在步骤301，客户应用程序的执行会使得请求被发送给主服务器。在步骤302，在协议栈205中处理请求，并将请求发送给主服务器。所述协议在消息丢失时实施重新传送，并且，为做到这一点而保持消息的拷贝。在步骤303，应答业已返回自主服务器。将应答没有延迟地发送回客户应用程序过程。为复制的协议保持请求及相关应答的拷贝。因为，在该例中，假定主服务器较快地进行响应，所以，不存在从主服务器发送至客户机的独立确认信息。也就是说，自主服务器返回的应答足以起应答的作用。在包括较慢主服务器的其它实施例中，协议必须包括独立的确认信息，这种确认信息总是在传送应答前从主服务器发送给客户机。

在步骤304，应用程序过程可在不等待实行复制的情况下继续执行。在步骤305，协议栈205将请求及应答存储在一个为尚未被复制给备份服务器的请求所设计的队列内。

在步骤306，客户机将包含原始请求和应答的消息发送给备份服务器。作为响应，备份服务器将一个确认(步骤307)返回给客户机，以便确认安全地接收了客户机的消息。应该注意，在没有该确认信息的情况下，客户机没有知道业已接收到了消息的其它方法，因为，没有来自备份服务器的其它应答。

以前提及了多个其它问题，即：出错和修复通告以及状态传递。以下说明本发明对这些问题的解决方案。

就出错和修复通告而言，主、辅助服务器之间的通信还起监听的作用。如果辅助服务器未被规则地更新，则辅助服务器会等待足够长的时间去接收任何显著的客户机超时，然后进行接管。在服务器过程重新开始时，该过程就检查是否存在有激活的主服务器。

就状态传递而言，它在重启动出错了的服务器时使用。在执行服务器能像主/备份对那样工作之前，它们的状态必须被拷贝成重启动的状态。在这种状态传递与进行系统软件和硬件升级时所需的状态传递类型之间没有根本的差异。而且，由于现代处理器有很少量的硬件故障，状态传递机制应该针对系统升级被最佳化。

我们记得，本发明的一个方面是这样的要求即：即使来自不同客户机的请求以及出错和修复通告可在主和备份服务器S101和S’107中按不同的次序到达，但必须按同样的次序对它们进行排序。因此，在某些实施例中，提供用于实施消息之间的因果相关关系(也称为“因果次序关系”)的机制是有益的。这基本上涉及按符合逻辑地发送出消息的次序而不是按接收消息的严格次序来对消息进行处理。对因果次序关系更完整的说明可以连同对ISIS工具包的说明一起得到，ISIS工具包是由美国纽约Ithaca的Cornell大学开发的。IEEE计算机学会出版社1994年出版的ISBN 0-8186-5342-6的K.P.Birman和R.van Renesse所著《用ISIS工具包进行可靠的分布式计算》中有上述说明。可用低开销来实现因果次序关系，并且，因果次序关系可通过允许较高度的并发性来改进系统效率。图4a和4b说明了这种效率的提高。在图4a中，处理器Pro1将对资源的请求发送给资源处理器Pro2(步骤401)。在不支持底层系统中因果次序关系的情况下，Pro2必须将消息发送给资源Pro3，以便对其进行初始化(步骤402)。在业已应答资源准备好了之后(步骤403)，允许Pro2将一应答发送给Pro1，以便通知它：资源是可用的(步骤404)。处理器Pro1可将一消息发送给资源Pro3(步骤405)。应该注意，各处理器的行为要受到一些限制，这些限制被设计成要阻止一个处理器在接收先前发送的消息之前接收(从而处理)以后发送的消息。

参照图4b，该图说明了其中底层系统支持因果次序关系的实例。该实例始于处理器Pro1将对资源的请求发送给资源处理器Pro2(步骤406)。现在，资源处理器Pro2不需要等待来自Pro3的应答。相反，它立即将一应答发送给Pro1，以便通知：资源是可用的(步骤407)。在大约同样的时刻，Pro2将一消息发送给资源Pro3，以便对其初始化(步骤408)。由于有这种并发性，故处理器Pro1能比所述的没有因果次序关系的实例(图4a)更快地将其消息发送给资源Pro3(步骤409)。这并不会产生任何问题，因为，即使来自Pro2的消息有所延迟，因果消息次序关系也能确保Pro3会在接收到来自Pro1的消息之前处理初始化消息(另外的步骤408’)。

对于客户机调用复制服务器的受限情况而言，不一定要实现完全的因果次序关系模型，因为，在这种情况下，序列号足以使得复制服务器按适当的次序对请求进行处理。但是，在将协议扩展至更普遍的情况(例如允许复制服务器调用另一个复制服务器)时，就需要调用上述完全的模型。

业已参照具体实施例说明了本发明，但是，本专业的技术人员很容易注意到，可按除上述最佳实施例以外的具体形式来实施本发明。可在不脱离本发明精神的情况下做到这一点。上述最佳实施例仅仅是说明性的，无论如何都不应认为是限制性的。应该由后附的 而不是由前面的说明来给出了本发明的范围，本文包括了属于权利要求范围内的所有变化形式和等同形式。

Claims (10)

1、一种容错客户机-服务器系统，所述系统包括：

主服务器；

备份服务器；以及

客户机；

其中：

    所述客户机包括

        用于将请求发送给主服务器的装置；

        用于接收来自主服务器的响应的装置，其中该响应包

    括主服务器状态信息；

        用于将主服务器状态信息发送给备份服务器的装置；

    所述主服务器包括：

        用于接收并处理请求的装置；

        用于响应上述请求、以与任何备份处理无关的方式将

    响应发送给客户机的装置；其中，所述响应包括主服务器

    的状态信息；

        用于执行备份处理的装置，所述备份处理包括周期性

    地将主服务器状态信息发送给备份服务器；以及

    所述备份服务器包括：

        用于接收来自主服务器的主服务器状态信息的装置；

        用于接收来自客户机的主服务器状态信息的装置。

2、如权利要求1的容错客户机-服务器系统，其特征在于，所述主服务器状态信息包括自从最近将主服务器状态信息从主服务器传给备份服务器以来主服务器业已处理的所有请求-应答对。

3、如权利要求1的容错客户机-服务器系统，其特征在于，所述主服务器状态信息包括从一个应答中得出的检查和。

4、如权利要求1的容错客户机-服务器系统，其特征在于，根据预定的时间间隔周期性地启动所述主服务器的用于执行备份处理的装置。

5、如权利要求1的容错客户机-服务器系统，其特征在于：

所述主服务器还包括用于将主服务器状态信息存储起来的装置；以及

主服务器中的用于执行备份处理的装置响应于用于存储主服务器状态信息的装置被填加至预定量而被启动。

6、一种操作容错客户机-服务器系统的方法，所述系统包括主服务器、备份服务器以及客户机；所述方法包括下列步骤：

将来自客户机的请求发送给主服务器；

在主服务器中，接收并处理上述请求，包括以与主服务器所执行的任何备份处理无关的方式将响应发送给客户机，其中，所述响应包括主服务器的状态信息；

在主服务器中执行备份处理，包括周期性地将主服务器状态信息发送给备份服务器；

在客户机中接收来自主服务器的响应；以及

将主服务器状态信息从客户机发送给备份处理器。

7、如权利要求6的方法，其特征在于，所述主服务器状态信息包括自从最近将主服务器状态信息从主服务器传至备份服务器以来主服务器业已处理的所有请求-应答对。

8、如权利要求6的方法，其特征在于，所述主服务器状态信息包括从一个应答中得出的检查和。

9、如权利要求6的方法，其特征在于，根据预定的时间间隔周期性地执行主服务器中所述用于执行备份处理的步骤。

10、如权利要求6的方法，其特征在于：

所述主服务器还执行所述将主服务器状态信息存储在存储装置内的步骤；

响应于存储装置被填加至预定量而进行在主服务器中所述用于执行备份处理的步骤。

Images