FIFO完美点对点链路与序列号实现-CSDN博客

1、完美点对点链路抽象允许来自一个发送者的消息以与发送顺序不同的顺序到达接收者。然而，一些应用依赖于先进先出（FIFO）顺序通信。请指定一种 FIFO 顺序的完美点对点链路抽象，该抽象除了具备完美点对点链路的保证外，还能确保消息不会被重新排序。

## FIFO 顺序的完美点对点链路规范

- **模块名称**：`FIFOPerfectPointToPointLinks`
- **实例**：`fpl`

### 事件

- **请求**：⟨fpl, Send | q, m ⟩  
  表示请求将消息 `m` 发送到进程 `q`。

- **指示**：⟨fpl, Deliver | p, m ⟩  
  表示传递由进程 `p` 发送的消息 `m`。

### 属性

- **FPL1 - FPL3**：与完美点对点链路的属性 `PL1 - PL3` 相同。
- **FPL4（FIFO 传递）**：如果某个进程在发送消息 `m2` 之前发送了消息 `m1`，那么任何正确的进程在未传递 `m1` 之前不会传递 `m2`。

2、如何使用序列号在完美点对点链路的基础上实现先进先出顺序的完美点对点链路？

算法2.11 “序列号”实现了在完美点对点链路上的先进先出顺序的完美点对点链路。代码如下：

**Algorithm 2.11**:  
**Sequence Number**  
Implements: FIFO Perfect PointToPoint Links, instance `fpl`.  
Uses: Perfect PointToPoint Links, instance `pl`.

upon event ⟨fpl, Init ⟩ do  
  forall `p ∈ Π` do  
    `lsn[p] := 0`;  
    `next[p] := 1`;

upon event ⟨fpl, Send | q, m ⟩ do  
  `lsn[q] := lsn[q] + 1`;  
  trigger ⟨pl, Send | q, (m, lsn[q]) ⟩;

upon event ⟨pl, Deliver | p, (m, sn) ⟩ do  
  `pending := pending ∪ {(p, m, sn)}`;  
  while exists `(q, n, sn′) ∈ pending` such that `sn′ = next[q]` do  
    `next[q] := next[q] + 1`;  
    `pending := pending \ {(q, n, sn′)}`;  
    trigger ⟨fpl, Deliver | q, n ⟩;

3、以下陈述是否满足同步计算假设？在我的服务器上，任何请求的处理时间都不会超过1周。

满足。同步计算假设要求存在一个已知的处理延迟上限，即任何进程执行一个步骤所花费的时间总是小于这个上限。该陈述表明服务器上请求处理时间不会超过1周，这意味着存在一个明确的处理延迟上限，因此满足同步计算假设。

4、在一个进程可能出现遗漏故障且无法限制此类故障数量的模型中，我们能否实现完美故障检测器抽象？如果故障数量有界但未知呢？如果可能出现遗漏故障的进程在出现有限且已知数量的此类故障后崩溃呢？

如果遗漏故障的数量未知，不可能实现完美故障检测器抽象。因为要保证故障检测器的 强完整性 属性，进程 p 必须在某个超时延迟后检测到另一个进程 q 的崩溃，但无论如何选择这个延迟，它都可能超过 q 出现遗漏的传输延迟次数，从而违反故障检测器的 强准确性 属性。

如果在同步系统中可能出现的遗漏数量已知，我们可以用它来校准进程的超时延迟，以准确检测故障。如果延迟超过了进程在未实际崩溃的情况下可能出现遗漏故障的最长时间，就可以安全地将该进程检测为已崩溃。

5、在故障停止模型中，以下哪些属性是安全属性？1. 每个崩溃的进程最终都会被检测到；2. 没有进程在崩溃前被检测到；3. 没有两个进程做出不同的决定；4. 没有两个正确的进程做出不同的决定；5. 每个正确的进程在t个时间单位之前做出决定；6. 如果某个正确的进程做出决定，那么每个正确的进程都会做出决定。

2、3、4

6、假设算法A使用一个假定为最终完美的故障检测器D来实现分布式编程抽象M。如果D不是最终完美的，例如，当D永久输出空集时，A是否会违反M的安全属性？

答案是否定的。直观地说，原因是最终完美故障检测器抽象可能在某个任意但未知的时间 $ t $ 之前出错。如果算法 $ A $ 在 $ t $ 之前违反了某个安全属性，那么这种违反无法在后续得到纠正。

7、考虑在‘惰性可靠广播’算法中，一个进程p进行可靠广播（rb - broadcast）消息m的情况。该算法是否允许进程p在进行尽力广播（beb - broadcast）消息m之前就可靠投递（rb - deliver）该消息？如果不允许，请修改算法使其成为可能。

在‘惰性可靠广播’算法中，发送者进程先进行 尽力广播消息 ，随后在可靠投递消息之前进行 尽力投递消息 。可进行如下简单修改：让进程在进行可靠广播消息时立即进行可靠投递，并确保将可靠投递的消息添加到已投递集合中。

必要的修改如下：

upon event ⟨rb, Broadcast | m ⟩ do
    delivered := delivered ∪ {m};
    trigger ⟨rb, Deliver | self, m ⟩;
    trigger ⟨beb, Broadcast | [DATA, self, m] ⟩;