ES2370050T3 - Sistema y procedimiento para llevar a cabo la comunicación entre un servidor y un equipo de usuario. - Google Patents

Abstract

Sistema de comunicación para llevar a cabo una comunicación entre un servidor (105) y al menos un equipo (101) de usuario, estando el sistema de comunicación configurado para permitir una conexión de transmisión por flujo entre el servidor (105) y el equipo (101) de usuario, conteniendo el servidor (105) un medio para recibir solicitudes del equipo (101) de usuario, conteniendo las solicitudes demandas de transferencia de objetos, y estando el servidor adaptado para almacenar los objetos en una cola, caracterizado porque el sistema de comunicación contiene un medio para entregar directamente los objetos al equipo (101) de usuario a través de la conexión de transmisión por flujo anteriormente abierta entre el servidor (105) y el equipo (101) de usuario.

Description

Sistema y procedimiento para llevar a cabo la comunicación entre un servidor y un equipo de usuario

Campo de la invención

La invención se refiere a un sistema de comunicación para llevar a cabo una comunicación entre un servidor y al menos un equipo de usuario.

Antecedentes de la invención

Se conoce el aumento de la funcionalidad de equipos de usuarios, especialmente equipos móviles de usuario como, por ejemplo, teléfonos móviles, para descargar contenido, especialmente contenido asociado (p. ej., una página en html con imágenes, o una secuencia de imágenes desde una carpeta álbum).

Esto ocurre, por ejemplo, mediante una plataforma para sistemas de comunicación móvil de tercera generación, según se describe en la especificación TS 23.057 Versión 6.2.0 (Septiembre de 2003) del Proyecto de Colaboración de 3ª Generación (3GPP).

La descarga de contenido ocurre, por ejemplo, según una comunicación entre el equipo de usuario y un servidor de contenido, que se base, por ejemplo, en el Protocolo de Transferencia de Hipertexto (HTTP). Según esta comunicación, el equipo de usuario envía una solicitud (solicitud-HTTP) de una aplicación deseada al servidor de contenido.

Según información contenida en una cabecera de la solicitud (cabecera-solicitud), el servidor de contenido selecciona un contenido para transferir al equipo de usuario.

Las redes inalámbricas móviles tienen mayores latencias que las redes fijas, debido a las leyes de la física.

Esta latencia afecta al protocolo HTTP estándar, que consiste en Respuestas-a-Solicitudes individuales y, específicamente, cuando las respuestas sólo incluyen pequeños trozos de contenido.

El protocolo HTTP tiene sobregasto redundante, tanto en las solicitudes como en las correspondientes respuestas. P. ej., cuando se solicita una imagen pequeña, tanto la solicitud en sí como la cantidad de cabeceras en la respuesta son usualmente más grandes que el tamaño de una tal imagen. Si bien la cantidad de cabeceras en la respuesta puede controlarse relativamente y reducirse a un mínimo estricto, las cabeceras desde el dispositivo se envían en todas y cada una de las respuestas, y la mayoría de esas cabeceras son totalmente redundantes, ya que nunca cambian, p. ej., “Agente-Usuario” y la cabecera de “Aceptar”, con una lista (enorme a veces) de tipos de contenido con soporte.

La Pasarela (GW) introduce latencia adicional en la solicitud y la respuesta, porque se comporta como un agente de copia y remisión, y sólo pasa la solicitud (o devuelve la respuesta) cuando se recibe en ella el contenido entero.

El documento WO 2008 / 033598 A1 revela un procedimiento y un aparato para seleccionar y entregar contenido personalizado de medios electrónicos no solicitado. El contenido de medios electrónicos se selecciona automáticamente para un usuario en base a criterios predeterminados, y el contenido se descarga automáticamente, al menos parcialmente, a un dispositivo de usuario antes de una solicitud del contenido proveniente de los usuarios. El contenido de medios electrónicos se selecciona específicamente en base a una ubicación geográfica actual o futura del usuario, el comportamiento anterior del usuario (p. ej., búsquedas históricas por Internet) y / o una característica demográfica o sicográfica del usuario.

Resumen de la invención

Es un objeto de la presente invención permitir un empleo más eficiente del ancho de banda en una comunicación entre un servidor y al menos un equipo de usuario. Según la invención, este objeto es logrado por un sistema de comunicación según la reivindicación 1, y por un procedimiento según la reivindicación 7.

La invención propone un sistema de comunicación para llevar a cabo una comunicación entre un servidor y al menos un equipo de usuario y, más específicamente, un sistema de comunicación capaz de llevar a cabo una pluralidad de comunicaciones entre el servidor y varios equipos de usuario.

La invención usa la idea para aumentar la eficiencia del ancho de banda en una red, reduciendo la latencia de los mecanismos de solicitud / respuesta.

La invención permite manipular solicitudes que están destinadas para ser realizadas en un segundo plano. Esto implica que las solicitudes pueden manipularse incluso si el usuario realiza distintas tareas.

