我們需要在其他用戶線上提交報告內容時透過網路向各個用戶（合規性、生產）發送桌面警報。
目前我們正在使用NET SEND，但這不能保證傳送，並且從客戶端和伺服器的角度來看都證明是不可靠的（我認為在更高版本的Windows 中將不支援；我們目前運行的是XP） 。
我們正在考慮基於 Jabber 的解決方案，但有人使用 Jabber 用戶端像 NET SEND 一樣在螢幕上彈出警報訊息，而不是僅僅將聊天視窗放在前面或在系統附近顯示臨時「toast」訊息托盤。
我們需要警報訊息是持久的，並且只能被用戶忽略，表明他們已經看到了它。 Toast 風格的彈出視窗就可以，只要它不僅是在有限的時間內並且必須再次被用戶關閉。
有什麼解決辦法嗎？
答案1
我們家也有類似的東西。我們使用帶有notifyanything 和popup 插件的Miranda IM 用戶端。
Notifyanything 允許客戶端在指定連接埠上接收 udp 訊息。彈出視窗就是這樣做的，在用戶螢幕頂部的視窗中顯示訊息。
在我們的例子中，一切都在內部網路上，因此 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 實現，因為他們可以決定將其用於其他用途（聊天、向其他用戶發送訊息）。
我也同意網路發送。它正在消失，並且禁用它是常見的做法，因為它被濫用於發送垃圾郵件。
讓我知道你的想法以及進展如何;-)
答案4
曾經使用過PSI jabber客戶端。它具有彈出通知和聲音通知。 JAJC jabber 客戶端也是如此。