🚀 go-pugleaf

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.

On Feb 5, 4:54 am, "Guevonaso" <fernando.ros...@gmail.com> 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. 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....
>
> ¿Mas opciones?
>
> Un saludo.

Otra opción seria usar el patrón obervador como el método de saber a
quien hay que notificar cuando ocurre el evento:

Cuando un cliente empieza, notifica el servidor que quiere estar
notificado de sus eventos, Y el servidor graba la referencia de todos
los clientes que queren estar notificados. Cuando ocurre el evento en
el servidor, ya sabe a quien notificar.

Es mas, usando Java RMI no hay que preocupar se con la comunicación en
el nivel bajo, y se puede poner en practica communicando entre los
objects directamente.

Algunos links que seguro pueden expicar lo mejor que yo:

http://es.wikipedia.org/wiki/Observer_%28patr%C3%B3n_de_dise%C3%B1o%29
http://en.wikipedia.org/wiki/Observer_pattern

http://es.wikipedia.org/wiki/RMI

http://java.sun.com/j2se/1.5.0/docs/api/java/util/Observer.html
http://java.sun.com/j2se/1.5.0/docs/api/java/util/Observable.html

Saludos,
Carl.

> 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.
>
Tambien puedes implementarte tu mediante CRC32 o parecido un mecanismo
de deteccion de paquetes dañados, y enviar de vuelta un ACK/NACK,
claro q es un poco reinventar la rueda, pero puede tener ventajas en
funcion de tu red (si las ventajas de multicast son importantes)

On 5 feb, 19:16, "Carl" <c.gro...@gmail.com> wrote:
>[...]
> Otra opción seria usar el patrón obervador como el método de saber a
> quien hay que notificar cuando ocurre el evento:
[...]
> Es mas, usando Java RMI no hay que preocupar se con la comunicación en
> el nivel bajo, y se puede poner en practica communicando entre los
> objects directamente.
>
[...]
> Saludos,
> Carl.



Muchas gracias, creo que lo voy a plantear así. Ahora tengo que buscar
informacion sobre RMI.
Fernando.