当其他用户在线提交报告内容时，我们需要通过网络向各种用户（合规、生产）发送桌面警报。
目前我们正在使用 NET SEND，但这无法保证传输，并且从客户端和服务器的角度来看都被证明是不可靠的（并且我了解到在 Windows 的更高版本中将不受支持；我们目前正在运行 XP）。
我们正在考虑基于 Jabber 的解决方案，但是否有人使用过 Jabber 客户端在屏幕上弹出警报消息，就像 NET SEND 那样，而不是仅仅将聊天窗口放在前面或在系统托盘附近显示临时的“toast”消息。
我们需要警告消息持久存在，并且只能由用户关闭，表明他们已经看到它。Toast 式弹出窗口也可以，只要它不是只持续有限的时间并且必须由用户多次关闭即可。
有什么解决办法吗？
答案1
我们公司内部也有类似的产品。我们使用 Miranda IM 客户端以及 notifyanything 和 popup 插件。
Notifyanything 允许客户端在指定端口上接收 UDP 消息。Popup 就是这么做的，在用户屏幕顶部的窗口中显示消息。
在我们的案例中，一切都在内部网络上，因此不必担心 UPD 数据包的丢失。
下面是我们运行的将 udp 消息从服务器发送给用户的 python 脚本示例：
#!/usr/bin/python
import socket, sys
hosts = (
('10.0.0.1', 15000),
('10.0.0.2', 15000),
('10.0.0.3', 15000),
)
def send(txt):
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
for h,p in hosts:
s.sendto(txt, 0, (h,p))
del s
if len(sys.argv) > 1:
s = "\n".join(sys.argv[-2:])
send(s)
答案2
我遇到了同样的问题。目标是沿着升级路径传递每个警报 - 如果在给定的时间范围内未确认，则将警报发送给列表中的下一个人。我们认为 Jabber 是最好的解决方案，但要做到这一点，我们必须扩展协议或研究更多客户端。（该协议非常适合扩展，并且有无数可用的客户端）。这个陷阱是因为我们经常希望确认某些警报，而不是其他警报。
例如，警报的最终路径：
通过 Jabber 发送给管理员 A。 5 分钟后没有确认，通过 Jabber 发送给管理员 B。 5分钟后没有确认，通过短信发送给管理员A。 5分钟后没有确认，通过短信发送给管理员B。 5 分钟后没有确认，通过 Jabber 发送给管理员 A 和 B 的经理。 5 分钟后没有收到确认，通过短信发送给管理员 A 和 B 的经理。 经理评估警报、确认警报或致电管理员 A 或 B。
问题是，如果在此过程中生成了第二个警报，管理员 A 或 B 可能希望确认该警报，但不想确认第一个警报。例如，如果他们正忙于处理生成另一个警报的单独问题，或者他们不在计算机附近，则要知道第二个警报并不严重，但第一个警报需要由计算机附近的人来处理，升级机制是找到合适人选的最有效方法。
Jabber 中有两种消息传递类型。（我认为称为普通消息传递和聊天消息传递）。其中一种类型可能允许区分对哪条消息做出响应。不幸的是，如果收到大量消息，这种可能允许这样做的消息传递类型会给我们测试的客户端带来极大的不便。（此外，我不确定测试人员是否确定是否确实可以区分对哪些消息做出响应，因为这个问题压倒了测试）。
由于这只是一个探索性项目，我们并没有时间去实施一个完整的解决方案，因此我们无法确定问题是否只是选择了一个更好的客户端，还是需要对协议进行扩展。我仍然认为 Jabber 是传递警报的最佳方法。对于任何警报传递/升级系统，确认警报的人应该对警报负责，并且所有未能确认警报的人都应该承担后果。这必须与系统一起发挥作用，了解联系人员的最佳方式、值班轮换、警报泛滥的风险、当前不在轮换中的人员发出的警报问题，以及警报系统意外产生问责制（如果现有系统没有问责制）而引起的任何政治考虑。
答案3
很抱歉，这不是您问题（关于 Jabber）的确切答案，但您可能想查看 ReachAlert。
这将阻止人们破坏您的 jabber 实现，因为他们可能决定将其用于其他用途（聊天、向其他用户发送消息）。
我也同意关于 net send 的说法。它正在消失，禁用它是一种常见的做法，因为它被滥用来发送垃圾邮件。
请告诉我你的想法以及进展如何；-)
答案4
曾使用过 PSI jabber 客户端。它有弹出通知和声音通知。JAJC jabber 客户端也是如此。