在系统V消息队列中，
我们使用msgget()系统调用
int msqid = msgget(key, 0666 | IPC_CREAT);
如果msqid是唯一的队列标识符，那么关键是什么？它不是一个唯一的队列标识符吗？
所有该手册页都是这个
msgget（）系统调用返回与key参数值相关联的System V消息队列标识符
没有解释该键究竟是什么。它是某种哈希表的关键，其值是一堆IPC工具吗？我已经阅读了this帖子，但它仍然很混乱。
人们通常也会使用ftok()来生成密钥。
key_t ftok(const char *pathname, int proj_id);
ftok（）函数使用由给定路径名命名的文件的标识（必须引用现有的可访问文件）和proj_id的最低8位（必须非零）才能生成key_t类型系统V IPC密钥
为什么有人想要通过散列文件的inode来生成唯一编号？就个人而言，我认为所有同意公共号码的流程都比同意公共文件的所有流程更容易实现。它仅仅用于this回答状态的统一分发目的吗？
答案 0 :(得分：0)
由于碰撞，既不同意固定号码也不同意固定文件。密钥的命名空间很小，系统全局。在实践中，您必须随机生成密钥（如果密钥已存在，则使用新的随机值重试）并通过另一个通道传递密钥（例如将其存储在文件中或在命令行或某种消息中传递）。
答案 1 :(得分：0)
msqid 是唯一的队列标识符，在您的程序中用作参考以标识该队列。您需要该标识符，因为稍后您可能希望使用 msgsend 将消息实际发送到该队列。这需要队列标识符作为参数。
key 是该特定队列的系统范围引用。一个类比是将其视为 TCP 或 UDP 端口号（这也是“系统范围的”-至少对于特定 IP-）。
ftok 只是一种在整个分布式应用程序中使用公共文件的便捷方式，proj-id 是与该应用程序关联的队列。通过使用 ftok，您可以减轻（但不能完全避免）冲突的可能性，并且可以简化跨应用程序的键值选择。想象一个使用 10 个消息队列的应用程序，您只需为整个应用程序指定一个文件并使用从 1 到 10 的 proj_id 数字。其他应用程序可以指定不同的文件并使用相同的 proj_id 1 到 10数字“无冲突”（阅读下一段以澄清解决方案可能会出现冲突）。
正如几条评论中提到的，该解决方案容易发生冲突 - 但对于某些应用程序，这可能不是问题，特别是在旨在在受控环境中运行的自定义应用程序中，您的应用程序是唯一的（ s) 使用消息队列和键可以在系统范围内分配。
可以将其比作在同一接口中部署两个侦听 UDP 端口 10000 的应用程序。它们不能，并且需要在系统范围的基础上分配端口。
消息队列在 1984 年左右由 AT&T 合并到 UNIX System V Release 2。这是一个基本的解决方案，但就其时间而言，它可能有一些优点。
与其他 System V IPC 机制一样，它们是旧的解决方案，只要您发现它们对您的应用程序有用，并且了解警告和限制并且不代表任何问题，它们仍然可以应用。