接下来，传输程序在物理链接上将消息发送给另一处理器上的目标消息队列(图3)。通过传输接口，应用程序能在不改变自身的情况下改变底层通信机制，不过需要配置传输程序。这种方案将物理链接的具体技术问题隐藏起来，提高了应用的可移植性。
图3：传输功能
消息队列具有整个系统内唯一的名称，发送器能通过其名称来定位消息队列。所有通过MSGQ模块发送的消息都必须在第一字段编码MSGQ_Msg Header，之所以必须是因为内部指令就保存在报头中，报头由传输程序和MSGQ模块内部使用。消息发送到不同的处理器时，传输程序对消息报头部分的任何字大小和字节序(endian)差异进行处理。应用程序负责消息专用部分所需的转换。
由于不同的处理器可能采用不同的调用模块(系统中的消息队列)，因此MSGQ模块允许应用程序写入器指定通知机制的类型，这非常有用，因为用户能指定通知机制，并相应地调节MSGQ。不过，一旦将消息发送给读取器，写入器就会丢掉消息的拥有权，并且不能再修改或释放消息，因此在发送之前确保消息的正确性至关重要。当读取器接收消息后，必须释放消息或重复使用消息。
消息队列的定位
MSGQ为每个打开的消息队列保留一个消息存储库，消息队列的读取器从消息队列的存储库中获取消息。如果需要将读取器或写入器线程移至另一个处理器，就无需更改读取器或写入器代码。
定位消息队列有两种办法：同步定位和异步定位。采用同步定位法情况下(可能采取阻塞方法)，消息管理每个传输程序的查询，以查找所需消息队列的位置。采用异步定位法情况下，将消息队列定位后会发送异步定位消息给指定的消息队列。
同步法的实施更为简便，但要求用于阻塞队列的一些参数，如定位线程等。虽然异步法无需进行阻塞，但实际操作更为困难，难以使用。
我们可通过应用程序指定的通知机制来支持同步或异步操作。用户可指定通知机制，如信号量和中断记入等，这样就不用再遵循特定的调用模式。消息发送器能嵌入消息队列，消息读取器则能提取消息队列并做出回答。
数据流示例
以下我们给出来自某个应用程序的基本数据流程。根据设计，该应用可在两个DSP之间移动数据。在本例中，我们用多个集来管理不同类型的消息，其中包括应用程序、传输程序内部控制消息以及错误消息等。采用不同的集并不是必需的，但这样做有助于简化应用程序的维护。例如，管理若干个小集有时要比管理单个大集要简单。此外，如果消息大小有所不同，那么采用单个大集的话就会浪费大量存储器空间，因为这时必须支持最差情况下的空间要求。
