软件可读性和效率取舍

by Shubheksha

通过Shubheksha

网络通信设计中的一些约束和折衷：摘要 (Some Constraints and Trade-offs In The Design of Network Communications: A Summary)

This article distills the content presented in the paper “Some Constraints and Trade-offs In The Design of Network Communications” published in 1975 by E. A. Akkoyunlu et al.

本文摘录了“网络通信设计中的一些约束和折衷”一文中介绍的内容。 由EA Akkoyunlu等人于1975年出版。

The paper focuses on the inclusion of Interprocess Communication (IPC) primitives and the consequences of doing so. It explores, in particular, the time-out and the insertion property feature described in detail below with respect to distributed systems of sequential processes without system buffering and interrupts.

本文着重于包含进程间通信(IPC)原语及其后果。 它特别探讨了下面针对没有系统缓冲和中断的顺序过程的分布式系统详细描述的超时和插入属性功能。

It also touches upon the two generals problem which states that it’s impossible for two processes to agree on a decision over an unreliable network.

它还涉及了两个将军问题，即两个流程不可能就不可靠的网络达成一致的决定。

介绍： (Introduction:)

The design of an Interprocess Communication Mechanism (IPCM) can be described by stating the behavior of the system and the required services. The features to be included in the IPCM are very critical as they might be interdependent, hence the design process should begin with a detailed spec. This involves thorough understanding of the consequences of each decision.

可以通过陈述系统的行为和所需的服务来描述进程间通信机制(IPCM)的设计。 IPCM中包含的功能非常关键，因为它们可能是相互依赖的，因此设计过程应从详细的规范开始。 这涉及对每个决定的后果的透彻了解。

The major aim of the paper is to point out the interdependence of the features to be incorporated in the system.

本文的主要目的是指出要纳入系统的功能的相互依赖性。

The paper states that at times the incompatibility between features is visible from the start. Yet, sometimes two features which seem completely unrelated end up affecting each other significantly. If the trade-offs involved aren’t explored at the beginning, it might not be possible to include desirable features. Trying to accommodate conflicting features results in messy code at the cost of elegance.

该论文指出，有时从一开始就可以看到特征之间的不兼容性。 但是，有时似乎完全不相关的两个功能最终会彼此产生重大影响。 如果一开始就没有权衡所涉及的取舍，则可能无法包含所需的功能。 试图容纳冲突的功能会导致代码混乱，但代价是优雅。

中间流程： (Intermediate Processes:)

Let’s suppose a system doesn’t allow indirect communication between processes that cannot establish a connection. The users just care about the logical sender and receiver of the messages: they don’t care what path the messages take or how many processes they travel through to reach their final destination. In such a situation, intermediate processes come to our rescue. They’re not a part of the IPCM but are inserted between two processes that can’t communicate directly through a directory or broker process when the connection is set up. They’re the only ones aware of the indirect nature of communication between the processes.

假设系统不允许在无法建立连接的进程之间进行间接通信。 用户只关心消息的逻辑发送者和接收者：他们不在乎消息采用什么路径或到达最终目的地所经过的过程。 在这种情况下，中间流程将为我们提供帮助。 它们不是IPCM的一部分，而是插入到两个进程之间，当建立连接时，这两个进程不能直接通过目录或代理进程进行通信。 他们是唯一意识到流程之间通信的间接性质的人。

集中式与分布式系统： (Centralized vs. Distributed Systems:)

集中通讯设施 (Centralized Communication Facility)

1. Has a single agent which is able to maintain all state information related to the communication happening in the system
   具有单个代理，该代理能够维护与系统中发生的通信有关的所有状态信息
2. The agent can also change the state of the system in a well-defined manner
   代理还可以以明确定义的方式更改系统状态

For example, if we consider the IPCM to be the centralized agent, it’ll be responsible for matching the SEND and RECEIVE requests of two processes, transferring data between their buffers and relaying appropriate status to both.

例如，如果我们将IPCM视为集中式代理，则它将负责匹配两个进程的SEND和RECEIVE请求，在它们的缓冲区之间传输数据并将适当的状态中继到这两个进程。

分布式通讯设施 (Distributed Communication Facility)

1. No single agent has the complete state information at any time
   任何单一代理都无法随时获得完整的状态信息
2. The IPCM is made of several individual components which coordinate, exchange and work with parts of state information they possess.
   IPCM由几个独立的组件组成，这些组件可以协调，交换和使用它们拥有的部分状态信息。
3. A global change can take a considerable amount of time
   全球变化可能会花费大量时间
4. If one of the components crashes, the activity of other components still interests us
   如果其中一个组件崩溃，那么其他组件的活动仍然会让我们感兴趣

Case 1:

情况1：

In Figure 1, P1 and P2 are the two communicating processes on different machines over a network with their own IPCMs and P is the interface which enables this, with parts that lie on both machines. P handles the details of the network lines.

在图1中，P1和P2是网络上不同机器上具有自己的IPCM的两个通信过程，而P是实现此目的的接口，两个机器上都有部件。 P处理网络线路的详细信息。

If one machine or a communication link crashes, we want the surviving IPCM’s to continue their operation. At least one component should detect a failure and be able to communicate. (In the case of a communication link failure, both ends must know.)

如果一台机器或通信链路崩溃，我们希望幸存的IPCM继续运行。 至少一个组件应检测到故障并能够通信。 (在通信链接失败的情况下，两端必须知道。)

Case 2:

情况2：

Distributed communication can also happen on the same machine given that there are one or more intermediate processes taking part in the system. In that case, P, P1 and P2 will be processes on the same system with identical IPCMs. P is an intermediate processes which facilitates the communication between P1 and P2.

假设系统中有一个或多个中间过程，则分布式通信也可以在同一台机器上进行。 在这种情况下，P，P1和P2将是具有相同IPCM的同一系统上的进程。 P是促进P1和P2之间通信的中间过程。

Transactions between P1 and P2 consist of two steps: P1 to P and P to P2. Normally, the status returned to P1 would reflect the result of the P1 to P transfer, but P1 is interested in the status of the over all transaction from P1 to P2.

P1和P2之间的事务包括两个步骤：P1到P和P到P2。 通常，返回到P1的状态将反映P1到P传输的结果，但是P1对从P1到P2的整个事务的状态感兴趣。

One way to deal with this is a delayed status return. The status isn’t sent to the sender immediately after the transaction occurs but only when the sender issues a SEND STATUS primitive. In the example above, after receiving the message from P1, P further sends it to P2, doesn’t send any status to P1 and waits to receive a status from P2. When it receives the appropriate status from P2, it relays it to P1 using the SEND STATUS primitive.

解决此问题的一种方法是延迟状态返回 。 交易发生后，状态不会立即发送给发送方，而仅在发送方发出SEND STATUS原语时才发送。 在上面的示例中，P从P1接收到消息后，进一步将其发送给P2，不向P1发送任何状态，而是等待从P2接收状态。 当它从P2接收到适当的状态时，它将使用SEND STATUS原语将其中继到P1。

分布式设施的特殊情况 (Special Cases of Distributed Facility)

This section starts out by stating some facts and reasoning around them.

本节首先说明一些事实并围绕它们进行推理。

FACT 0: A perfectly reliable distributed system can be made to behave as a centralized system.

事实0：可以使一个完全可靠的分布式系统充当集中式系统。

Theoretically, this is possible if:

从理论上讲，这是可能的：

1. The state of different components of the system is known at any given time
   在任何给定时间都可以了解系统不同组件的状态
2. After every transaction, the status is relayed properly between the processes through their IPCMs using reliable communication.
   每次交易后，状态将在其进程之间使用可靠的通信通过其IPCM正确中继。

However, this isn’t possible in practice because we don’t have a perfect reliable network. Hence, the more realistic version of the above fact is:

但是，在实践中这是不可能的，因为我们没有完善的可靠网络。 因此，上述事实的更现实的版本是：

FACT I: A distributed IPCM can be made to simulate a centralized system provided that:

事实I：只要满足以下条件，就可以制作分布式IPCM以模拟集中式系统：

1. The overall system remains connected at all times, and

1.整个系统始终保持连接状态，并且

2. When a communication link fails, the component IPCM’s that are connected to it know about it, and

2.当通信链路发生故障时，与其连接的组件IPCM知道该消息，并且

3. The mean time between two consecutive failures is large compared to the mean transaction time across the network.

3.与网络上的平均事务处理时间相比，两次连续故障之间的平均时间要长。

The paper states that if the above conditions are met, we can establish communication links that are reliable enough to simulate a centralized systems because:

该论文指出，如果满足以上条件，我们可以建立足够可靠的通信链路来模拟集中式系统，因为：

1. There is always a path from the sender to the receiver
   从发送者到接收者总会有一条路径
2. Only one copy of an undelivered message will be retained by the system in case of a failure due to link failure detection. Hence a message cannot be lost if undelivered and will be removed from the system when delivered.
   如果由于链路故障检测而导致故障，系统将仅保留未送达邮件的一个副本。 因此，如果未传递，则消息不会丢失，传递时将从系统中删除。
3. A routing strategy and a bound on the failure rate ensures that a message moving around in a subset of nodes will eventually get out in finite time if the target node isn’t present in the subset.
   路由策略和故障率边界确保了如果子节点中不存在目标节点，则在子节点中移动的消息最终将在有限的时间内消失。

The cases described above are special cases because they make a lot of assumptions, use inefficient algorithms and don’t take into account network partitions leading to disconnected components.

上面描述的情况是特殊情况，因为它们做出了很多假设，使用了低效的算法，并且没有考虑导致组件断开连接的网络分区。

分布式系统中的状态 (Status in Distributed Systems)

完整状态 (Complete Status)

A complete status is one that relays the final outcome of the message, such as whether it reached its destination.

完整状态是一种中继消息的最终结果的状态，例如消息是否到达目的地。

FACT 2: In an arbitrary distributed facility, it is impossible to provide complete status.

事实2：在任意分布式设施中，不可能提供完整的状态。

Case 1:

情况1：

Assume that a system is partitioned into two disjoint networks, leaving the IPCMs disconnected. Now, if IPCM1 was awaiting a status from IPCM2, there is no way to get it and relay the result to P1.

假定系统被划分为两个不相交的网络，而使IPCM保持断开状态。 现在，如果IPCM1正在等待IPCM2的状态，则无法获取它并将结果中继到P1。

Case 2:

情况2：

Consider figure 2, if there isn’t a reliable failure detection mechanism present in the system and IPCM2 sends a status message to IPCM1, then it can never be sure it reached or not without an acknowledgement. This leads to an infinite exchange of messages.

考虑图2，如果系统中不存在可靠的故障检测机制，并且IPCM2将状态消息发送到IPCM1，则在没有确认的情况下永远无法确定它是否到达。 这导致消息的无限交换。

超时时间 (Time-outs)

Time-outs are required because the system has finite resources and can’t afford to be deadlocked forever. The paper states that:

超时是必需的，因为系统资源有限，并且永远无法陷入僵局。 该文件指出：

FACT 3: In a distributed system with timeouts, it is impossible to provide complete status (even if the system is absolutely reliable).

事实3：在具有超时的分布式系统中，不可能提供完整的状态(即使系统绝对可靠)。

In figure 3, P1 is trying to send P2 a message through a chain of IPCMs.

在图3中，P1试图通过一系列IPCM向P2发送消息。

Suppose if I1 takes data from P1 but before it hears about the status of the transaction, P1’s request times out. IPCM1 has now knowledge about the final outcome whether the data was successfully received by P2. Whatever status it returns to P1, it may prove to be incorrect. Hence, it’s impossible to provide complete status in a distributed facility with time-outs.

