如何处理具有多个输入和输出的单个文本 io 流？

Question

所以我正在解决一个问题，一些建议会很好。先说一点背景，请见谅。

我正在开发一个通过TL1 protocol 查询网络设备的管理系统。对于那些不熟悉该协议的人来说，简短的回答是这是一种“人类可读”的语言，它通过基于文本的 IO 流进行通信。

我正在使用Spring和Jsch打开一个到远程NE（网元）的端口，登录，运行命令，然后关闭连接。有两种方法可以进入远程 NE，或者直接（通过 ssh 网关）如果元素具有 tcp/ip 地址（许多只是 osi），或者通过 ems（管理系统）使用所谓的“北向接口”。

无论哪种方式，程序都是相同的。

• 使用 Jsch 打开一个到 NE 或 ems 的端口。
• 发送NE ex的登录命令。 "act-user<tid>:<username>:UniqueId::<password>;"
• 发送命令前。 "rtrv-alm-all:<tid>:ALL:uniqueid::,,,,;"

• 检索和处理结果。例如上面的结果可能看起来像这样......

  RTRV-ALM-ALL:foo:ALL:uniqueid;

  CMPSW205 02-01-11 18:33:05

  M uniqueid COMPLD

  "01-01-06:MJ,BOARDOUT-ALM,SA,01-10,12-53-58,,:\"OPA_C__LRX:BOARD EXTRACTED\","

  ;

; 很重要，因为它表示响应结束。

• 最后注销并关闭端口。

在 Spring 中，我一直在非常有效地使用 ThreadPoolTaskExecutor 来做到这一点。

直到出现这个问题...

对于一个特定的 ems 平台（日立），我的方法遇到了障碍。这个 ems 通过它处理多达 80 个节点。您连接到端口，然后发出命令登录到 ems，然后运行指向各个 NE 的命令。和之前的过程一样，但是问题出在这……

登录 ems 后，下一个命令，无论是什么，最多需要 10 分钟才能完成。在此之前，所有其他命令都被阻止。在此初始等待之后，所有其他命令都会快速运行。似乎没有办法阻止这种行为（我怀疑在此期间发生了一些 NE 自动发现）。

现在我的问题的重点......

所以我对这个平台的下一个方法是连接到 ems，登录到它，并保持连接打开，然后将命令传递给各种 NE。这意味着应用程序（基于 Web）首次加载后会有 10 分钟的延迟，但在此之后就可以了。

我遇到的问题是如何最好地做到这一点。有一个基于文本的 iostream 来传递这些东西看起来像是一个很大的瓶颈，加上多个用户将使用该应用程序，我如何处理针对这个单个 iostream 的多个命令和响应？我可以在这个 ems 上打开一些 iostreams（可能最多 6 个），但这也使得整理去哪里变得复杂。

任何有关方向的建议都将不胜感激。

Answer 1

考虑每个 em 使用一个进程，以便与每个 em 的通信是分开的。这至少可以确保与其他 em 的通信不受此问题的影响。

您将不得不构建某种命令队列系统，以便发送到 Hitachi em 的命令在完成之前不会阻塞用户界面。要么这样，要么您必须在客户端软件开始使用之前将其延迟 10 分钟，或者将处理 Hitachi 的界面部分延迟 10 分钟。

也许建立连接并立即发送某种 ping 或站保持空闲命令是一个好策略 - 一些良性的东西，你不关心响应，或者没有响应，但会触发 10一分钟的延迟来完成它。您的用户可以熟悉这 10 分钟的延迟，并至少在喝咖啡或其他东西之前启动应用程序。

如果您可以在应用程序设计中以某种方式将 Hitachi 与其他 em 隔离开来，这将真正确保 10 分钟的延迟仅在与 Hitachi 接口时存在。您可以连接并发出虚拟命令，并将 Hitachi 置于某种“连接”状态，在结果出现之前无法使用命令，然后您将状态更改为就绪，以便用户可以与之交互。

---

另一种方法是开发某种中间件组件 - 我不知道您是否已经这样做了。如果客户端都是基于网络的，您可以在网络服务器上运行一个通信部分，该部分从客户端获取连接并通过网络服务器上的一个管道将它们与所有 em 通信。当这部分在网络服务器上启动时，它可以连接到每个 em 并发送一些初始 ping 命令，该命令启动 10 分钟计时器。一旦完成，网络服务器上的部件可以每隔一段时间发送一次keepalive消息，同样是某种虚拟命令，以保持套接字处于活动状态，这样它就不必重新设置并再次经历 10 分钟的等待时间。当用户打开网站时，他们可以与这个中间件服务器进行通信，该服务器会将请求转发到适当的 em 并将响应转发回客户端——所有这些都是通过已经打开的连接进行的。