Según una realización preferida de la invención, un dispositivo y / o aplicación efectúa las solicitudes asíncronamente

50 E08009266

19-10-2011

(sincronizando el contenido entre el dispositivo y el servidor), en lugar de la típica secuencia de solicitud del explorador / respuesta / página de representación.

De esta manera, el servidor puede entregar contenido relevante no solicitado para ese momento (p. ej., fotos que están mostrándose al usuario) así como contenido previo a la entrega no solicitada que podría ser relevante más tarde (p. ej., detalles de fotos, información de contacto, etc.) de la manera más eficiente, lo que significa entregar una secuencia no solicitada de trozos asociados de contenido sin ninguna interrupción en el medio.

Además, la invención permite una transmisión por flujo de contenido de multimedios. La gestión de solicitudes se optimiza.

La invención habilita un procedimiento con una comunicación en la cual el servidor siempre envía información al equipo de usuario. Esto hace uso del ancho de banda completo. Preferiblemente, el término “transferencia por flujo” se usa en el contexto de una única conexión usada para entregar un flujo no solicitado de trozos de contenido sin interrupciones entre ellos, optimizando la lista de contenido a enviar en secuencia. Esto es comparable a transmitir las solicitudes en paralelo, lo que algunos dispositivos ya hacen mediante el explorador, donde la probabilidad de intentar hacer que las solicitudes y respuestas compitan con el ancho de banda disponible podría proporcionar una eficacia de entre casi el 100% y un valor bajo en caso de que se respondan todas.

La invención presente puede funcionar con tecnologías conocidas, así como con tecnologías futuras.

Es preferible entregar directamente el contenido no solicitado; permaneciendo el canal siempre abierto. Otro contenido puede transferirse.

Según la invención, el contenido se transfiere en objetos distintos. Los objetos según la invención son entidades de datos que pueden adaptarse a varios fines. Ejemplos de estos objetos son imágenes, ficheros de datos, módulos de software e incluso programas ejecutables de ordenador.

Es un objetivo de una mejora adicional de la invención aumentar la eficacia del ancho de banda en la red móvil, reduciendo la latencia del mecanismo existente de solicitud / respuesta del HTTP. El usuario no lo percibirá, principalmente porque estas solicitudes están concebidas para efectuarse en el segundo plano (p. ej., sincronizando datos mientras el usuario está mirando a alguna otra cosa).

La invención permite reducir los periodos muertos donde no se está usando el ancho de banda completo.

La invención propone un sistema de comunicación para llevar a cabo una comunicación entre un servidor y al menos un equipo de usuario. Además, la invención comprende un procedimiento de comunicación entre el servidor y el equipo de usuario.

Según una realización de la invención, el servidor contiene un medio para recibir solicitudes del equipo de usuario, en donde al menos algunas solicitudes contienen una demanda para transferir un objeto, el sistema de comunicación contiene adicionalmente un generador de colas, el sistema de comunicación permite adicionalmente una conexión de transmisión por flujo entre el servidor y el equipo de usuario, y el sistema de comunicación contiene un medio para entregar los objetos no solicitados al equipo de usuario.

Según una realización preferida del sistema de comunicación, el procedimiento y el servidor, el servidor contiene el medio para entregar los objetos no solicitados al equipo de usuario.

Según una realización de la invención, el sistema de comunicación, un nodo lógico, el servidor y / o el equipo móvil de usuario contienen un medio para determinar el ancho de banda disponible para la conexión de transmisión por flujo.

Según una realización preferida de la invención, el equipo de usuario contiene un medio para abrir la conexión de transmisión por flujo al servidor.

La invención contiene varios medios para abrir la conexión de transmisión por flujo. Por ejemplo, el equipo de usuario (cliente) abre la conexión de transmisión por flujo al servidor mediante HTTPS o mediante una conexión directa.

Según una realización preferida del sistema de comunicación, el procedimiento y el servidor, el sistema de comunicación contiene un selector que es capaz de seleccionar objetos que pueden transferirse desde el servidor al equipo de usuario, en donde el selector está equipado en forma tal que el ancho de banda disponible determinado se use como un parámetro en el proceso de selección.

Según una realización preferida del sistema de comunicación, el procedimiento, el servidor y el equipo de usuario envían solicitudes al servidor, en donde al menos algunas solicitudes contienen una demanda para transferir un objeto, el servidor recibe las solicitudes, el servidor provee, los objetos se almacenan en una cola y los objetos se entregan directamente al equipo de usuario en una conexión de transmisión por flujo.

45 E08009266

19-10-2011

Según una realización preferida de la invención, se habilita un flujo constante de objetos desde el servidor al equipo de usuario.

Según una mejora adicional de la invención, el flujo de objetos se optimiza de modo tal que se use un máximo del ancho de banda disponible.

Según una realización preferida del sistema de comunicación, el procedimiento, el servidor y el equipo de usuario, se evalúa si los objetos en la cola son suficientes a fin de mantener abierta la conexión de transmisión por flujo. Se prefiere especialmente que se transfieran las partes de mantenimiento en vigencia al equipo de usuario, a fin de mantener viva la conexión de transmisión por flujo.

Preferiblemente, las partes recibidas mediante la conexión de transmisión por flujo están concebidas para ponerse en un almacén, o memoria caché, local, para ser reutilizadas más tarde por la aplicación, cuando se necesiten para mostrarse en pantalla.

Una parte de mantenimiento de vigencia puede ser cualquier trozo de contenido con al menos un octeto, y con una falsa ubicación de contenido que no corresponde a ningún contenido real y que se almacena en la memoria caché pero no es usada nunca por la aplicación (p. ej., ubicación = /mantenimiento-de-vigencia, tipo = texto / plano, datos = “pedal”).

Una utilización de las partes de mantenimiento de vigencia puede depender de la topología de la red conectada, p. ej., la existencia de agentes o pasarelas del Protocolo de Aplicaciones Inalámbricas, de encaminadores de Traducciones de Direcciones de Red TCP/IP, etc.

El empleo de las partes de mantenimiento de vigencia, así como la periodicidad de los paquetes, pueden tanto preconfigurarse para una red específica, cuando se conoce la red, como ser calculados dinámicamente por el servidor comprobando si la conexión se desconecta alguna vez, y por cuánto tiempo.

Por ejemplo, si el servidor intenta enviar una parte a una conexión establecida y el envío fracasa, el servidor comprueba cuándo se envió con éxito la última parte y se señala a sí mismo que para esa conexión, o dirección de IP,

o gama de direcciones de IP, se necesita un elemento de mantenimiento de vigencia, y que la periodicidad es algunos segundos menor que el periodo entre la parte exitosa y la parte fracasada (idealmente redondeada a minutos o segundos menos algunos segundos, por ejemplo, aproximadamente 30 segundos, que es la configuración usual de caída de conexión en tales redes). Si esta conexión se cae nuevamente, un periodo más pequeño es usado por el servidor.

Según una realización preferida de la invención, el equipo de usuario está configurado para recibir objetos transferidos desde un servidor según una de las reivindicaciones precedentes y para extraer objetos transmitidos desde el flujo de datos.

La invención comprende adicionalmente un servidor que es capaz de interactuar en el sistema de comunicación. El servidor contiene un medio para recibir solicitudes de al menos un equipo de usuario, en donde al menos algunas solicitudes contienen una demanda para transferir un objeto, y el servidor es capaz de interactuar con medios para habilitar una conexión de transmisión por flujo entre el servidor y el equipo de usuario.

Según una realización de la invención, un procedimiento de transmisión por flujo permite la transmisión por flujo de múltiples ficheros de contenido a la vez, sin intentar reconectar cada fichero de contenido con un terminal portátil; luego, los múltiples ficheros se transmiten al terminal portátil desde el servidor de transmisión por flujo, en donde al menos dos objetos se transmiten por flujo al equipo de usuario.

La invención incluye distintas maneras para implementar el protocolo de transmisión por flujo.

Más adelante se describen tres soluciones que son especialmente preferidas.

Un objeto de estas soluciones es implementar el protocolo de transmisión por flujo.

Una solución incluye un procedimiento de una conexión de cuenca directa, omitiendo la pila del HTTP.

La realización preferida de esta solución implicaría reimplementar la pila del HTTP en un cliente de Java.

Una realización de la invención incluye una conexión directa de HTTP entre el dispositivo y el servidor, sin ningún agente, o pasarela del Protocolo de Aplicaciones Inalámbricas, en el medio.

El tercer procedimiento propone usar HTTPS sobre la Pasarela del Protocolo de Aplicaciones Inalámbricas.

El tercer procedimiento es ventajoso, porque el HTTP sobre la Pasarela del Protocolo de Aplicaciones Inalámbricas, o

45 E08009266

19-10-2011

el Agente del HTTP, se comporta como un elemento de almacenamiento y remisión, y sólo devuelve la respuesta al dispositivo cuando la conexión entre el agente y el servidor se termina. Usando el HTTPS, el agente se comporta como un sencillo encaminador de TCP / IP y pasa todo el tráfico entre el dispositivo al servidor, a través de dicho agente, sin ninguna funcionalidad de almacenamiento y remisión del HTTP.

Una realización de la invención propone una determinación de una secuencia de objetos a transferir desde el servidor al equipo de usuario.

Además, la invención propone poner estos objetos según una cierta secuencia en la cola.

Esta realización implica la idea de que las solicitudes enviadas desde el equipo de usuario (un cliente) al servidor se evalúan y de que -en base a esta evaluación -se seleccionan los objetos referidos a las solicitudes.

Preferiblemente, esta selección ocurre con respecto al ancho de banda disponible.

Una realización adicional de la invención incluye una configuración del equipo de usuario y / o el servidor, a fin de evaluar prioridades para la selección.

Además, una realización preferida de la invención propone una configuración del servidor o del equipo de usuario para evaluar prioridades para la secuencia de objetos a incluir en la cola.

