2008-11-11 8 views
10

Estoy rediseñando una aplicación que heredé que envía fotos digitales desde una computadora portátil a un servidor web. La idea es tomar fotos "en el campo" y publicarlas instantáneamente en una página web (con algunas características más sofisticadas).¿Cuál es el mejor diseño en .NET para enviar datos a través de una conexión de red no confiable (3G)?

Escenario típico
1. Las fotos se transfieren de la cámara a la computadora portátil con USB estándar.
2. Las fotos se procesan de varias maneras. (No es importante)
3. Cada foto se envía por CORREO en pequeños pedazos (~ 64 kb cada uno) utilizando una búsqueda webre a un servidor web Apache estándar donde se fusiona de nuevo.

El problema con el diseño actual es que a menudo se cuelga cuando la conexión de red no es confiable. Como estamos usando una red móvil (3G) y, a menudo, terminamos fuera de cobertura, necesito una forma de manejar esto correctamente.

Mi pregunta es si hay una mejor solución para hacer esto que no hará que la aplicación se cuelgue cuando la conexión se caiga de vez en cuando.

(Bono pregunta es cómo esto podría ser adecuadamente unidad probada, sin tener que realizar una caminata con el portátil.)

EDITAR 2008-11-24: ahora las he arreglado para crear un entorno de prueba adecuado para esto usando una combinación de NetLimiter y TMnetsim (freeware). Intenté establecer 5 kb/seg y soltar el 1% de todos los paquetes; mi aplicación aún funciona bien con el nuevo diseño.

EDITAR 2008-12-11: Solo para actualizar cómo lo hice. Creé un trabajador de fondo (como se sugiere a continuación) que se inicia cada vez que se detecta una cámara para copiar las fotos de la cámara a la PC. Luego, comencé a trabajar en otro entorno cuando los archivos llegan a la PC para cargarlos mediante una transferencia HTTP asíncrona. Definitivamente fue un dolor hacer todo bien, especialmente porque la operación debería ser "cancelable" en cualquier momento ... Pero de todos modos, ahora funciona. ¡UN GRAN AGRADECIMIENTO a todos los que me ayudaron!

Respuesta

2

yo evitaría el uso de HTTP en absoluto de cualquier hilo que tiene la interfaz de usuario a menos que realmente quiere bloquear hasta que se recibe la respuesta. Puede intentar usar la misma lógica de un hilo de fondo que se ejecutará todo el tiempo que lo necesite. Solo asegúrese de tener una lógica que detecte cuándo se pierde la conexión (probablemente a partir de un tiempo de espera) y la volverá a intentar a intervalos regulares (pero no frecuentes) hasta que vuelva a conectarse.

Su mejor opción sería la creación de algún tipo de proceso de trabajo de fondo que subir las fotos una vez que se guardan en un directorio de Dropbox en el dispositivo. Aunque diré que crear un proceso en segundo plano basado en .NET no es trivial.

1

Primero averigüe por qué está colgando: ¿las solicitudes están ahí? ¿Se van a tiempo? ¿Qué sucede si reduces la configuración de tiempo de espera?

¿Estás haciendo la POST desde el hilo de UI? (No haga eso :)

Es posible que detecte la caída de la conexión al hacer solicitudes de latido con tiempos de espera muy cortos, también.

+0

Parece como si envío algunos datos y la conexión se corta, mientras que los datos están "en camino", los datos se pierden y se bloquea el hilo de carga. Preferiría rediseñar la carga completa en lugar de intentar que ese código realmente desordenado sea estable. – Christopher

+0

Si establece un tiempo de espera, ¿eso es un honor? Ese sería mi primer puerto de escala. –

0

En primer lugar, colocaría el proceso de transferencia fuera de la aplicación. Sincronice archivos con una utilidad que le permita reiniciar la transferencia desde la mitad de la última transferencia.

Puede simular caídas de comunicación con algún tipo de Faraday cage.

0

¿Has mirado el Sync Framework?

creo que sirve, Bruno Figueiredo

+0

Esto es interesante. Sin embargo, probablemente necesitaría desarrollar mi propio proveedor; no es una opción usar algo más que Apache/PHP en el otro extremo. – Christopher

1

Es probable que tenga que utilizar en lugar de WebRequest.BeginGetResponse WebRequest.GetResponse, aunque no lo hace, entonces parece ser una forma de cancelar la respuesta (tal vez la eliminación de la WebRequest ayudará)

Además, usted podría intentar jugar con la propiedad Timeout de WebRequest

+0

¿Es realmente lo mejor hacer la carga de forma asincrónica? Lo tengo en un hilo separado de todos modos, y se siente como hacer el código aún más complicado para hacer llamadas asincrónicas. Podría estar equivocado aquí por supuesto. – Christopher

+0

No intentaría llamadas asíncronas si tiene problemas de red. Definitivamente necesita un modelo de transferencia "conectado ocasionalmente". – D3vtr0n

1

Una manera de probar esto sin sacar su portátil en los campos: tratar m0n0wall en una máquina de repuesto, y establecer sus reglas de firewall para exprimir ancho de banda y paquetes de drop.

Como alternativa, instale netlimiter en su servidor/cliente

+0

Ambas son ideas geniales, ¡gracias! – Christopher

0

me gustaría probar el uso de técnicas de almacenamiento en caché de ASP.NET con ADO.NET servicios de sincronización para la transferencia de datos.

tratar almacenamiento en caché de las imágenes en un formato binario o BLOB primera y almacenarlos en una base de datos de la CE local (o Express). luego Sincronice los datos a una base de datos del servidor central, a través de WebServices.

Intente crear un servicio web centralizado para manejar sus transferencias de imágenes en caché.

El servicio web recibiría los datos a través de los servicios de sincronización en un escenario "de vez en cuando conectado".

para las pruebas de unidad, intente utilizar una máquina virtual (VMware) o un ordenador portátil en una conexión de acceso telefónico.

Cuestiones relacionadas