Socket Error # 10054 con TIdHTTP

[fide_uci]

A mi me sucede lo mismo. Pero la verdad es que especificamente no se por que. yo he creado un Cliente/Servidor de mensajeria instantania que me trabaja de maravillas. Pero en algunas ocasiones, muy aleatorias por cierto, el cliente se me desconecta dandome ese mismo error. Dado que aun no he implementado los paquetes KEEP_ALIVE (es este caso PING-PONG o sea que el cliente le envie un paquete al servidor para que este sepa que la conexion aun permanece activa) estoy por pensar que el servidor cierra la conexion por el tiempo que demora el cliente sin enviar ningun paquete. A lo mejor esto lo controla el mismo Switch de mi centro pero eso no lo se. La verdad es que de momento no se como resolverlo. Y cuando implemente el paquete KEEP_ALIVE, si me sigue dando el mismo error, voy a tener que hacer algun truquito para que el usuario no vea el error y parezca que no ha sucedido nada. Aunque no me gustaria hacerlo asi, pero bueno que remedio. !!!

[rolandoj]

Empezado por fide_uci

A mi me sucede lo mismo. Pero la verdad es que especificamente no se por que. yo he creado un Cliente/Servidor de mensajeria instantania que me trabaja de maravillas. Pero en algunas ocasiones, muy aleatorias por cierto, el cliente se me desconecta dandome ese mismo error. Dado que aun no he implementado los paquetes KEEP_ALIVE (es este caso PING-PONG o sea que el cliente le envie un paquete al servidor para que este sepa que la conexion aun permanece activa) estoy por pensar que el servidor cierra la conexion por el tiempo que demora el cliente sin enviar ningun paquete. A lo mejor esto lo controla el mismo Switch de mi centro pero eso no lo se. La verdad es que de momento no se como resolverlo. Y cuando implemente el paquete KEEP_ALIVE, si me sigue dando el mismo error, voy a tener que hacer algun truquito para que el usuario no vea el error y parezca que no ha sucedido nada. Aunque no me gustaria hacerlo asi, pero bueno que remedio. !!!

Hola,

Gracias por los comentarios.

Infortunadamente, nunca he tenido noticias de una verdadera solución. Para efectos prácticos, la que expliqué antes es la que uso desde entonces. Te sugiero que la utilices, ya que para el usuario es transparente (a menos que el error se repita demasiadas veces, lo que no recuerdo que me haya ocurrido).

[fide_uci]

hmm, esta bien. Vere si soluciono el priblema por la otra via, si no es asi entonces usare esa que me das. Thanks !!!

[kishorfarm]

Estoy en la misma situación, con la necesidad de enviar un GET periódico para actualizar una DNS dinámica. Si uso solo el GET al final me salen excepciones "Socket error # 10054".

Tu solución no es mala pero yo lo que voy a hacer es, directamente, crear y destruir el componentge TIdHTTP cada vez que tenga que hacer un GET o un POST.

On Timer (5 minutos)

Create TIdHTTP;
try
Connect TIdHTTP;
Get;
Procesado de respuesta;
finally
Disconnect TIdHTTP;
Free TIdHTTP;
end


Cuando lo pruebe ya comentaré el resultado.

[rolandoj]

Hola,

La verdad, nunca he sabido más nada del asunto. La solución que describí la uso desde entonces y siempre ha funcionado bien.

La solución que planteas no la he usado. Debe servir también; pero, si la cantidad de llamadas es significativa, probablemente la frecuencia de errores será comparativamente baja y por ello el crear, y destruír, siempre el componente será más ineficiente que reiniciarlo solo cuandio se produzca un error.

Saludos

[_cero_]

Este problema ocurre por puertos bloqueados en el firewall (o eso creo), curiosamente no ocurre cuando se intenta conectar el componente sino cuando se desconecta (de ahí a que pase después de un tiempo), la solución más feucha que sirve al menos para comprobar esto, es desactivar el firewall para que vean que ya no da el error.

Ahora a mi seme soluciono después de abrir el puerto 21 que ocupaba para un TIdFTP, prueben eso que a mi si me funciono, pero no sé porque, ya que si el puerto estuviera bloqueado no me permitiría conectar, además solo pasa en xp, porque en vista o 7 todo va de maravilla.

Pd. Me uno a la petición de que un experto en redes nos explique esta onda con el firewall.

[rolandoj]

Hola,

Gracias por la información.

Lo del Firewall es un dato interesante. En mi caso, al menos del lado del cliente, ese no era el problema. Ahora, el servidor era remoto y yo no tenía control total; así que no hice esa prueba, quizás si era por ahí.

De todas formas, aún si fuera por el firewall, habría que saber exactamente que parámetro causa el problema, así que el hilo sigue vivo.

Por otro lado, desde un punto de vista práctico, las soluciones disponibles son efectivas. En mi caso, ha funcionado tan bien que ya ni me acordaba de este hilo.

El tema es entonces más que todo de interés académico, aunque quizás en aplicaciones que tengan una enorme carga de llamadas puede ser valioso hallar una solución mejor.