假设I1从P1获取数据，但是在它听到事务状态之前，P1的请求就超时了。 IPCM1现在知道有关最终结果，P2是否成功接收了数据。 无论返回P1的状态如何，都可能被证明是错误的。 因此，不可能在具有超时的分布式设施中提供完整的状态。

插入属性 (Insertion Property)

An IPCM has insertion property if we insert an intermediate process P between two processes P1 and P2 that wish to communicate such that:

如果我们在希望进行通信的两个进程P1和P2之间插入一个中间进程P，则IPCM具有插入属性：

1. P is invisible to both P1 and P2
   P对P1和P2均不可见
2. The status relayed to P1 and P2 is the same they’d get if directly connected
   中继到P1和P2的状态与直接连接时的状态相同

FACT 4: In a distributed system with timeouts, the insertion property can be possessed only if the IPCM withholds some status information that is known to it.

事实4：在具有超时的分布式系统中，仅当IPCM保留某些已知的状态信息时，才可以拥有插入属性。

Delayed status is required to fulfill the insertion property. Consider that the message is sent from P1 to P2. What happens if P receives P1’s message, it goes into await-status state but it times out before P could learn about the status?

需要延迟状态才能实现插入属性。 考虑该消息是从P1发送到P2的。 如果P接收到P1的消息，它进入await-status状态，但是在P知道该状态之前超时，会发生什么？

We can’t tell P1 the final outcome of the exchange as that’s not available yet. We also can’t let P know that it’s in await-status state because that would mean that the message was received by someone. It’s also not possible that P2 never received the data because such a situation cannot arise if P1 and P2 are directly connected & hence violates the insertion property.

我们尚无法告知P1交换的最终结果，因为该结果尚不可用。 我们也不能让P知道它处于await-status状态，因为那意味着消息已被某人接收。 P2也永远不会收到数据，因为如果P1和P2直接连接并因此违反了插入属性，则不会出现这种情况。

The solution to this is to provide an ambiguous status to P1, one that is as likely to be possible if the two processes were connected directly.

解决此问题的方法是为P1提供一个模糊的状态，如果两个进程直接连接，则可能会出现这种状态。

Thus, a deliberate suppression of what happened is introduced by providing the same status to cover a time-out which occurs while awaiting status and, say, a transmission error.

因此，通过提供相同的状态来覆盖等待状态时发生的超时，例如传输错误，来故意抑制发生的事情。

逻辑消息和物理消息 (Logical and Physical Messages)

The basic function of an IPCM is the transfer and synchronization of data between two processes. This may happen by dividing the physical messages originally sent by the sender process as a part of a single operation into smaller messages, also known as logical message for the ease of transfer.

IPCM的基本功能是两个进程之间的数据传输和同步。 通过将最初由发送方进程发送的物理消息(作为单个操作的一部分)划分为较小的消息(为便于传输也称为逻辑消息)，可以发生这种情况。

缓冲区大小注意事项 (Buffer Size Considerations)

As depicted in figure 5, if a buffer mismatch arises, we can take the following approaches to fix it:

如图5所示，如果出现缓冲区不匹配，我们可以采用以下方法对其进行修复：

1. Define a system-wide buffer size. This is extremely restrictive, especially within a network of heterogeneous systems.
   定义系统范围的缓冲区大小。 这是极其严格的限制，尤其是在异构系统的网络中。
2. Satisfy the request with the small buffer size and inform both the processes involved what happened. This approach requires that the processes are aware of the low level details of the communication.
   以较小的缓冲区大小满足请求，并告知两个涉及的过程发生了什么。 这种方法要求进程知道通信的底层细节。
