Foros Club Delphi

Foros Club Delphi (https://www.clubdelphi.com/foros/index.php)
-   C++ Builder (https://www.clubdelphi.com/foros/forumdisplay.php?f=13)
-   -   Como saber si está conectada la aplicación cliente (https://www.clubdelphi.com/foros/showthread.php?t=90920)

MARX 08-10-2016 22:18:06

Como saber si está conectada la aplicación cliente
 
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] 10-10-2016 09:48:59

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

MARX 10-10-2016 15:24:38

Cita:

Empezado por Neftali (Mensaje 509467)
¿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] 10-10-2016 16:13:39

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

MARX 10-10-2016 17:45:18

Cita:

Empezado por Neftali (Mensaje 509473)
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 10-10-2016 18:53:44

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] 10-10-2016 19:17:37

Cita:

Empezado por MARX (Mensaje 509443)
¿hay alguna forma de saber desde el servidor cuando el cliente está conectado o desde el cliente cuando el servidor está conectado?

Cita:

Empezado por MARX (Mensaje 509478)
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.

:confused::confused::confused:

MARX 11-10-2016 18:46:41

Cita:

Empezado por mamcx (Mensaje 509480)
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?



Cita:

Empezado por Neftali (Mensaje 509481)
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.

:confused::confused::confused:

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 11-10-2016 20:44:37

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.

Cita:

Empezado por MARX (Mensaje 509497)
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.

Cita:

Empezado por MARX (Mensaje 509497)
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 12-10-2016 01:03:14

Cita:

Empezado por mamcx (Mensaje 509498)
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 12-10-2016 18:54:59

Cita:

Empezado por MARX (Mensaje 509501)
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.

Cita:

Empezado por MARX (Mensaje 509501)
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 13-10-2016 20:11:38

Cita:

Empezado por mamcx (Mensaje 509513)
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.

Cita:

Empezado por mamcx (Mensaje 509513)
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 13-10-2016 21:55:02

Hola.
Cita:

Empezado por MARX (Mensaje 509534)
...
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 13-10-2016 22:12:10

Hola de nuevo.

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


AnsiString IndyVersion
()
{
  
AnsiString ver;
  
TIdHTTPIdHTTP = 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 14-10-2016 02:41:05

Cita:

Empezado por ecfisa (Mensaje 509536)
Hola de nuevo.

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


AnsiString IndyVersion
()
{
  
AnsiString ver;
  
TIdHTTPIdHTTP = 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 26-10-2016 16:54:12

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 26-10-2016 17:21:57

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
Cita:

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:

Cita:

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 26-10-2016 17:44:47

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 :D


La franja horaria es GMT +2. Ahora son las 00:48:06.

Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi