至少一次语义(at least once semantice)：客户等等直到服务器重启并再次执行操作：客户继续重试，直到获得一个应答为止。可保证RPC至少执行一次。
至多一次语义(at most once semantics)：立即放弃报告失败。保证RPC至多执行一次，但可能没有执行。
仅有一次语义(exactly once semantics)：这个方案不可行，思考一下，如果服务器在执行request和记录执行request时崩溃会发生什么？在记录request和执行request这个过程时，你可以使用at-most-once,如果在这个过程中服务器崩溃，然后你将记录这个错误并执行返回，然后你不会再一次尝试，这就是at-most-once，而at-least-once是崩溃后，如果request是重复应答，那么你就会继续携带request再次请求，但exactly-once是无法被论证的。- 从服务器到客户的应答丢失(lost reply),同一有效性(idempotent)：服务器上有些操作可以安全地重复执行多次，而对数据不影响，如果某一请求的操作具有这一属性，则称为同一有效性(idempotent)。多数请求都不具有同一有效性。丢失应答非常难以处理，简明的解决方法是依赖于超时重传机制，发出的请求在一个合理的时间内没有应答，就再发送一个请求。这种方法的问题是，客户内核无法确定为什么没有应答，是否请求或应答丢失？或许只是服务器速度慢？
同一有效性(idempotent)：服务器上有些操作可以安全地重复执行多次，而对数据不影响，如果某一请求的操作具有这一属性，则称为同一有效性(idempotent)。多数请求都不具有同一有效性。
解决方案: 客户内核给每个请求一个序列号，服务器内核则保留每个请求最近接收到的序列号。这样，服务器就可以通过这个序列号来区别一个请求是重发的还是原来的，对重传的请求拒绝响应。另外，也可以在消息中增加一个位来提示该请求消息是原来的还是重发的，对于原请求可以安全地进行处理，对于重发的请求，则处理要十分小心（服务器保留一个副本，是一种有效的办法）。

5.2 服务器接收了请求后崩溃(server crash)

重传机制的语义:

至少一次语义(at least once semantice)：客户等等直到服务器重启并再次执行操作：客户继续重试，直到获得一个应答为止。可保证RPC至少执行一次。
至多一次语义(at most once semantics)：立即放弃报告失败。保证RPC至多执行一次，但可能没有执行。
仅有一次语义(exactly once semantics)：在系统发生异常时，Writer 可以尝试多次重新发送 Event，同时能保证最终每个 Event 只被写入一次

最后,我们介绍客户在发送给服务器请求后而在应答收到之前崩溃的情况.

5.3 client发送请求后崩溃(client crash)

客户在发送给服务器请求后而在应答收到之前崩溃,这里先引起孤报的概念:

孤报(orphan):a computation is active and no parent is waiting for result.Such unwanted computation is call Orphan

存在的问题

浪费CPU时间，Orphan可能锁住某些文件或占用有价值的资源，当客户机重启时,来自Orphan的应答造成应答混乱.

孤报(orphan)的解决方法:1981年Nelson提出了四种的解决方法：

消灭(extermination)，思想：客户代理在发送RPC消息后,代理进行事务登录(log),记录发送的请求,重启时,检查事务登录,Orphan被撤消。缺点：磁盘空间浪费;orphan可能引起新的RPC导致更多的orphan,客户重启后,无法找到它们；网络分区:网络被分成两个独立的部分,客户所在的另一个部分中的orphan仍能活动(不是一中可靠的方法)
“再生”(reincarnation)，思想：将时间按顺序分成时间段，每一段的一个序号，当客户重启时，广播一个消息告诉所有的主机一上新的时间段的开始。机器收到这样的广播消息后，所有的过程计算被撤消。对于已发出的应答，由于消息中含有时间段序号而客户可以很容易地区别它们。缺点：那些有效的计算也被删除
gettlereincarnation(合理再生)，思想：当机器收到新的时间段的广播广消息后，每台机器检查是否有远程计算，如果有则试着找出它们的客户，若能找到客户(主人)，则继续它的计算，否则将远程计算撤消。缺点：系统开销大。
期满(expiration)，思想：每个RPC都给对方一个标准的时间量T，来作为它的工作期限，如果它在T时间内不能完成工作，客户必须重新请求，以保证每个RPC就可以在T时间内完成。当有客户崩溃后，在客户机重起之前等待一个时间量T,这样可保证所有的Orphan已发送。缺点：时间量T的取值比较复杂。

RPC实现

RPC协议选择(protocol selection)是选择面向连接的还是非连接的协议?

面向连接的协议的优点：通信实现容易：内核发送消息后，它不必关心它是否会丢失，也无须处理确认，而这些方面都由支持连接的软件来实现。缺点：性能较差（需要额外的软件）。在单一建筑物和校园内使用的分布式系统可以采用面向连接的协议。

是标准通用的还是RPC专用的协议?

要使用自定义的RPC协议就得完全自己设计一些分布式系统使用IP(or UDP)作为基本协议，原因是：IP/UFP协议已经设计，可节约相当可观的工作消息包可在几乎所有的Unix系统中传送和接收IP/UDP消息支持许多现存的网络总之，IP/UDP很容易使用，并且适合现存的Unix系统和网络关于性能，IP是无连接的协议，在它之上可建立起可靠的TCP协议（面向连接的），IP协议支持网关的报文分组，使报文从一介网络进入另一个网络（物理网络）。预言，一个高性能的RPC协议可望面世。