Según una implementación de la invención, el servidor está configurado a fin de evaluar prioridades para enviar directamente los objetos al equipo de usuario.

En una realización de la presente invención, se evalúa un suceso a fin de iniciar una transferencia de un objeto desde la cola al equipo de usuario.

Un parámetro especialmente adecuado para la secuencia de objetos a meter en cola y / o transferir es la información acerca del ancho de banda disponible para la transferencia de los objetos.

Esta realización tiene la ventaja de que se aumenta adicionalmente la eficacia del empleo del ancho de banda.

La invención incluye una gran variedad de relaciones entre el tamaño de los objetos y la colocación en cola y / o una decisión acerca de una secuencia de estos objetos.

La decisión acerca de la secuencia realizada por la aplicación en el dispositivo depende de lo que se está mostrando en pantalla.

Por ejemplo, si la aplicación está mostrando una lista de fotografías, el dispositivo solicita al servidor enviar ‘x’ fotografías desde el álbum ‘y’.

Si el usuario cambia la pantalla por algunas otras páginas donde no se estén mostrando las fotografías, sino una lista de personas, el dispositivo informará al servidor que envíe una lista de avatares de contacto, con un indicador que establece que estas partes son ahora más importantes que las fotografías solicitadas antes. Si la primera solicitud produjo 10 fotografías y sólo se devolvieron 5, el servidor no retendrá las 5 fotografías restantes en la cola y comenzará a entregar las nuevas piezas de avatares antes de que esas 5 fotografías sean devueltas.

Estos aspectos precitados, y otros aspectos y ventajas de la invención, serán evidentes a partir de, y se aclararán con referencia a, las realizaciones de la invención descritas a continuación en el presente documento.

Breve descripción de los dibujos

Se hará referencia a realizaciones preferidas de la invención, a modo de ejemplo, a los dibujos adjuntos.

Fig. 1: un panorama esquemático de un sistema de comunicación, en el cual un equipo móvil de usuario se conecta a través de una red con un servidor, y

Fig. 2: una representación esquemática de procesos de solicitud, respuesta y gestión de datos según una realización preferida de la invención.

Descripción detallada de las realizaciones

La descripción de las realizaciones muestra implementaciones de una transmisión por flujo de múltiples partes, que consiste en un procedimiento para optimizar la entrega de contenido desde una plataforma servidora a un dispositivo móvil, conectado mediante una red inalámbrica, que aspira a mejorar la entrega de múltiples contenidos pequeños sobre líneas de alta latencia, manteniendo a la vez la compatibilidad con topologías comunes de redes de Compañías Operadoras (p. ej., Redes Privadas Adaptables de explorador por omisión y Pasarelas del Protocolo de Aplicaciones

45 E08009266

19-10-2011

Inalámbricas), y a equilibrar los estándares existentes (HTTP y multipartes / mixtos).

La Fig. 1 muestra una representación esquemática de un sistema de comunicación y un equipo móvil de usuario según la invención.

Para los expertos en la técnica queda claro que las funciones descritas son una selección de muchos medios para llevar a cabo la invención e implementarla.

La Fig. 1 muestra en un panorama esquemático un equipo móvil 101 de usuario. El equipo móvil 101 de usuario es, por ejemplo, un teléfono celular móvil. El equipo móvil 101 de usuario está conectado con un servidor 105. Preferiblemente, una conexión interactiva entre el equipo móvil 101 de usuario y el servidor 105 se realiza a través de una red de comunicación. Por ejemplo, la red comprende una red 102 de telecomunicación. La red 102 de telecomunicación vincula el equipo móvil de usuario a través de una interfaz aérea. La interfaz aérea 106 es, por ejemplo, una red de GSM (GSM: Sistema Global para Comunicaciones Móviles) o una red del UMTS (UMTS: Sistema Universal de Telecomunicaciones Móviles). La red 102 de telecomunicación está conectada a través de una pasarela 103 con una red 104 de datos. La red 104 de datos es, por ejemplo, Internet o una intranet. El servidor 105 está conectado con la red 104 de datos.

La información para registrar el equipo de usuario en la red 102 de telecomunicación se almacena en el módulo 109 de identificación de usuario. El módulo de identificación de usuario, por ejemplo, es suministrado por un operador de la red 102 de telecomunicación. El módulo 109 de identificación de usuario es, por ejemplo, una tarjeta de chip que, con respecto a las redes del GSM, se conoce como tarjeta de SIM (SIM: Módulo de Identificación de Abonado).

Con respecto a las redes del UMTS, el módulo 109 de identificación de usuario se llama tarjeta de USIM (USIM: Módulo Universal de Identificación de Abonado). El equipo 101 de usuario, preferiblemente móvil, comprende adicionalmente un procesador 110, que está conectado con el módulo 109 de identificación de usuario.

El equipo 101 de usuario puede comprender elementos adicionales, por ejemplo, un panel de teclas o un teclado 111, una interfaz gráfica 112 de usuario y un almacén 113. Preferiblemente, el almacén 113 comprende áreas de almacenamiento permanentes y no permanentes.

