Como saber si está conectada la aplicación cliente

[MARX]

Hola a todos.
Vengo con una pregunta que espero me la sepan responder.
Tengo dos aplicaciones, un servidor y un cliente, ambas en maquinas diferentes.
Las dos aplicaciones se envían datos la una a la otra por medio de una conexión cliente/servidor de la herramienta Indy
La pregunta es la siguiente ¿hay alguna forma de saber desde el servidor cuando el cliente está conectado o desde el cliente cuando el servidor está conectado?.
Lo que yo estoy haciendo ahora es enviar un comando y detectar la excepción si no hay respuesta del otro lado. El problema de este método es que la aplicación se queda sin responder y parece colgada hasta que determina que no hay respuesta.
Si pudiera enviar un ping a un programa determinado podría solucionar el problema ya que un ping determina rápidamente si hay respuesta del otro lado o no.

Se me había ocurrido hacer un ping con IdIcmpClient, pero con este solo pude hacer un ping a la PC, no a la aplicación y solo ejecutando la aplicación servidor como administrador

Espero me puedan ayudar

Saludos
MARX

[Neftali [Germán.Estévez]]

¿Estás conectando con sockets?
¿Qué componentes estás utilizando para la conexión?
¿TidTCPClient, TidTCPServer?

[MARX]

Empezado por Neftali

¿Estás conectando con sockets?
¿Qué componentes estás utilizando para la conexión?
¿TidTCPClient, TidTCPServer?

Hola Neftali.
Efectivamente, estoy utilizando TidTCPClient y TidTCPServer.

[Neftali [Germán.Estévez]]

Revisa los eventos de estos componentes. Poseen unos llamados OnConnected y OnDisconnected.
Deberían servirte para lo que necesitas.

[MARX]

Empezado por Neftali

Revisa los eventos de estos componentes. Poseen unos llamados OnConnected y OnDisconnected.
Deberían servirte para lo que necesitas.

Pero esos eventos ocurren cuando se conecta o se desconecta, no creo que me sirva para determinar si la aplicación que está en la otra PC está conectada o no.
¿o me equivoco?

No tengo idea si la herrmienta TIdEcho y TIdECHOServer me puede servir para esto

[mamcx]

Honestamente no se puede hacer lo que dices. Para notificar desde la una que la otra esta desconectada, pues tienen que tener conexion!

----

Lo que se hace es que se define un "timeout" y un metodo de "ping" que corre dentro de la ventana del timeout. Si el ping falla, se asume que esta desconectado. Algunos componentes tienen esa opcion automatica.

La otra, es que debes mejorar el codigo que hace los envios. No deberia "colgar" la app (usas un thread aparte, como debe ser?).

SIN EMBARGO

La UNICA forma confiable de saber si hay o no conexión es HACIENDO LA CONEXION.

UNICA FORMA.

Todo lo demas son simples aproximaciones.

[Neftali [Germán.Estévez]]

Empezado por MARX

¿hay alguna forma de saber desde el servidor cuando el cliente está conectado o desde el cliente cuando el servidor está conectado?

Empezado por MARX

Pero esos eventos ocurren cuando se conecta o se desconecta, no creo que me sirva para determinar si la aplicación que está en la otra PC está conectada o no.
¿o me equivoco?

No acabo de entender...
A no ser que te refieras a saber si las aplicacione están funcionando (no conectadas entre si).

porque una vez que se conectan desde ambos extremos tienen los eventos de conexión/desconexión.

[MARX]

Empezado por mamcx

Honestamente no se puede hacer lo que dices. Para notificar desde la una que la otra esta desconectada, pues tienen que tener conexion!

----

Lo que se hace es que se define un "timeout" y un metodo de "ping" que corre dentro de la ventana del timeout. Si el ping falla, se asume que esta desconectado. Algunos componentes tienen esa opcion automatica.

La otra, es que debes mejorar el codigo que hace los envios. No deberia "colgar" la app (usas un thread aparte, como debe ser?).

SIN EMBARGO

La UNICA forma confiable de saber si hay o no conexión es HACIENDO LA CONEXION.

UNICA FORMA.

Todo lo demas son simples aproximaciones.

Es lo que estoy haciendo hasta ahora. Ya había probado modificando el tiempo de ConnectTimeout pero no funciona la conexión, probé con un valor de 1, 10, 50, 100, 500, 800, 1000, etc pero no funciona. Poniendo un tiempo diferente a 0 me tira siempre un el error "Connect timed out".