确认机制(Acknowledgement)
stop-and-wait protocol：思想：逐包确认。特点:一个包丢失了，可独立重传；容易实现。
blast protocol：思想:一个消息的所有包都发送完成后等待一个确认，而不是一个一个确认。特点:报文丢失时，有两种选择:

全部放弃：等待重传整个消息的所有包，容易实现；
选择重传：请求丢失包重传，占用网络的带宽少，对局域网这种方法较少使用，广域网络上普遍采用）。

流量控制(flow control)

通常网络接口芯片可以接收连续不断到来的包，但是由于芯片中缓冲区的限制，总是对连续到来的包的个数有个数量限制"超载"(overrun):一个消息到来而接收它的机器无法接收，以至于到来的消息丢失。超载是一个很严重的问题，它比因噪声等其他破坏引来的包丢失普遍得多。

以上两种确认机制对超载问题有所不同:

stop-and-wait protocol：超载的可能性小，因为第二个包在没有收到明确的确认之前不能被收送。（在拥有多个发送用户的情况下可能存在）

blastprotocol：接收方超载是很可能的：由于网络接口芯片引起的超载（因接收方处理一个进程而来不及处理到来的消息包）

解决方法：

忙等待：CPU空操作，应用短延时的网络环境；

中断：发送进程挂起，CPU重新调度，应用在长延时网络环境；

由于网络接口芯片缓冲区容量引起的超载，解决方法：

设有n个缓冲容量，发送进程每连接发送n个消息包时，便等待一个确认（由协议完成）确认丢失问题(lost ACK) ,图中"ACK"包丢失，造成的问题。

解决：对确认(ACK)进行确认（ACK），“超时确认”。

临界路径(critical path)

分布式系统是否成功依赖于它的性能的好坏，而系统性能的好坏又依赖于它的通信速度，通信速度与系统的具体实现有关，下面我们进一步讨论从客户到服务器执行一个RPC的过程。
临界路径(critical path)：每个RPC的指令执行的顺序是从客户调用客户代理，自陷进入内核，消息传送，服务器中断，服务器代理，最后到达进行请求处理并返回应答的服务器。RPC的这一系列步骤称为（从客户到服务器的）临界路径。

临界路径(critical path)图示

客户调用stub procedure:

申请一个缓冲区用来整理外出的消息，有些系统有一定数量的缓冲区，也有一些是一个缓冲区池，从中选择一个合适的供服务器使用。

参数整理

参数整理成适合的格式，并与消息一起插入消息缓冲区中。以备传送，自陷进入内核。

切换进入内核

内核获得控制，保存CPU寄存器及内存映像，建立新的内存映像。

拷贝消息到内核

因为用户和内核是不连接的，内核必须明确地把拷贝到内核缓冲区。

填入目标地址

将其拷贝到网络接口，到此客户临界结束。

原则上，启动计时器不属于计算RPC时间的部分，启动计时机后，系统有两种方式：忙等待和重新调度。
在服务器端，当字节到达后，被存入板上缓冲区或主存，当消息包的所有字节都到达后，服务器将形成一个中断。
检查消息包的有效性，并决定将其送给一个代理，若没有等待的代理则放弃或保存至缓冲区。
假定有一个等待的代理，那么，消息被拷贝到代理并切换到服务器代理，恢复寄存器及主存映像，代理调用receive原语，分解参数，建立服务器的调用环境，进行请求处理。

临界路径(critical path)的开销：拷贝;在考虑临界路径的时间开销问题时，其中最重大的部分是拷贝

copy1:客户代理－＞内核
copy2:内核－＞网络接口板
copy3:网络接口板－＞目标机器
copy4:网络接口板－＞内核
copy5:内核－＞服务器代理

定时管理(timer)

所有的协议都是以通过通信介质交换消息为目的的，而事实上，所有的系统中，消息都有可能丢失，或许是因为噪声或是超载。所以，多数协议都设置定时器，当消息发送出去后，期待应答（确认）的到来，若没有消息到来而定时器期满(expiration),则重发。这个过程可以重复直到发送方放弃。

设置定时器：

建立一个数据结构来指定定时器何时期满，以及期满时如何处理。

多个进程的定时器组织成列表方式如下图所示:

当一个确认或应答在超时之前到来，列表中查出对应进程所在的项，将它删除，实际上，只有少数的进程可能超时，但每一个进程都要进入超时表后再删除，这些大量的工作多数是多余的。另外，定时器也不需要精确的时间，但定时太短引起过多的超时，定时太长则对包丢失的情况又过多的等待。

实现方法

在PCB中增加一个字段，称为定时器，当发出一个RPC时，将允许延迟的时间加上当前的时钟的值并存于PCB中定时器字段，如果不需要超时重传的，其值规定为0，这样，内核定期扫描PCB链表，如果定时器值非0且小于当前时间，则该进程超时

RPC与消息传递通信的比较

RPC结构性好，使用方便;消息传递通信更灵活，但结构性差RPC只有一个返回，而消息传递通信可以向多个客户返回。RPC返回的结果或参数的值最好是少量的，消息传递通信可适合于大批量数据的传递