iOS: aleatorio "No se puede conectar al host" con 3G

Estoy trabajando en una aplicación de iOS que funciona como un thin client para un server de negocios. Hay muchas requestes enviadas al server, una gran cantidad de datos descargados.

No utilizo ningún marco de request de fantasía, solo una NSURLConnection asíncrona con un delegado.

La aplicación generalmente funciona muy bien con wifi y 3G BUT

Algunos usuarios informan desconexiones aleatorias al usar 3G (en EE. UU.). Todas las requestes son okey pero de vez en cuando una request falla con el error "No se puede conectar con el host" (-1004).

Esto afecta mucho la experiencia del usuario.

Algunos hechos:

  1. No sucede en wifi
  2. Los usuarios informan que no sucede con otras aplicaciones cuando usa 3G.
  3. No es un problema de time de espera, el error aparece 0.3-1.0 segundos después de iniciar la connection.
  4. No pudimos reproducir el problema usando traceroute.
  5. Al usar SCNetworkReachability el host parece ser accesible (conozco las limitaciones de esta API).

Pregunta ¿Cuál podría ser la causa del problema? ¿Qué properties de connection pueden diferir con 3G y Wi-Fi? ¿Cómo puedo depurarlo?

Actualmente, la única solución que veo es tratar de enviar la request nuevamente si la request anterior ha fallado. Sin embargo, primero me gustaría encontrar la causa del problema.

EDITAR El problema probablemente fue causado por uno de nuestros enrutadores. Los chicos todavía están inspeccionando el problema.

Todos los códigos de error se pueden encontrar en la documentation de Apple en la sección

Referencia de códigos de error CFNetwork

El código -1004 se describe solo como

kCFURLErrorCannotConnectToHost

La connection falló porque no se puede realizar una connection al host. Disponible en OS X v10.6 y posterior. Declarado en CFNetworkErrors.h.

Básicamente significa que el usuario tiene una connection (no está en modo de vuelo, el tráfico de datos está encendido y su teléfono está registrado en la networking, tenía una URL válida, etc.) pero se evitó activamente que se conectara al server . Si el server no respondiera, habría tenido algo más como un error de time de espera después de un time de espera más largo, como describió. Este tipo de error es probablemente causado por algo que impide el tráfico al server y, por ejemplo, puede ocurrir si el usuario está detrás de un firewall o un proxy.

El problema podría ser causado por el proveedor, especialmente si no tiene problemas con algunos usuarios y problemas aleatorios con otros.

Como dijo otro póster, podría tratar de preguntar a sus usuarios sobre su proveedor de services, y más detalles sobre su location, o qué estaban haciendo cuando obtuvieron el error (como sentarse en un vehículo o tener mala recepción en el campo)

Si no puede encontrar ningún patrón, y si el error realmente ocurre de manera aleatoria y solo para algunos usuarios, y solo algunas veces, simplemente consideraría que es otro problema inevitable que puede ser causado por el hecho de que los teléfonos mobilees nunca están garantizados estar conectado todo el time , y que algunos proveedores de teléfonos celulares no siempre entreguen el 100% de todos los packages que deben entregarse allí … lo que debe hacer es manejar el error.

Desarrolle el error simplemente reintentando y no mostrándolo al usuario, al less no hasta después de una cantidad suficiente de rebashs.

Una última cosa a considerar:

Si envía muchas requestes de su aplicación y muchos datos, asegúrese de que no está "consumiendo demasiado" enviando spam a grandes cantidades de requestes sin terminar. Esto podría hacer que el server o algún server proxy en el path rechace su request porque está demasiado ocupado respondiendo su otra request. Una request rechazada podría causar un error como ese. Asegúrese de enviar una cantidad razonable de requestes para que el dispositivo de su usuario tenga time para "respirar".

Deje que su esquema de rebash sea inteligente cuando comience reintentando un montón de veces en less time, y si sigue fallando, aumente el lapso de time para el próximo rebash.

Volvería a considerar la suposition de que solo afecta su aplicación. Hay muchas maneras en que los usuarios solo pueden ver problemas con su aplicación, incluso si el problema es con su connection a Internet. Por ejemplo, quizás las otras aplicaciones vuelvan a intentarlo de forma transparente; los usuarios simplemente verían velocidades de actualización lentas. O quizás las conexiones interrumpidas simplemente no importan para las otras aplicaciones.

¿Ha preguntado a los usuarios afectados qué proveedor están utilizando? Si todos usan la misma networking mobile, eso indicaría que es un problema con la networking en lugar de su aplicación.

Me parece que la razón de esto es simplemente la naturaleza de los datos celulares y el acceso a Internet. Como sabrá, cuando está utilizando una connection celular, a veces, especialmente si se está moviendo, la connection cambiará de networking a medida que cambia las torres de transmisión.

Menciona que está descargando una gran cantidad de datos ya intervalos muy cortos, supongo que esto hace que su aplicación sea más propensa a este problema, y ​​no aceptaría por un segundo que esto no sucedería para otras aplicaciones, se trata de synchronization.