El equipo 101 de usuario contiene preferiblemente una antena 115, que permite físicamente una conexión con la red 102 de telecomunicación por la interfaz aérea 106.

El servidor 105 es, por ejemplo, un servidor de contenido que es operado por un proveedor de contenido. El contenido puede descargarse a través de la red 102, 103, 104 en el equipo 101 de usuario.

El contenido se transfiere como objetos. Ejemplos de estos objetos son todos los tipos de conjuntos de datos, como, por ejemplo, datos de texto, información gráfica tal como fotografías o películas, así como módulos de programa. Los módulos de programa pueden ser ejecutables, especialmente ejecutables en el equipo 101 de usuario o con respecto al equipo 101 de usuario.

El servidor 105 es preferiblemente operado por un proveedor de contenido, que usa el servidor para dejar el contenido disponible.

Preferiblemente, el contenido queda disponible sobre la red 102, 103, 104.

Según una realización preferida, el equipo 101 de usuario puede descargar el contenido del servidor 105 usando la red 102, 103, 104.

Los módulos de programa precitados pueden tener el formato de código de programa para aplicaciones de software. Estas aplicaciones de software son ejecutables por el equipo 101 de usuario, especialmente con una utilización de un entorno de tiempo de ejecución de aplicaciones.

Si se usa el HTTP para llevar a cabo las solicitudes, se genera una demanda para solicitudes de contenido (respectivamente, de objetos con contenido empotrado) del HTTP, con una cabecera de solicitud y un área de datos. El área de datos contiene especialmente contenido (información) específico de la información que se solicita.

La cabecera de la solicitud contiene especialmente información acerca de la configuración del equipo 101 de usuario.

Es preferible que las solicitudes para obtener contenido (objetos) del servidor se refieran a datos de identificación. Los datos de identificación pueden estar contenidos en la cabecera de la solicitud.

Ventajosamente, esta realización usa los estándares del HTTP, esto es, el URL (Localizador Universal de Recursos) en la solicitud, y las cabeceras de Ubicación-de-Contenido o Identificador-de-Contenido en las respuestas.

45 E08009266

19-10-2011

La invención puede implementarse con diversos sistemas de comunicación, equipos de usuario, servidores, redes que los hagan funcionar y con una gran variedad de parámetros operativos.

Estos parámetros pueden adaptarse a fin de permitir una transmisión por flujo de múltiples partes.

La realización de “Transmisión por Flujo de Múltiples Partes” se refiere a evitar los efectos negativos de la latencia de red, alejándose del paradigma de solicitud-respuesta individual, hacia un canal de transmisión por flujo, más un canal de señalización.

El equipo de usuario (cliente) abre una conexión al servidor. El servidor mantiene abierta la conexión usando partes de mantenimiento de vigencia (si se necesitan), y entrega directamente contenido real a través de ese canal. En paralelo, el cliente efectúa una solicitud, usando esta vez una solicitud-respuesta estándar del HTTP, donde el cliente solicita uno o más recursos en la misma solicitud, incluyendo niveles optativos de prioridad para cada recurso, a lo cual el servidor responde con un pequeño acuse de recibo (o rechazo). Luego el servidor recupera los recursos solicitados, los pone en una cola ordenada (mirando al nivel de prioridad) y entrega directamente cada trozo de contenido de vuelta a través del canal de transmisión por flujo abierto previamente.

La parte izquierda de la Fig. 2 muestra un proceso de comunicación según la invención. Los iconos se transfieren según una cierta secuencia, que es distinta a la de los números de icono.

Incluso la solicitud inicial (obtener icono 1 a 5) podría significar una respuesta de los iconos 2, 3, 1, 5, 4, en caso de que la solicitud de esos iconos desde el servidor al almacén de contenido real recupere 2 y 3 antes de 1, 5 y 4.

Una secuencia preferida depende de la disponibilidad del contenido, y puede devolverse fuera de orden (la cabecera de ubicación-de-contenido o de identificador-de-contenido hará referencia a qué es cada parte).

Además, las solicitudes subsecuenciales desde el dispositivo pueden cambiar el orden de la cola y forzar que el contenido de la solicitud más reciente se responda antes que las partes existentes en la cola.

Preferiblemente, el marcado de contenido (lista de fotografías, textos o datos de html) debería transferirse antes de las fotografías efectivas, cuando sea posible, o bien el dispositivo procesará la respuesta de la imagen, pondrá en el almacén local, según una realización preferida de la invención, una interfaz gráfica de usuario, por ejemplo, una pantalla que permanece sin cambios hasta que se recibe el marcado. Esta es una optimización preferida, ya que puede ocurrir que los iconos estén listos para ser entregados y el marcado lleve algún tiempo de proceso, por lo que el tiempo para procesar el marcado en el servidor se usa para transferir ya algunas imágenes al dispositivo.

La transmisión por flujo se basa en el concepto de que el contenido se transfiere al dispositivo y se almacena localmente en memoria caché, de modo que puede ser reutilizado más tarde cuando el usuario acceda a la misma pantalla de la aplicación.