Me interesa lo del thread a parte ¿Como puedo hacer para usar un thread a parte?

Empezado por Neftali

No acabo de entender...
A no ser que te refieras a saber si las aplicaciones están funcionando (no conectadas entre si).

porque una vez que se conectan desde ambos extremos tienen los eventos de conexión/desconexión.

Lo que quiero hacer es que el servidor se de cuenta que terminales están conectadas y que las terminales se den cuenta si el servidor está conectado sin que la PC se cuelgue mientras espera la respuesta del otro lado.
Lo que hago ahora es que en el evento OnCreate del servidor envíe un dato avisando a las terminales que se conectó, el problema está en que cuando manda el dato a las terminales que no están conectadas se queda un rato esperando la respuesta. Eso hace que la aplicación tarde en iniciar y queda a medio abrir.
Solucioné gran parte del problema determinando al iniciar el programa cuales son las terminales conectadas y guardando en una tabla esa información, entonces no le envío datos a las terminales que figuran como desconectadas. Cuando una de las terminales que estaban desconectadas se conecta modifico esa info en la tabla.
Entonces solo tardaría para determinar las terminales conectadas y desconectadas cuando inicio el programa, en el resto del programa se va enterando en el proceso de ejecución cuando se conectan y cuando se desconectan las terminales.
Y lo mismo hago con las terminales para saber si el servidor está conectado.

[mamcx]

Presta atencion a lo que se te dice:

NO SE PUEDE HACER.

Lo que estas pidiendo es un *sin sentido*. Lo unico que se puede hacer es una heuristica.

Empezado por MARX

Es lo que estoy haciendo hasta ahora. Ya había probado modificando el tiempo de ConnectTimeout pero no funciona la conexión, probé con un valor de 1, 10, 50, 100, 500, 800, 1000, etc pero no funciona. Poniendo un tiempo diferente a 0 me tira siempre un el error "Connect timed out".

No. Estas haciendo cosas sin entender como funcionan. Adivinando no se llega a ningun lado. ConnectTimeout solo dice en cuanto tiempo se desiste de intentar la conexion. Aumentar solo hara mas larga la espera en una conexion fallida. No tiene otra implicacion.

Empezado por MARX

Lo que hago ahora es que en el evento OnCreate del servidor envíe un dato avisando a las terminales que se conectó, el problema está en que cuando manda el dato a las terminales que no están conectadas se queda un rato esperando la respuesta. Eso hace que la aplicación tarde en iniciar y queda a medio abrir.

Este es tu problema? Entonces en vez de inventar una "solucion" que no funciona (porque no estas teniendo en cuenta como funcionan las redes) y luego al ver que no es la solucion estas tratando de aplicar otra solucion sobre la falla. Asi solo estas complicandote la vida.

Debes entender que la conexion va a fallar. Asi que en vez de tratar de encontrar la forma de que "no falle", es reaccionar *correctamente*. Intenta la conexion, pon un timeout corto (o el por defecto) y procede acorde. Recibe cuando los clientes se conecten que ya hay otra vez linea y procede.

Si te esta bloqueando la ejecucion es porque no estan usando codigo asincronico o un thread aparte para la comunicacion, Busca en el foro al respecto.

Pero principalmente, trata de entender como funcionan las redes para que no des palos de ciego.

---

P.D: En estos casos es muy util si haces un diagrama de maquina de estado, y analizas que debes hacer en cada estado, luego lo codificas. Eso resultara en un codigo mas correcto.

[MARX]

Empezado por mamcx

Presta atencion a lo que se te dice:

NO SE PUEDE HACER.

Lo que estas pidiendo es un *sin sentido*. Lo unico que se puede hacer es una heuristica.



No. Estas haciendo cosas sin entender como funcionan. Adivinando no se llega a ningun lado. ConnectTimeout solo dice en cuanto tiempo se desiste de intentar la conexion. Aumentar solo hara mas larga la espera en una conexion fallida. No tiene otra implicacion.



Este es tu problema? Entonces en vez de inventar una "solucion" que no funciona (porque no estas teniendo en cuenta como funcionan las redes) y luego al ver que no es la solucion estas tratando de aplicar otra solucion sobre la falla. Asi solo estas complicandote la vida.

Debes entender que la conexion va a fallar. Asi que en vez de tratar de encontrar la forma de que "no falle", es reaccionar *correctamente*. Intenta la conexion, pon un timeout corto (o el por defecto) y procede acorde. Recibe cuando los clientes se conecten que ya hay otra vez linea y procede.

