Using Jabber to send network messages

Question

We have a requirement to send desktop alerts to various users (compliance, production) across a network when other users have submitted content online for a report.

At present we are using NET SEND but this has no guarantee of delivery and has proved unreliable from both client and server perspective (and I gather will be unsupported in later versions of Windows; we are currently running XP).

We are considering a Jabber-based solution but has anyone used a Jabber client to pop up alert messages on the screen like NET SEND does, as opposed to just bringing a chat window to the front or displaying a temporary 'toast' message near the system tray.

We need the alert message to be persistent and only dismissed by the user, indicating they have seen it. Toast-style pop-ups would be fine as long as it was not only for a limited time and again had to be dismissed by the user.

Any solutions?

Answer 1

We have something similar in house. We use the Miranda IM client with the notifyanything and popup plugins.

Notifyanything allows the client to receive udp messages on a specified port. Popup does just that, displays the message in the window at the top of the users screen.

In our case, everything is on the internal network, so loss of UPD packets is not a concern.

Here is an example of the python script we run to send the udp messages from the servers to the users:

#!/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)

Answer 2

I came across this exact issue. The goal was to deliver each alert along an escalation pathway - sending the alert to the next person in the list if it was not acknowledged in a given timeframe. We determined that Jabber was the best solution, but that to do it right we had to extend the protocol or investigate more clients. (The protocol lends itself very well to extension and there are countless clients available). This catch was because it was frequently desirable to acknowledge some alerts but not others.

For example. An alert's ultimate path:

Send to admin A via Jabber.
No acknowledgement after 5 minutes, sent to admin B via Jabber.
No acknowledgement after 5 minutes, sent to admin A via SMS.
No acknowledgement after 5 minutes, sent to admin B via SMS.
No acknowledgement after 5 minutes, sent to admin A and B's manager via Jabber.
No acknowledgement after 5 minutes, sent to admin A and B's manager via SMS.
Manager evaluates the alert, acknowledge it or phones admin A or B.

The catch is that if a second alert is generated in the middle of this process, admin A or B may wish to acknowledge it, but not acknowledge the first alert. For example, if they're busy with a separate issue that generated the other alert, or if they're not near a computer, know that the second alert is not serious, but that the first alert needs to be handled by someone near a computer and the escalation mechanism is the most efficient way to find the right person.

There were two types of message delivery in Jabber. (I believe called normal vs chat) It's possible that one of the two types allowed a differentiation in which message was responded to. Unfortunately, the messaging type that might have allowed for this caused extreme inconvenience with the clients we tested if a large flood of messages were received. (Also I'm not sure whether the people testing determined whether it was possible to indeed differentiate what was being responded to, due to this issue overwhelming the testing).

As it was exploratory and we didn't really have time to implement a full solution, we didn't determine whether the problem was just choosing a better client or whether extensions to the protocol were necessary. I still think Jabber is the best method to deliver alerts. For any alert delivery/escalation system, a person who acknowledges an alert should take ownership of the alert, and there should be repercussions for everyone failing to acknowledge an alert. This has to work with the system understanding the best way to reach a person, an on-call rotation, the risk of alert floods, the issue of alerts created by a person who is currently out of the rotation, and any political considerations caused by an alerting system that accidentally creates accountability if the existing system has none.

Answer 3

I'm sorry this isn't an exact answer to your question (about Jabber), but you might want to check out ReachAlert.

http://www.tekalign.com/

This would stop people from corrupting your jabber implementation since they could decide to use it for something else (chatting, sending messages to other users).

I also agree about net send. It's going away and is common practice to disable it since it was abused for spamming.

Let me know what you think and how it goes ;-)

Answer 4

This may be a better question to ask over at Stackoverflow, but it does look like there are python and perl libraries for Jabber, so this should be possible.

http://jabberpy.sourceforge.net/

http://search.cpan.org/~reatmon/Net-Jabber-2.0/lib/Net/Jabber.pm

Answer 5

Have used PSI jabber client. It has popup notifications along with sound notifications. Same goes for JAJC jabber client.

Answer 6

I think this can achieved trought a monitoring solution like ZAbbix, you can trigger an action upon any remote events by remote scripting, once the action has been triggered Zabbix can do escalations. Actions can be running remote script, sending email or alerts via jabber until the trigger is acknoledged.