-

Los iconos según la Fig. 2 son sólo ejemplos de objetos según la invención, y los iconos, por ejemplo, pueden ser reemplazados por otros tipos de datos o códigos de programa o, respectivamente, incluso por programas ejecutables.

Esto incluye, por ejemplo, un flujo de pequeños ficheros de vídeo o de anticipo de audio, o puede ser una lista de contactos (basados en estándares vcard, o xml, o texto), donde cada contacto es una parte individual y puede enviarse por separado. Puede transferirse cualquier clase de contenido relevante.

-

Una combinación de distintos tipos de objetos en el posible proceso de transmisión por flujo, por ejemplo, creando una secuencia con una combinación de datos gráficos o datos de programa, es una realización preferida de esta implementación.

El estándar HTTP y el de multipartes-mixtas proporciona cabeceras que definen el tipo de contenido de cada parte (texto, imagen, etc.), la ubicación, o el identificador, del elemento (de modo que el contenido pueda transferirse fuera de orden), e incluso cabeceras gzip, o deflactoras, que señalizan un contenido comprimido.

Como se ha afirmado anteriormente, según una realización preferida de la invención, una Pasarela del Protocolo de Aplicaciones Inalámbricas se comporta como un agente de copia y remisión, y sólo retransmite la respuesta cuando se recibe el contenido entero.

Si se mantiene abierta una conexión de transmisión por flujo, la Pasarela del Protocolo de Aplicaciones Inalámbricas, preferiblemente, no devuelve el contenido al dispositivo.

Existe una pluralidad de soluciones para implementar protocolos de transmisión por flujo en redes adecuadas, especialmente redes de operador común.

50 E08009266

19-10-2011

A continuación se describen tres soluciones especialmente preferidas para implementar el protocolo de transmisión por flujo en redes de operador común (donde “común” significa usar la Red Privada Adaptable de exploración por omisión, que usualmente sólo da acceso a los servidores externos a través de la Pasarela del Protocolo de Aplicaciones Inalámbricas, y sólo mediante agentes de HTTP o HTTPS):

1.

Conectar el servidor dentro de la red del Operador Común y hacer que el terminal hable en HTTP directamente con el servidor. Esto fallará en la mayoría de los casos, como, p. ej., en aplicaciones J2ME de Java, porque, por ejemplo, la configuración de la Pasarela del Protocolo de Aplicaciones Inalámbricas (agente de HTTP) está definida por la plataforma móvil y la aplicación no puede decidir por sí misma no usar la Pasarela del Protocolo de Aplicaciones Inalámbricas para algunas solicitudes específicas. Esto también requeriría cambios en los cortafuegos del Operador Común, para dar acceso directo desde el terminal al servidor, sin atravesar la Pasarela del Protocolo de Aplicaciones Inalámbricas.

2.

Conectar el servidor dentro de la red del Operador Común, y tener una conexión de cuenca directa, omitiendo la pila del HTTP: Esto significaría reimplementar la pila del HTTP en clientes de Java, y tener un puerto no estándar en el servidor. El modelo de seguridad de Java prohíbe las conexiones de HTTP con puertos no estándares (HTTP=80, HTTPS=443) y usa las configuraciones por omisión de la plataforma móvil de la Pasarela del Protocolo de Aplicaciones Inalámbricas. La conexión de cuenca directa tampoco podría disponer totalmente de soporte por parte del dispositivo. Esto también requeriría cambios en los cortafuegos del Operador Común, para dar acceso directo desde el terminal al servidor, sin atravesar la Pasarela del Protocolo de Aplicaciones Inalámbricas.

3.

Usar el HTTPS sobre la Pasarela del Protocolo de Aplicaciones Inalámbricas. El estándar del agente de HTTPS permite una conexión directa entre el cliente y el servidor, usando el agente como un agente sencillo de cuenca, y dejando que el tráfico fluya directamente desde un punto a otro. Esto permite que el protocolo propuesto de “Transmisión por Flujo de Múltiples Partes” funcione en todas las configuraciones comunes de Redes Privadas Adaptables de “exploración” del Operador Común, sin ningún cambio en el Operador Común. La única preocupación podría ser con respecto a los recursos de la Pasarela del Protocolo de Aplicaciones Inalámbricas: si el servicio se usa de manera similar a la exploración normal, y no está (casi) siempre activo, y no es usado por todas las bases de clientes a la vez, la carga sobre la Pasarela del Protocolo de Aplicaciones Inalámbricas sería similar a la de la exploración normal (o incluso menor, debido a la optimización y a la conexión única). Si el servicio tiene una utilización mucho mayor que la exploración normal, la opción 2 debería considerarse con cuidado.

Puede usarse una gran variedad de estándares para llevar a cabo la transmisión por flujo de múltiples partes según la invención.

Una realización preferida de la “Transmisión por Flujo de Múltiples Partes” usa el formato estándar “multipartes-mixtas” (RFC 2046, RFC 2387) para entregar cada trozo de contenido.