Si te esta bloqueando la ejecucion es porque no estan usando codigo asincronico o un thread aparte para la comunicacion, Busca en el foro al respecto.

Pero principalmente, trata de entender como funcionan las redes para que no des palos de ciego.

---

P.D: En estos casos es muy util si haces un diagrama de maquina de estado, y analizas que debes hacer en cada estado, luego lo codificas. Eso resultara en un codigo mas correcto.

Creo que no me has entendido.

1)- En ningún momento intenté sobre el error como me has dicho. Solo dije como solucione, hasta ahora, el problema que tengo con el tiempo de verificación de estado de los terminales. Estoy acá buscando una solución mas eficiente.
4)- Nunca intenté inventar una solución porque no propuse ninguna, solo comuniqué lo que hice. Acá estoy para encontrar una respuesta.
2)- Probé, antes de traer esta inquietud al foro, con valores bajos en la propiedad ConnectTimeout, para que la aplicación cliente desista antes si la conexión es fallida, pero eso me trajo el problema de que poniendo cualquier valor distinto de cero, me aparezca el error "Connect timed out", no importa que valor ponga, si 1 o 2 o 1000. Subí los tiempos de ConnectTimeout porque pensé que el problema de que me apareciera el error todo el tiempo era porque ponía tiempos muy bajos. Solo volviendo el valor a cero hacía la conexión con las terminales en ejecución.
3)- Entiendo bien que algunas conexiones van a fallar, por eso busco una alternativa para solucionar el alto tiempo de inicio al intentar determinar cuales son los terminales desconectados. Por eso me interesé en el tema que propusiste sobre los "thread".

No soy una persona necia, vine a este foro a comunicar cual es el problema con el que me encontré, brindando los datos de los procedimientos que implementé.
En ningún momento me empeciné en resolver el problema siguiendo únicamente la linea que venía siguiendo.

Espero la próxima vez seas mas paciente al leer y me ayudes a encontrar una solución.

PD: No soy un Ing. en sistema, solo soy un simple ingeniero en Electrónica que le fascina la programación tanto como la electrónica.


Saludos
MARX

[mamcx]

Empezado por MARX

Creo que no me has entendido.
3)- Entiendo bien que algunas conexiones van a fallar, por eso busco una alternativa para solucionar el alto tiempo de inicio al intentar determinar cuales son los terminales desconectados. Por eso me interesé en el tema que propusiste sobre los "thread".

Entonces este es tu real problema? Porque todo lo demas lo que hizo fue complicar la situacion.

Empezado por MARX

2)- ....Solo volviendo el valor a cero hacía la conexión con las terminales en ejecución.

Esto si me parece raro. No deberia ser asi.

Asi que busque el problema y encontre esto:

https://stackoverflow.com/questions/...ip-connections

Hay que leer los comentarios y los links enlazados.

Inesperadamente, parece ser un problema de Indy. Se recomienda actualizar a ultima version y seguir las recomendaciones.

[MARX]

Empezado por mamcx

Entonces este es tu real problema? Porque todo lo demas lo que hizo fue complicar la situacion.

No complique la situación, le estaba explicando a uno de los usuario lo que hice porque no entendía que era lo que quería hacer.

Empezado por mamcx

Esto si me parece raro. No deberia ser asi.

Asi que busque el problema y encontre esto:

https://stackoverflow.com/questions/...ip-connections

Hay que leer los comentarios y los links enlazados.

Inesperadamente, parece ser un problema de Indy. Se recomienda actualizar a ultima version y seguir las recomendaciones.

Gracias por el dato mamcx.
Aunque es raro porque dicen que en la versión 2010 y la XE funciona bien y yo estoy utilizando la versión XE8
No se que versión de Indy trae el XE8. ¿Como puedo ver la versión del indy?

De todas formas, si alguien tiene algún dato sobre este problema ruego me lo comuniquen. Por mi parte seguiré buscando.
Desde ya agradezco cualquier otra información que me puedan brindar.

Saludos
MARX

[ecfisa]

Hola.

Empezado por MARX

...
Aunque es raro porque dicen que en la versión 2010 y la XE funciona bien y yo estoy utilizando la versión XE8
No se que versión de Indy trae el XE8. ¿Como puedo ver la versión del indy?
...

No sé si servirá en la versión de Delphi que estas usando, pero intentalo de este modo:

Código Delphi [-]
...
uses IdHTTP;
...
function IndyVersion: string;
var
  idHTTP1: TIdHTTP;
