sondeo de un servidor HTTP del cliente J2ME

StackOverflow https://stackoverflow.com/questions/1249605

Pregunta

Tengo una aplicación J2ME corriendo en mi teléfono móvil (cliente),

Me gustaría abrir una conexión HTTP con el servidor y mantener el sondeo para obtener información actualizada en el servidor.

Cada sondeo realizado utilizará GPRS bytes y resultaría costoso en el largo plazo, como la facturación GPRS se basa en los paquetes enviados y recibidos. ¿Hay una manera eficiente de bytes de votación mediante el protocolo HTTP ?.

También he oído hablar de sondeo largo, pero no estoy seguro de cómo funciona y qué tan eficiente que sería.

En realidad la forma preffered sería que el servidor de decir la aplicación de teléfono que los nuevos datos está listo para ser usado que no será necesario para hacer el sondeo manera, sin embargo no sé de estas técnicas, especialmente en J2ME.

¿Fue útil?

Solución

Si desea resolver este problema utilizando sólo HTTP, sondeo largo sería la mejor camino. Es bastante fácil. Lo primero que necesita para configurar una dirección URL en el lado del servidor para la notificación (por ejemplo http://example.com/notify), y definir un protocolo de notificación. El protocolo puede ser tan simple como algunas líneas de texto y cada línea es un evento. Por ejemplo, 

  MSG user1
  PHOTO user2 album1
  EMAIL user1
  HEARTBEAT 300

El hilo de votación en el teléfono funciona así,

  1. Haga una conexión HTTP con el URL de notificación. En J2ME, puede utilizar GCF HttpConnection.
  2. El servidor bloqueará si hay eventos para empujar.
  3. Si el servidor responde, obtener cada línea y generar un nuevo subproceso para notificar a la aplicación y el bucle de retorno al # 1.
  4. Si la conexión se cierra por cualquier razón, el sueño por un tiempo y volver al paso 1.

Hay que prestar atención a los siguientes detalles de implementación,

  1. Tune HTTP tiempos de espera tanto en el cliente y el servidor. Cuanto más largo sea el tiempo de espera, la más eficiente. Agotado el tiempo de conexión provocará una reconexión.
  2. Habilitar HTTP keepalive tanto en el teléfono y el servidor. 3-way handshake del TCP es costosa en términos de GPRS a fin de tratar de evitarlo.
  3. a detectar conexiones rancios. En entornos móviles, es muy fácil conseguir conexiones HTTP rancios (conexión se ha ido, pero el hilo de votación sigue a la espera). Se puede utilizar para recuperar los latidos del corazón. Decir ritmo cardíaco es de 5 minutos. Servidor debe enviar una notificación de cada 5 minutos. Si no hay datos para empujar, basta con enviar latido del corazón. En el teléfono, el hilo de votación debe tratar de cerrar y volver a abrir la conexión de votación si nada recibido durante 5 minutos.
  4. Manejo de errores de conectividad con cuidado. Sondeo largo no funciona bien cuando hay problemas de conectividad. Si no se maneja adecuadamente, puede ser el acuerdo para romper. Por ejemplo, se puede perder una gran cantidad de paquetes en el paso 4 si el sueño es lo suficientemente largo. Si es posible, comprobar la disponibilidad de GPRS en el teléfono y poner el hilo de votación en espera cuando GPRS no está disponible para ahorrar batería.
  5. coste del servidor puede ser muy alto si no se aplican correctamente. Por ejemplo, si se utiliza servlets Java, cada aplicación que se ejecuta tendrá al menos una conexión de sondeo y su hilo correspondiente. Dependiendo del número de usuarios, esto puede matar a un Tomcat rápidamente :) Es necesario utilizar tecnologías de eficiencia de recursos, como Apache Mina.

Me dijeron que hay otras maneras más eficaces para impulsar las notificaciones al teléfono, al igual que el uso de SMS y algunos trucos de nivel IP. Pero ya sea que tiene que hacer un poco de programación no portátiles de bajo nivel o encontrarse con riesgos de violaciónes de patentes. Sondeo largo es probablemente lo mejor que se puede conseguir con una única solución de HTTP.

Otros consejos

No sé exactamente lo que quiere decir con "polling", quiere usted decir algo así como IMAP IDLE ? Una conexión permanece abierta y no hay ninguna sobrecarga para la construcción de la conexión en sí una y otra vez. Como se ha dicho, otra posible solución es la cabecera HEAD de una petición HTTP (olvidó él, gracias!).

Mira en este tutorial para el básico de conexiones HTTP en J2ME.

Empujar datos a una aplicación / dispositivo sin el apoyo de empuje (como un Blackberry) no es posible.

El es el método que proporciona HTTP si desea comprobar si una página ha cambiado o no, es utilizado por los navegadores y servidores proxy para comprobar si una página ha sido actualizada o no sin consumir mucho ancho de banda.

En términos de HTTP, la petición HEAD es lo mismo que conseguir sin el cuerpo, supongo que esto sería sólo un par de cientos de bytes en la mayoría de los cuales se ve aceptable si sus encuestas no son muy frecuentes.

La mejor manera de hacer esto es utilizar conexión de socket. Muchas aplicaciones como Gmail los utilizan.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top