分布式系统中的过程寻址方式

在本文中，我们将详细探讨分布式系统中与通信相关的寻址过程的概念。

在基于消息的通信系统中，另一个重要的问题就是为参与通信的各个过程指定名称或地址。以下是消息处理过程中所支持的两种地址方案：

• 显式寻址
• 隐式寻址

显式寻址：在显式寻址方案中，该过程的实现方式是通过在通信原语中指定相应的参数来确定的。在显式寻址中使用的原语如下：

• 发送消息到进程ID为process_id的进程中：send(process_id, message)一条消息被发送到该进程，该进程的process_id作为参数被指定了。
• 接收（process_id, message）收到了来自某个进程的消息，该进程的进程ID被作为参数传递给了系统。

隐式寻址方式：在隐式寻址方案中，想要与另一个进程进行通信的进程不需要在通信过程中以参数形式明确指定该进程的身份，而是可以通过service_id来标识该进程。在隐式寻址中使用的通信原语如下：

• Send_any(service_id, message): 发送消息到指定的服务ID。将会向所有提供与 service_id 类型相对应的服务的进程发送消息。在这种简单模型中，发送者直接指定了服务，而无需再指定具体的进程。这种模型在客户端-服务器通信中非常有用，因为在客户端看来，与其担心选择哪个服务器来提供服务，不如直接选择能够提供所需服务的服务器即可。
• 接收任何与 process_id 相关的消息：receive_any(process_id, message)它从任何发送进程那里接收消息，然后返回发送该消息的进程的进程ID。在这种简单机制下，接收者可以从任何进程中接收消息。这种机制适用于客户端-服务器通信场景，即所有授权的客户端都可以从服务器处获取服务。

过程寻址的方法：

machine_id@local_id该方法使用机器地址和本地标识符来识别各个进程。机器地址指的是接收方的机器地址，该地址用于发送消息时使用；而本地标识符则指的是接收进程的进程ID、端口号或进程的名称。

例如，Berkeley Unix系统使用32位IP地址，以及16位的process_id或local_id（即IP地址、端口号）。

优势： 

• 为了处理这些流程，这种方法不需要进行任何全球性的协调工作。

缺点： 

• 使用这种方法时，无法对进程进行迁移。

machine_id1@local_id@machine_id2:这种方法在已迁移的进程中增加了一个名为 machine_id 的字段。 这就是为什么这种地址分配方式被称为“基于链接的地址分配方式”。 machine_id1能够识别出创建该流程的节点或机器。而local_id则是由创建该流程的机器所生成的。 这里的 machine_id2 指的是所创建进程的最后一个已知位置。 它被用于处理进程迁移的情况。当某个进程被迁移到另一台机器上时，该进程会留下一些链接信息，这些信息包括该进程要迁移到的节点的机器ID，以及当前机器的相关信息。 该链接信息的目的是，在需要时将相关消息转发给已迁移的进程。

优势：

• 它允许进程进行迁移。

缺点：

• 由于该进程需要多次迁移，因此它成为一个难以定位的位置。另外，如果因为执行该进程的机器出现故障而导致进程无法正常运行的话，那么找到该进程就变得非常困难了。

位置透明的过程寻址：

在“位置透明过程寻址机制”中，当一个进程想要向另一个进程发送消息时，只需为该进程提供一个高级别的名称。然后，该名称会被名称服务器映射为低级别的名称。为了便于将来参考，这种映射也可以被发送进程的内核缓存起来，从而不必再次联系名称服务器。

在处理这一问题的过程中，一个重要的目标是确保位置的透明度。 实现这一目标的最常用方法，就是使用两级命名方案来标识各种进程。同时，还需要借助名称服务器，将那些高层次的、与机器无关的进程名称，转换为低层次的、与机器相关的名称。 在DEMOSIMP和Charlotte中，采用了一种与这种过程寻址方式类似的方法。 虽然这种处理方式能够支持进程迁移功能，但它存在两个主要缺点：

• 如果某个进程在其生命周期中多次迁移，那么需要找到该进程的尝试次数就会变得非常频繁。
• 如果某个进程在其生命周期中所依赖的中间节点出现了故障，那么可能无法找到该进程的位置。