begin
  idHTTP1 := TIdHTTP.Create( nil );
  try
    Result := IdHTTP1.Version;
  finally
    idHTTP1.Free;
  end;
end;

Uso:

Código Delphi [-]
...
begin
  ShowMessageFmt( 'Versión Indy: %s', [IndyVersion] );
...

Saludos

[ecfisa]

Hola de nuevo.

Perdón no ví que el foro era C++, entonces sería:

Código PHP:


AnsiString IndyVersion()
{
  AnsiString ver;
  TIdHTTP* IdHTTP = new TIdHTTP(NULL);

  try {
    ver = IdHTTP->Version;
  } __finally {
    delete IdHTTP;
  }

  return ver;
} 


(por supuesto que también podes hacerlo volcando el componente en tiempo de diseño, ahorrándote la creación y destrucción)

Saludos

[MARX]

Empezado por ecfisa

Hola de nuevo.

Perdón no ví que el foro era C++, entonces sería:

Código PHP:


AnsiString IndyVersion()
{
  AnsiString ver;
  TIdHTTP* IdHTTP = new TIdHTTP(NULL);

  try {
    ver = IdHTTP->Version;
  } __finally {
    delete IdHTTP;
  }

  return ver;
} 


(por supuesto que también podes hacerlo volcando el componente en tiempo de diseño, ahorrándote la creación y destrucción)

Saludos

Gracias ecfisa, no lo pude hacer andar de esa manera.
Lo que hice fue hacer TidTCPServer1->Version y lo puse en un Edit. La versión que me acusa es la 10.6.2.5263, que supongo sera la versión del Indy. Así que no debería tener problema si cambio el el valor del ConnectTimeout. Tendré que buscar más información en la red
Gracias una vez mas ecfisa. Siempre solucionandome problemas.
De más está decir que si saben algo sobre el problema principal planteado me avisen.
Desde ya muchas gracias.

Saludos
MARX

[Snaked]

hola MARX una posible solucion que se me ocurre, es que teniendo un servidor en internet tipo hosting linux, crees un archivo_token en algun lugar del servidor y que dicho archivo contenga algo asi como una linea que ponga SERVER_STATUS=0 o SERVER_STATUS=1 de forma que consultando por FTP el contenido de ese archivo sepas si esta en marcha tu aplicacion tipo SERVER o no

Por supuesto la aplicacion SERVIDORA tendria a su vez, que cambiar ese SERVER_STATUS segun entrase en funcionamiento o saliese
y lo mismo respecto a los clientes......refiriendonos a la parte "aplicacion en ejecucion"....es una posible solucion que funciona, yo mismo a veces he utilizado algo asi para algunas cosas....otra cosa a tener en cuenta seria en ese fichero "Token" anotar la direccion IP actualizada de los terminales que se conecten a la red

en la ayuda de C++ Builder viene como crear conectar etc un cliente de FTP sencillo

[mamcx]

No.

Porque la app puede caerse ANTES de poder "Cambiar" su estado.

La *UNICA* forma confiable es intentando al conexion y usando timeouts. NO HAY DE OTRA.

Esto se conoce como el problema de los 2 generales:

https://es.wikipedia.org/wiki/Proble..._dos_generales

En computación, el Problema de los dos generales, también llamado Problema de las dos armadas o Problema del Ataque Coordinado, es un experimento mental que ilustra los problemas y retos de diseño involucrados en la coordinación de una acción a través de una comunicación a través de un vínculo poco fiable.

Existen formas y algoritmos sofisticados que ayudan, pero todo se reduce al final a lo anterior. NO HAY FORMA de hacer esto confiable, solo con un grado de certeza.

Y lo que te estoy diciendo es por mucho lo mas simple que puede funcionar. El truco, como dice el articulo:

Un enfoque pragmático para hacer frente al problema de los dos generales es utilizar esquemas que acepten la incertidumbre del canal de comunicaciones y no intente eliminarla, sino mitigarla hasta un grado aceptable.

[MARX]

Gracias por sus respuestas.
Solucioné el problema hace unos días utilizando el timeout en 500 y hago la comprobación de la conexión de las terminales en otro hilo.
Investigando el tema que me propuso mamcx sobre los thread a parte, hago la comprobación del estado de las terminales en paralelo y ya no se me cuelga el programa mientras chequea las terminales.
Muchas gracias a todos. Me han ayudado mucho y he aprendido a utilizar una herramienta muy importante.

Saludos y hasta la próxima