Tenemos el requisito de enviar alertas de escritorio a varios usuarios (cumplimiento, producción) a través de una red cuando otros usuarios han enviado contenido en línea para un informe.
Actualmente estamos usando NET SEND pero no tiene garantía de entrega y ha demostrado ser poco confiable tanto desde la perspectiva del cliente como del servidor (y supongo que no será compatible con versiones posteriores de Windows; actualmente estamos ejecutando XP).
Estamos considerando una solución basada en Jabber, pero ¿alguien ha usado un cliente Jabber para mostrar mensajes de alerta emergentes en la pantalla como lo hace NET SEND, en lugar de simplemente traer una ventana de chat al frente o mostrar un mensaje temporal cerca del sistema? bandeja.
Necesitamos que el mensaje de alerta sea persistente y solo lo descarte el usuario, indicando que lo ha visto. Las ventanas emergentes estilo brindis estarían bien siempre y cuando no fueran solo por un tiempo limitado y el usuario tuviera que descartarlas nuevamente.
¿Alguna solución?
Respuesta1
Tenemos algo similar en casa. Usamos el cliente de mensajería instantánea Miranda con los complementos notifyanything y popup.
Notifyanything permite al cliente recibir mensajes udp en un puerto específico. La ventana emergente hace precisamente eso: muestra el mensaje en la ventana en la parte superior de la pantalla del usuario.
En nuestro caso, todo está en la red interna, por lo que la pérdida de paquetes UPD no es motivo de preocupación.
Aquí hay un ejemplo del script de Python que ejecutamos para enviar los mensajes udp desde los servidores a los usuarios:
#!/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)
Respuesta2
Me encontré con este problema exacto. El objetivo era entregar cada alerta a lo largo de una ruta de escalada: enviar la alerta a la siguiente persona en la lista si no se reconocía en un período de tiempo determinado. Determinamos que Jabber era la mejor solución, pero que para hacerlo bien teníamos que ampliar el protocolo o investigar más clientes. (El protocolo se presta muy bien a la extensión y hay innumerables clientes disponibles). Este problema se debía a que con frecuencia era deseable reconocer algunas alertas pero no otras.
Por ejemplo. El camino final de una alerta:
Enviar al administrador A a través de Jabber. Sin reconocimiento después de 5 minutos, enviado al administrador B a través de Jabber. Sin confirmación después de 5 minutos, enviada al administrador A por SMS. Sin confirmación después de 5 minutos, enviada al administrador B por SMS. No hay confirmación después de 5 minutos, enviada al administrador A y al gerente de B a través de Jabber. No hay confirmación después de 5 minutos, enviada al administrador A y al gerente B por SMS. El gerente evalúa la alerta, la reconoce o llama al administrador A o B.
El problema es que si se genera una segunda alerta en medio de este proceso, es posible que el administrador A o B desee reconocerla, pero no reconocer la primera alerta. Por ejemplo, si están ocupados con un problema distinto que generó la otra alerta, o si no están cerca de una computadora, sepa que la segunda alerta no es grave, pero que la primera alerta debe ser manejada por alguien cercano a una La computadora y el mecanismo de escalada es la forma más eficiente de encontrar a la persona adecuada.
Había dos tipos de entrega de mensajes en Jabber. (Creo que se llama normal vs chat) Es posible que uno de los dos tipos permitiera diferenciar en qué mensaje se respondía. Desafortunadamente, el tipo de mensajería que podría haber permitido esto causó inconvenientes extremos con los clientes que probamos si se recibía una gran avalancha de mensajes. (Además, no estoy seguro de si las personas que realizaron la prueba determinaron si era posible diferenciar a qué se respondía, debido a que este problema abrumaba las pruebas).
Como era exploratorio y realmente no teníamos tiempo para implementar una solución completa, no determinamos si el problema era simplemente elegir un mejor cliente o si eran necesarias extensiones al protocolo. Sigo pensando que Jabber es el mejor método para enviar alertas. Para cualquier sistema de entrega/escalamiento de alertas, una persona que reconoce una alerta debe asumir la propiedad de la alerta, y debería haber repercusiones para todos aquellos que no reconozcan una alerta. Esto tiene que funcionar con el sistema entendiendo la mejor manera de comunicarse con una persona, una rotación de guardia, el riesgo de inundaciones de alertas, la emisión de alertas creadas por una persona que actualmente está fuera de la rotación y cualquier consideración política causada por un sistema de alerta que accidentalmente crea responsabilidad si el sistema existente no la tiene.
Respuesta3
Lamento que esta no sea una respuesta exacta a su pregunta (sobre Jabber), pero es posible que desee consultar ReachAlert.
Esto evitaría que las personas corrompan su implementación de Jabber, ya que podrían decidir usarlo para otra cosa (chatear, enviar mensajes a otros usuarios).
También estoy de acuerdo con el envío neto. Está desapareciendo y es una práctica común desactivarlo, ya que se abusó de él para enviar spam.
Cuéntame qué te parece y cómo te va ;-)
Respuesta4
He utilizado el cliente PSI Jabber. Tiene notificaciones emergentes junto con notificaciones sonoras. Lo mismo ocurre con el cliente jabber JAJC.