3. Allow partial transfers. In this approach, only the process that issued the smaller request (50 words) is woken up. All other processes remain asleep awaiting further transfers. If the receiver’s buffer isn’t full, an EOM (End Of Message) indicator is required to wake it up.
   允许部分转移。 在这种方法中，仅唤醒发出较小请求(50个字)的进程。 所有其他进程都处于睡眠状态，等待进一步的传输。 如果接收器的缓冲区未满，则需要EOM(消息结束)指示器将其唤醒。

部分转让和知名港口 (Partial Transfers and Well-Known Ports)

In figure 6, a service process using a well-known port is accepting requests for sever user processes, P1…Pn. If P1 sends a message to the service process that isn’t complete and doesn’t fill its buffer, we need to consider the following situations:

在图6中，使用知名端口的服务进程正在接受对多个用户进程P1…Pn的请求。 如果P1向服务进程发送的消息未完成且未填充其缓冲区，则我们需要考虑以下情况：

1. The well-known port is reserved for P1. No other process can communicate with the service process using it until P1 is done.
   众所周知的端口是为P1保留的。 在完成P1之前，没有其他进程可以与使用它的服务进程进行通信。
2. When the service process times out while P1 is preparing to send the second and final part of the message, we need to handle it without informing P1 that the first part has been ignored. P1 isn’t listening for incoming messages from the service process.
   当服务进程超时，而P1准备发送消息的第二部分和最后一部分时，我们需要处理它而不通知P1第一部分已被忽略。 P1不在侦听来自服务进程的传入消息。

Since none of these problems arise without partial transfers, one solution is to ban them altogether. For example:

由于没有部分转移就不会出现这些问题，因此一种解决方案是完全禁止它们。 例如：

This is the approach taken in ARPANET where the communication to well known ports are restricted to short, complete messages which are used to setup a separate connection for subsequent communication.

这是在ARPANET中采用的方法，其中到知名端口的通信仅限于短而完整的消息，这些消息用于为以后的通信建立单独的连接。

缓冲过程 (Buffer Processes)

Whenever P1 wishes to transfer data to the service process, a new process S1 is created and receives messages from P1 until the logical message is completed, sleeping as and when required. Then it sends the complete physical message to the service process with EOM flag set. Thus no partial transfers happen between S1 and the service process, they’re all filtered out before that.

每当P1希望将数据传输到服务进程时，都会创建一个新进程S1并从P1接收消息，直到逻辑消息完成为止，并在需要时Hibernate。 然后，它将设置了EOM标志的完整的物理消息发送到服务进程。 因此，在S1和服务进程之间不会发生部分转移，在此之前它们都被过滤掉了。

However, this kind of a solution isn’t possible with well-known ports. S1 is inserted between P1 and the service process when the connection is initialized. In the case of well-known ports, no initialization takes place.

但是，众所周知的端口无法实现这种解决方案。 初始化连接后，将S1插入P1和服务进程之间。 对于众所周知的端口，不会进行初始化。

In discussing status returned to the users, we have indicated how the presence of certain other features limits the information that can be provided.

在讨论返回给用户的状态时，我们已指出某些其他功能的存在如何限制了可以提供的信息。

In fact, we have shown situations in which uncertain status had to be returned, providing almost no information as to the outcome of the transaction.

实际上，我们已经显示了必须返回不确定状态的情况，几乎没有提供有关交易结果的信息。

Even though the inclusion of insertion property complicates things, it is beneficial to use the weaker version of it.

即使包含插入属性使事情复杂化，使用较弱的版本也是有益的。

Finally, we list a set of features which may be combined in a working IPCM:

最后，我们列出了可以在有效的IPCM中组合的一组功能：

(1) Time-outs

(1)超时

(2) Weak insertion property and partial transfer

(2)插入性弱和部分转移

(3) Buffer processes to allow

(3)缓冲过程允许

(4) Well-known ports — with appropriate methods to deal with partial transfers to them.

(4)知名港口-采用适当的方法来处理对它们的部分转让。

翻译自: https://www.freecodecamp.org/news/some-constraints-trade-offs-in-the-design-of-network-communications-a-summary-19589efd55d9/

软件可读性和效率取舍