La aplicación en el móvil recibe el contenido entrante de la transmisión por flujo de múltiples partes, y procesa cada parte en cuanto se recibe la parte entera.

A continuación se explican las ventajas de la invención actual sobre el estado conocido de la técnica, según un ejemplo de un caso real.

El ejemplo del caso real se basa en una aplicación móvil que muestra una presentación de fotografías cargadas desde la red. El cliente puede recorrer la presentación para ver las próximas fotografías, hasta la última, o retroceder a las fotografías anteriores, hasta la primera.

Supondremos que cada fotografía tiene una resolución similar a la pantalla del dispositivo (para que pueda ampliarse hasta la pantalla entera) y un promedio de 10 KB cada una.

Aplicando una implementación conocida de solicitud-respuesta del HTTP, y suponiendo que ninguna imagen está almacenada aún en memoria caché en el dispositivo, la aplicación haría una única solicitud para cada fotografía.

La máxima velocidad teórica en una red de 3G, para estas fotografías de 10 KB, e ignorando el sobregasto de cabeceras del HTTP, sería de 0,21 segundos para una conexión de 384 KBits, hasta 1,25 segundos para una conexión de 64 Kbits. Las pruebas en la vida real en una red de 3G muestran que el tiempo medio entre crear un objeto del HTTP en Java, realizar la solicitud, dejar que la solicitud llegue al servidor (atravesando la Pasarela del Protocolo de Aplicaciones Inalámbricas), obtener el resultado de vuelta en el dispositivo y procesar la respuesta (sin incluir el procesamiento de la imagen misma en una representación interna de imagen), y para una respuesta de 1 octeto, está entre 0,5 y 1 segundo. Esto significa que, para cada fotografía, cada sucesión de solicitud-respuesta llevaría en promedio alrededor de 1 segundo, suponiendo el mejor caso y redondeando hacia abajo.

Alternativamente, el servidor podría devolver una respuesta de múltiples partes con más de una única fotografía. Devolver todas las fotografías no es factible, ya que la aplicación móvil no recibiría ningún contenido hasta que la

45 E08009266

19-10-2011

Pasarela del Protocolo de Aplicaciones Inalámbricas reciba el paquete entero, haciendo que la experiencia del usuario se convierta en un largo retardo seguido por la exhibición de todas las fotografías.

Podría lograrse un compromiso devolviendo ‘x’ fotografías cada vez, pero aún tendría el retardo de un segundo entre cada solicitud de múltiples partes, y las fotografías se mostrarían al usuario en trozos de ‘x’ fotografías.

Otra alternativa sería efectuar múltiples solicitudes en paralelo, para recuperar múltiples objetos y mezclar los retardos de latencia de una solicitud con la recepción del contenido de otra. Como las temporizaciones provenientes del cliente, la red, y el mismo servidor, no pueden controlarse, esto significa una eficacia aleatoria de entre menos del 100% de todo el ancho de banda disponible (si todas las solicitudes se alinearan secuencialmente) y menos que la del procedimiento estándar de solicitud-respuesta (cuando todas las solicitudes se están efectuando o devolviendo a la vez, podría darse la probabilidad de colisiones de red, retardos de red o reintentos de paquetes). En la práctica, esto sólo funciona para un número bajo de hebras concurrentes, pero no se extiende a más de un número de conexiones de un solo dígito. Como se ha señalado en los párrafos anteriores, los conceptos de implementación que usan el procedimiento estándar de solicitud-respuesta no utilizan totalmente el ancho de banda disponible, debido a las pausas de “latencia” ociosa entre solicitudes. Aunque la latencia disminuye levemente cuando aumenta el ancho de banda disponible, la relación no es directa, y la del ancho de banda con la latencia y con el tiempo tampoco es una relación directa. En otras palabras, con estas alternativas, aumentar el ancho de banda no se refleja proporcionalmente en menos tiempo empleado para obtener el contenido.

La invención presente incluye una pluralidad de implementaciones para realizar un flujo constante de contenido (objetos) desde el servidor al equipo de usuario.

Una realización especialmente preferida de la invención contiene algunas de, la mayoría de, o incluso todas las siguientes etapas:

-

El cliente abre la conexión de “transmisión por flujo” con el servidor, mediante el HTTPS o mediante conexión directa, eludiendo la Pasarela del Protocolo de Aplicaciones Inalámbricas. Esto se lleva a cabo en paralelo con las siguientes tareas, por lo que en la práctica no consume un tiempo significativo.

-

El cliente efectúa una solicitud estándar del HTTP a través de la Pasarela del Protocolo de Aplicaciones Inalámbricas, solicitando las “fotografías 1 a x”. El servidor devuelve una Aceptación. Esto lleva medio segundo, porque la respuesta no es relevante para esta secuencia.

-

El servidor recupera las fotografías solicitadas y las pone en una cola (la latencia en el procesamiento del servidor no es relevante, ya que es la misma que en las soluciones anteriores).

