在分布式系统中，通过消息传递方式实现IPC时可能会遇到的问题

发送方会发送包含数据的消息，而且这些消息的编写方式使得接收方能能够理解它们。在分布式系统中，进程间的通信是通过消息传递来实现的。这种方式允许进程之间通过基本操作来交换消息。

一种具有3个组成部分的固定长度头部结构：  

• 地址：该地址组件包含发送进程和接收进程的唯一地址。它分为两部分：一部分是发送进程的地址，另一部分则是接收进程的地址。
• 序列号：这个序列号的工作原理类似于消息标识符（ID）。它适用于那些因为系统故障而导致丢失或重复的消息需要被找回的情况。
• 结构信息：它包含两个字段：一个是数据类型（数据本身或指向数据的指针），另一个是消息的长度，这些都属于结构化的信息。

2. 各种大小的数据对象的集合：

消息传递：这种消息传递系统提供了一组基于消息的进程间通信协议，同时避免了程序员需要处理复杂的网络协议以及多种异构平台所带来的复杂性。 send()和receive()这些通信原语被进程用来实现彼此之间的交互。 例如，如果进程A想要与进程B进行通信，那么进程A会使用send()函数发送消息，而进程B则可以使用receive()函数来接收该消息。

优秀的消息传递系统的特征：

• 简单性
• 统一语义学
• 效率
• 正确性
• 可靠性
• 灵活性
• 安全性
• 可移植性

消息传递中的问题：

• 这条消息的发送者是谁呢？
• 目标接收者是谁？
• 是只有一个接收器，还是有多个接收器呢？
• 有没有什么办法可以确保收件人真的收到了这条消息呢？是否需要等待发件人的回复呢？
• 如果在通信过程中发生灾难性事件，比如通信链路中断或节点崩溃等情况，那么有没有相应的应对策略呢？
• 如果接收方不愿意接受这条消息，那么应该如何处理它呢？是将其销毁，还是暂时保存在缓冲区中呢？如果缓冲区也满了，那么应该采取什么措施来处理这种情况呢？
• 在存在多个未处理消息的情况下，接收者是否能够对这些消息进行排序呢？

同步：

• 当进程需要相互通信时，就会调用 send() 和 receive() 这两个原语。
• 在通信结构中，通信原语的同步性是一个至关重要的问题。

同步语义：以下是进程之间传递消息的两种方式：

• 阻塞（同步模式）
• 非阻塞（异步）

1. 阻止/拦截：所谓的“阻塞语义”意味着，当调用 send() 或 receive() 这样的原语时，会阻塞调用者当前的执行流程。

2. 无阻塞：非阻塞语义意味着，当调用 send() 或 receive() 这样的原语时，不会阻塞调用者当前的执行流程，控制权会立即返回到调用者手中。

• 阻止 send() 原语的执行：“Blocking send()”这一操作指的是发送过程的阻塞状态。在执行此操作时，发送过程会一直处于阻塞状态，直到从接收方收到确认消息，表示消息已经成功接收到为止。
• 非阻塞的send()原语：非阻塞的send()函数表示，在send()语句执行完成后，当消息被成功传输到缓冲区之后，进程可以继续继续执行下去。
• 阻塞的 receive() 原语：当它们接收到相关消息时，接收过程就会暂停，直到收到新的消息为止。
• 非阻塞式接收()原语：非阻塞的receive()函数意味着，在执行完receive()语句之后，接收过程不会陷入阻塞状态。在将消息缓冲区的位置通知给内核之后，控制权会立即被返回给调用者。

在非阻塞的 receive() 函数中，当消息被放入消息缓冲区时，接收过程如何知道有消息到达呢？可以使用以下两种方法来实现这一点：

1. 民意调查在这种 polling 方法中，当接收到测试数据时，接收器可以检查缓冲区的状态。接收器会定期向内核发送查询请求，以确认消息是否已经在缓冲区中。
2. 中断在软件中断方法中，会使用软件中断来通知接收进程消息的状态，即消息是否已经被存储到缓冲区中，并且可以供接收方使用。因此，在这种方法中，接收进程可以继续运行，而无需提交失败的测试请求。

在那些被阻塞的 send() 和 receive() 原语中，存在一个问题：

• 阻止 send() 原语的执行：这里需要解决的问题是：如果接收进程发生崩溃，或者由于通信故障导致发送的消息丢失，那么发送过程可能会永久停止。因此，为了防止这种情况的发生，系统设置了固定的超时时间。当超过这个超时时间时，发送操作就会以错误状态终止。用户可以选择将超时值作为send函数的参数来指定，或者将其设置为默认值。
• 阻塞式的 receive() 原语：为了避免接收过程无限期地中断，可以设置一个固定的阻塞时间值来限制接收过程。这种情况可能发生在预期的发送程序出现故障时，或者因为通信中断而导致消息在网络上丢失时。