🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: es.comp.lenguajes.java
Article #725

Re: Sugerencias de alarmas [Off topic]

#725
From: Eduardo Villanueva Che
Date: Mon, 05 Feb 2007 18:01
70 lines
3770 bytes
Guevonaso wrote:

> Hola gente.
> 
> Tengo una duda de como hacer una aplicación. Me gustaría que me
> dieseis sugerencias.
> 
> La cosa va así, hay una aplicación monitor. Cuando se produce cierto
> evento debe de "lanzar" una alarma.
> 
> Luego, varios clientes, programas residentes en cada ordenador,
> reciben esta alarma y muestran una ventana emergente al usuario
> indicando que tal evento se ha producido. Para que actuen en
> consecuencia.
> 
> Omito detalles concretos para abstrarme del detalle.
> 
> La duda es ¿cual es la mejor manera?
> 
> Se me ocurre una opción que no creo que me cueste demasiado hacer. El
> Monitor de alarma es un servidor que escucha por un puerto XX. Los
> clientes cada N segundos consultan al servidor y este les dice si ha
> habido alarma o no.
> 
> El inconveniente que le veo, que el cliente no se da cuenta de que hay
> una alarma hasta que la consulta...  la red tendrá más trafico ...
> 
> Alguna otra sugerencia? tambien habia pensado que fuese al reves, los
> clientes escuchan por el puerto XX y es el Monitor el que manda una
> llamada a dicho puerto por toda la red.

Esa es la opción buena ;)

> Pero esto no se como hacerlo y 
> si se puede. Creo que tendría que saber las IP de los clientes para
> hacerles la alerta....

Esa es una opción, cada cliente al inicializarse debería registrar su IP en
el servidor, y este sólo enviaría la alarma a la lista de IPs registradas.

Otra forma de realizar esto es con multicast.

La elección de una u otra dependerá de las necesidades de tu aplicación y de
la fiabilidad de tu red. Multicast es la opción óptima, ya que sólo
enviarás un paquete por alarma, independientemente del número de clientes.
y además los clientes no tendrán que registrarse en el servidor. Sin
embargo con multicast sólo puedes enviar datagramas UDP, lo que significa
que no recibirás ACKs por parte de los clientes ni reenviarás los paquetes
en caso de error.

Si no importa que se pueda perder alguna alarma, o si las alarmas se
reenvían cada cierto tiempo hasta que se solucione el problema, multicast
es la opción ganadora. Pero si necesitas tener la garantía de que cada
alarma llega a todos los clientes, pues tendrás que mantener la lista de
las IPs de los clientes activos, y enviarles un paquete TCP a cada uno
cuando tengas una alarma.

Por lo que comentas creo que el cliente no solo debería saber cuando hay una
alarma, sino también cuando /otro/ cliente ha solucionado la alarma, con lo
cual enviar mensajes multicast cada x segundos mientras esté activa la
alarma podría ser la mejor solución.

> ¿Mas opciones?
> 
> Un saludo.


Un saludo,

Eduardo Villanueva Che.
Technical Details
Message-ID: <eq7rd2$n7h$1@peque.uv.es>
Path: arc1-ca.pugleaf.net!g2news2.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!130.59.10.21.MISMATCH!kanaga.switch.ch!switch.ch!news.rediris.es!news.uv.es!not-for-mail
References: <1170680068.477682.69270@a75g2000cwd.googlegroups.com>

Show Full Headers
Complete Article Headers
X-Google-Thread: 1116f3,e8d2670e32c40b8b
X-Google-Attributes: gid1116f3,public
X-Google-Language: SPANISH,UTF8
Path: arc1-ca.pugleaf.net!g2news2.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!130.59.10.21.MISMATCH!kanaga.switch.ch!switch.ch!news.rediris.es!news.uv.es!not-for-mail
From: Eduardo Villanueva Che <eviche@alumni.uv.es>
Newsgroups: es.comp.lenguajes.java
Subject: Re: Sugerencias de alarmas [Off topic]
Date: Mon, 05 Feb 2007 19:01:14 +0100
Organization: Universitat de Valencia
Lines: 70
Distribution: es
Message-ID: <eq7rd2$n7h$1@peque.uv.es>
References: <1170680068.477682.69270@a75g2000cwd.googlegroups.com>
NNTP-Posting-Host: 213.149.250.5
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8Bit
X-Trace: peque.uv.es 1170698466 23793 213.149.250.5 (5 Feb 2007 18:01:06 GMT)
X-Complaints-To: newsmanager@uv.es
NNTP-Posting-Date: Mon, 5 Feb 2007 18:01:06 +0000 (UTC)
User-Agent: KNode/0.10.4