-

El servidor entrega directamente el primer objeto de vuelta al dispositivo, a través de la conexión de transmisión por flujo. Esta primera respuesta lleva 0,2 segundos (a 384 Kbps) o 1,25 segundos (a 64 Kbps) para llegar a la aplicación terminal.

-

El servidor sigue entregando directamente los objetos posteriores a través del conducto, en secuencia continua. La latencia entre la entrega directa de cada objeto por parte del servidor (milisegundos) se refleja en la llegada de los objetos en el terminal.

Esto significa que la primera imagen se recibe después de 0,5 + 0,2 = 0,7 segundos (a 384 Kbps) o 0,5 + 1,25 = 1,75 segundos (a 64 Kbps), y las imágenes posteriores se reciben cada 0,2 o 1,25 segundos. Esto utiliza totalmente el ancho de banda disponible.

Para los expertos en la técnica es claro que la invención abarca un alcance mucho mayor de datos.

Es sumamente preferible adaptar una gama de parámetros y datos, para llevar a cabo los procesos descritos anteriormente, a las características de la red de comunicación, al servidor, al dispositivo y al tipo de comunicación involucrado.

40 E08009266

19-10-2011

Claims (13)

1. REIVINDICACIONES

   1. Sistema de comunicación para llevar a cabo una comunicación entre un servidor (105) y al menos un equipo (101) de usuario, estando el sistema de comunicación configurado para permitir una conexión de transmisión por flujo entre el servidor (105) y el equipo (101) de usuario,

   conteniendo el servidor (105) un medio para recibir solicitudes del equipo (101) de usuario, conteniendo las solicitudes demandas de transferencia de objetos, y estando el servidor adaptado para almacenar los objetos en una cola, caracterizado porque el sistema de comunicación contiene un medio para entregar directamente los objetos al equipo

   (101) de usuario a través de la conexión de transmisión por flujo anteriormente abierta entre el servidor (105) y el equipo (101) de usuario.

2. 2.

   El sistema de comunicación según la reivindicación 1, caracterizado porque el medio para entregar directamente los objetos al equipo (101) de usuario está contenido en el servidor (105).

3. 3.

   El sistema de comunicación según cualquiera de las reivindicaciones precedentes, caracterizado porque contiene un medio para determinar el ancho de banda disponible para la conexión de transmisión por flujo.

4. 4.

   El sistema de comunicación según cualquiera de las reivindicaciones precedentes, caracterizado porque contiene un selector que es capaz de seleccionar objetos que pueden transferirse desde el servidor (105) al equipo (101) de usuario, en el cual el selector está equipado de modo tal que el ancho de banda disponible determinado se use como un parámetro para la selección.

5. 5.

   El sistema de comunicación según cualquiera de las reivindicaciones precedentes, caracterizado porque el servidor está configurado para evaluar prioridades para entregar directamente los objetos al equipo de usuario.

6. 6.

   El sistema de comunicación según cualquiera de las reivindicaciones precedentes, caracterizado porque el equipo

   (101) de usuario contiene un medio para abrir la conexión de transmisión por flujo al servidor (105).
7. 7. Procedimiento para llevar a cabo una comunicación entre un servidor (105) y al menos un equipo (101) de usuario, en el cual

   se habilita una conexión de transmisión por flujo entre el servidor (105) y el equipo (101) de usuario,

   el equipo (101) de usuario envía solicitudes al servidor (105), conteniendo las solicitudes demandas de transferencia de objetos,

   el servidor (105) recibe las solicitudes y almacena los objetos en una cola, caracterizado porque los objetos se entregan directamente al equipo (101) de usuario a través de la conexión de transmisión por flujo anteriormente abierta entre el servidor (105) y el equipo (101) de usuario.

8. 8.

   El procedimiento según la reivindicación 7, caracterizado porque se habilita un flujo constante de objetos desde el servidor (105) al equipo (101) de usuario.

9. 9.

   El procedimiento según la reivindicación 8, caracterizado porque el flujo de objetos se optimiza de modo tal que se use el máximo del ancho de banda disponible.

10. 10.

    El procedimiento según cualquiera de las reivindicaciones 7 a 9, caracterizado porque se evalúa si los objetos en la cola son suficientes a fin de mantener abierta la conexión de transmisión por flujo.

11. 11.

    El procedimiento según cualquiera de las reivindicaciones 7 a 10, caracterizado porque las partes de mantenimiento de vigencia se transfieren al equipo de usuario para mantener viva la conexión de transmisión por flujo.

12. 12.

    El procedimiento según cualquiera de las reivindicaciones 7 a 11, caracterizado porque el servidor evalúa prioridades para entregar directamente los objetos al equipo de usuario.

13. 13.

    El procedimiento según cualquiera de las reivindicaciones 7 a 11, caracterizado porque una solicitud del equipo

    (101) de usuario cambia el orden de la cola de modo tal que el contenido solicitado más recientemente se envíe antes de partes existentes de la cola.

    19-10-2011 E08009266

    19-10-2011