☰

Использование Jabber для отправки сетевых сообщений

tag-icon • tag-icon windows networking windows-xp alerts xmpp
Использование Jabber для отправки сетевых сообщений

У нас есть требование отправлять оповещения на рабочий стол различным пользователям (соответствие требованиям, производство) по всей сети, когда другие пользователи отправляют контент для отчета онлайн.

В настоящее время мы используем NET SEND, но он не гарантирует доставку и оказался ненадежным как с точки зрения клиента, так и сервера (и, как я понимаю, не будет поддерживаться в более поздних версиях Windows; в настоящее время мы работаем с XP).

Мы рассматриваем решение на основе Jabber, но использовал ли кто-нибудь клиент Jabber для вывода всплывающих предупреждающих сообщений на экран, как это делает NET SEND, а не просто вывода окна чата на передний план или отображения временного всплывающего сообщения рядом с системным треем?

Нам нужно, чтобы предупреждающее сообщение было постоянным и отклонялось только пользователем, указывая, что он его видел. Всплывающие окна в стиле тоста были бы хороши, если бы они не были только на ограниченное время и снова должны были быть отклонены пользователем.

Есть ли какие-нибудь решения?

решение1

У нас есть что-то похожее в доме. Мы используем клиент Miranda IM с плагинами notifyanything и popup.

Notifyanything позволяет клиенту получать udp-сообщения на указанном порту. Popup делает именно это, отображает сообщение в окне в верхней части экрана пользователя.

В нашем случае все находится во внутренней сети, поэтому потеря пакетов UPD не является проблемой.

Вот пример скрипта Python, который мы запускаем для отправки UDP-сообщений с серверов пользователям:

#!/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.
Никакого подтверждения в течение 5 минут, отправлено администратору B через Jabber.
Подтверждения не получено в течение 5 минут, отправлено администратору А по SMS.
Подтверждения не получено в течение 5 минут, отправлено администратору B по SMS.
Никакого подтверждения в течение 5 минут, отправлено администратору А и менеджеру Б через Jabber.
Никакого подтверждения в течение 5 минут, отправлено администратору А и менеджеру Б по SMS.
Менеджер оценивает оповещение, подтверждает его получение или звонит администратору А или Б.

Подвох в том, что если второе оповещение генерируется в середине этого процесса, администраторы A или B могут захотеть подтвердить его, но не подтверждать первое оповещение. Например, если они заняты другой проблемой, которая сгенерировала другое оповещение, или если они не находятся рядом с компьютером, знайте, что второе оповещение не является серьезным, но что первое оповещение должно быть обработано кем-то, кто находится рядом с компьютером, и механизм эскалации является наиболее эффективным способом найти нужного человека.

В Jabber было два типа доставки сообщений. (Я думаю, это называется обычный и чат). Возможно, один из двух типов позволял различать, на какое сообщение отвечали. К сожалению, тип сообщений, который мог бы это делать, вызывал крайние неудобства у клиентов, которых мы тестировали, если получался большой поток сообщений. (Также я не уверен, определили ли люди, проводившие тестирование, можно ли было действительно различать, на что отвечали, из-за этой проблемы, переполнявшей тестирование).

Поскольку это было исследование, и у нас не было времени на реализацию полного решения, мы не определили, была ли проблема просто в выборе лучшего клиента или в необходимости расширения протокола. Я по-прежнему считаю, что Jabber — лучший способ доставки оповещений. Для любой системы доставки/эскалации оповещений лицо, подтвердившее оповещение, должно взять на себя ответственность за оповещение, и должны быть последствия для всех, кто не подтвердил оповещение. Это должно работать с системой, понимающей наилучший способ связаться с человеком, дежурную ротацию, риск потока оповещений, проблему оповещений, созданных лицом, которое в настоящее время не участвует в ротации, и любые политические соображения, вызванные системой оповещения, которая случайно создает ответственность, если существующая система ее не имеет.

решение3

Извините, это не точный ответ на ваш вопрос (о Jabber), но вам, возможно, будет интересно ознакомиться с ReachAlert.

http://www.tekalign.com/

Это не позволит посторонним лицам испортить вашу реализацию Jabber, поскольку они могут решить использовать ее для чего-то другого (общения, отправки сообщений другим пользователям).

Я также согласен насчет net send. Он уходит, и его обычно отключают, так как он использовался для рассылки спама.

Дайте мне знать, что вы думаете и как все прошло ;-)

решение4

Использовал клиент PSI jabber. У него есть всплывающие уведомления вместе со звуковыми уведомлениями. То же самое касается клиента JAJC jabber.

Связанный контент