如何使用流程B观察流程A

时间:2018-02-27 19:14:04

标签: ipc messaging observers

如果你能让我指出正确的方向,请提前致谢。我是(非常)新手程序员和Linux用户,我很欣赏有关我想象的软件应用程序的一些建议。

背景:基本思想是应用程序是“中间件”,它在Linux上作为一个进程运行,并在远程连接的“用户”和本地安装的“应用程序”之间传递纯文本数据。来自用户的数据将是特定于应用程序的命令(例如“读取消息95”)的形式,并且通常相对较短。另一方面,应用程序返回给用户的数据可以是从单个字符到多个屏幕的任何文本。中间件的工作是管理多个同时的用户连接;识别向中间件注册的任意数量的应用程序以通知用户命令;并在连接的用户和注册的应用程序之间路由纯文本数据。

应用程序可以是任何使用纯文本通信的东西:实时聊天程序,电子邮件服务器,冒险游戏,股票市场模拟器,回合制棋盘游戏,公告板等。每个应用程序将是一个独立运行的进程,管理自己的持久状态。因此,例如,应用程序流可能如下所示:

  1. 管理员运行中间件程序,并告诉它在特定端口(例如4000)上侦听用户连接。此时,没有注册的应用程序,也没有连接的用户。 (如果此时用户要连接,将通知用户没有可用的应用程序。)
  2. 管理员将特定应用程序(例如“聊天”)作为单独的进程运行,指示应用程序向中间件注册为可用应用程序。
  3. 用户通过端口4000远程连接到中间件,输入登录凭据,并从已注册的应用列表中选择“聊天”。
  4. 中间件内部将用户与“聊天”连接。
  5. 用户类型“你好”;中间件将“你好”传递给“聊天”; “聊天”处理用户的输入,并通过中间件向发送用户和/或任意数量的其他连接用户发送适当的回复(例如“用户:你好”)。
  6. 我的问题:在这种情况下,在中间件和应用程序之间传递数据的最佳技术/方法是什么?将App作为观察者注册到中间件的适当方式是什么,以便适当地通知用户命令?

    再次感谢,抱歉这个长度!

1 个答案:

答案 0 :(得分:1)

对我而言,它就像一个发布者/订阅者架构(如果可能的话,在其上构建一个管理应用程序)。你称之为“聊天列表”就像聊天室,换句话说,就是频道。这些渠道可以由管理员创建,您的应用程序可以向其发送(发布)消息。然后,每条消息将传递给频道的每个其他订阅者(因此您的应用程序也可以订阅现有频道)。

这种通信方法用于不同类型应用的音调以用于不同目的。从简单的聊天应用程序到分布式微系统。

您可以选择许多发布者/订阅者服务/应用程序。大多数这些服务提供TEXT和BINARY消息传递。其中一些具有REQUEST / REPLY等功能(您可以回复发布到频道中的消息),但您可以在自己的应用层自己轻松实现它(回复系统)。

告诉选择哪个MQ(消息队列)或PUB / SUB系统只是基于意见而没有用。但为了帮助您入门,请查看NATSMQTTRabbitMQ

我一直在自己的应用程序中使用nats来为我们的系统在微系统和另一个聊天应用程序之间传递数据。