ES2257543T3 - Control de transferencia de objeto en una red de comunicaciones. - Google Patents
Control de transferencia de objeto en una red de comunicaciones.Info
- Publication number
- ES2257543T3 ES2257543T3 ES02727530T ES02727530T ES2257543T3 ES 2257543 T3 ES2257543 T3 ES 2257543T3 ES 02727530 T ES02727530 T ES 02727530T ES 02727530 T ES02727530 T ES 02727530T ES 2257543 T3 ES2257543 T3 ES 2257543T3
- Authority
- ES
- Spain
- Prior art keywords
- component
- objects
- requested
- priority
- attribute
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/564—Enhancement of application control based on intercepted application data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
- H04L67/61—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources taking into account QoS or priority requirements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
- H04L67/62—Establishing a time schedule for servicing the requests
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/563—Data redirection of data network streams
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Information Transfer Between Computers (AREA)
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Polymers With Sulfur, Phosphorus Or Metals In The Main Chain (AREA)
- Communication Control (AREA)
- Small-Scale Networks (AREA)
Abstract
Un método de controlar, en una red (10) de comunicaciones, una transferencia de objeto desde un primer componente (20) a través de un componente intermedio (30) a un segundo componente (40) que está distante del primer componente (20), en el que la transferencia de objeto se basa en una pluralidad de solicitudes de objeto relacionada con objetos a los que se ha hecho referencia en uno o más códigos que se van a procesar mediante el segundo (40) u otro componente de la red (10) de comunicaciones, cuyo componente intermedio realiza las etapas de: - enviar una solicitud (406) de objeto al primer componente (20); - recibir del primer componente (20) el objeto solicitado (408); caracterizado porque el componente intermedio realiza además las etapas de - establecer y/o actualizar una prioridad del objeto solicitado (604), en el que se ha asignado una prioridad inicial al objeto solicitado basándose en un análisis de al menos uno de la solicitud de objeto y del código que se refiere al objeto solicitado; y - dependiendo de la prioridad del objeto solicitado, retardar (618; 404, 410, 412) el objeto solicitado o enviar (612) el objeto solicitado al segundo componente (40).
Description
Control de transferencia de objeto en una red de
comunicaciones.
El invento se refiere en general al campo de las
redes de comunicaciones, y más particularmente a una transferencia
de objeto desde un primer componente de red a través de un
componente intermediario a un segundo componente de red, cuyo
segundo componente de red está distante del primer componente de
red.
La transferencia de información sobre redes de
comunicaciones con módem como la red pública de Internet o las
redes internas se basa en unos protocolos específicos de
transferencia. La World Wide Web (en adelante WWW) por ejemplo,
que constituye un aspecto importante de la Internet, usa el
protocolo de transferencia de hipertexto (en adelante HTTP) para
intercambiar archivos que comprenden imágenes de texto, sonido,
vídeo, y otros contenidos.
Cualquier servidor de WWW contiene, además de los
archivos que puede servir, un componente de HTTP que se ha
diseñado para esperar por solicitudes de HTTP y para gestionarlas
cuando llegan. Un explorador de WWW se puede considerar como un
cliente de HTTP que está configurado para enviar solicitudes de
HTTP a servidores de WWW. Cuando quiera que un usuario del
explorador introduce una solicitud de archivo, bien sea
"abriendo" un archivo de WWW (tecleando en un localizador
uniforme de recursos (en adelante URL)) o bien haciendo "clic"
sobre un vínculo de hipertexto, el explorador acumula una solicitud
correspondiente de HTTP para el archivo y la envía a la dirección
de destino. El componente de HTTP del servidor de destino recibe la
solicitud de HTTP y devuelve el archivo solicitado.
El archivo solicitado se podría constituir
mediante una página de lenguaje de marca de hipertexto (en adelante
HTML) que incluya código de HTML. Cuando el explorador recibe la
página de HTML del servidor y detecta que el código de HTML, que
se puede considerar como un objeto en sí mismo, incluye objetos
adicionales tales como imágenes (de fondo), sonidos, secuencias de
comandos, o tramos de HTML, el explorador emite solicitudes
adicionales de HTTP al servidor con el fin de buscar los objetos
adicionales que estén incluidos en el código HTML. Tras recibir
las solicitudes adicionales de HTTP, el servidor envía al
explorador las respuestas de HTTP incluyendo los objetos
solicitados como imágenes. Como resulta evidente en la Figura 1,
las respuestas de HTTP se envían desde el servidor al explorador
que funciona sobre el cliente en el mismo orden que el explorador
ha emitido las solicitudes de HTTP.
El orden en que cualesquiera objetos adicionales
incluidos en el código de HTML de la página de HTML son
solicitados por el explorador depende usualmente de cómo se haya
escrito la página de HTML. Por ejemplo, un objeto que se haya
incluido en el principio del código de HTML no se presenta en forma
visual necesariamente en la parte superior de la página de HTML
porque características tales como tablas, estratos y tramos
permiten al autor del HTML usar disposiciones generales complejas.
Además, el orden en que un explorador emite solicitudes de HTTP
depende también de algoritmos internos del explorador. Por ejemplo,
algunos exploradores usan una heurística compleja para generar las
solicitudes de HTTP comenzando por solicitar los cuatro primeros
objetos tal como aparecen en el código de HTML de la página.
Después que se han solicitado los cuatro primeros objetos, se
solicitan cada dos objetos comenzando por la parte superior del área
que está visible actualmente al usuario, luego cada cuatro
objetos, y así sucesivamente. Otros exploradores usan un algoritmo
más sencillo que solicita los objetos uno por uno según aparecen en
el código de HTML. De lo anteriormente expuesto, resulta evidente
que usualmente es difícil predecir el orden en que se generan
solicitudes de HTTP para objetos a los que se haya hecho
referencia en un código de HTML.
Más aún, es difícil predecir el orden en que los
objetos solicitados son recibidos por el explorador. Aunque la
norma actual de HTTP (HTTP/1.1) requiere que en cada conexión de
protocolo de control de transferencia (en adelante TCP) las
respuestas de HTTP se envíen desde el servidor al explorador en el
mismo orden que las solicitudes de HTTP son recibidas por el
servidor, el orden en que las respuestas de HTTP son recibidas se
vuelve imprevisible en cuanto se abre más de una conexión al
servidor. Por tanto, la razón es el hecho de que, debido a
condiciones variables de red y a diferentes tiempos de tratamiento
de las solicitudes, algunas conexiones podrían transferir
respuestas de HTTP más deprisa que otras.
El documento US 5987466 describe un método de
explorar la WWW de la Internet y de presentar los elementos de una
página web a un usuario. El explorador de web solicita un HTML
deseado y luego solicita otros elementos de la página basándose en
niveles de prioridad definidos por el usuario. Los elementos se
presentan al usuario en secuencia de prioridad tan pronto como se
reciben.
Se necesita un método y un dispositivo que
habilite una transferencia perfeccionada de objetos desde un primer
componente de red a un segundo componente de red que está distante
del primer componente de red.
\newpage
Esta necesidad se satisface mediante la enseñanza
de las reivindicaciones independientes. En las reivindicaciones
subordinadas se describen realizaciones adicionales preferidas.
De acuerdo con un aspecto del invento, esta
necesidad se satisface mediante un método de controlar, en una red
de comunicaciones, una transferencia de objeto desde un primer
componente por medio de un componente intermedio (de hardware o de
software) a un segundo componente que está distante del primer
componente, en el que la transferencia de objeto se basa en una
pluralidad de solicitudes de objeto a los que se hace referencia en
uno o más códigos que se van a procesar mediante el segundo u otro
componente de la red de comunicaciones; el componente intermedio
realiza las etapas de enviar una solicitud de objeto al primer
componente, recibir del primer componente el objeto solicitado,
caracterizado porque el componente intermedio realiza además las
etapas de establecer y/o actualizar una prioridad del objeto
solicitado, en el que se ha asignado una prioridad inicial al
objeto solicitado basándose en un análisis de al menos uno de la
solicitud de objeto y del código que se refiere al objeto
solicitado, y, con independencia de la prioridad del objeto
solicitado, retardar el objeto solicitado o enviar el objeto
solicitado al segundo componente. Un objeto podría comprender en sí
mismo partes de código referentes a uno o más objetos adicionales.
Además, un código podría comprender por sí mismo un objeto (por
ejemplo, solicitado previamente).
Mediante el retardo intencionado de la
transferencia de un objeto basándose en una prioridad asignada, se
mejora la transferencia global de objetos desde un punto de vista
del usuario (incluso si no se ha disminuido la cantidad total de
objetos a transferir), porque los objetos importantes se
transfieren con carácter preferencial. Además, mediante la
implementación de esquemas apropiados de asignación de prioridad se
hace más previsible la transferencia de objetos desde el primer
componente de red al segundo componente de red. Por ejemplo, a los
objetos que tengan una significación mayor para el usuario se les
puede asignar una prioridad más alta y de ese modo se podrían
transmitir preferencialmente al segundo componente. Por el
contrario, los objetos que tengan una significación menor se
podrían retardar. En el caso extremo, un objeto que tuviese poca
significación se podría retardar hasta un grado tal que no se
transmitiese en absoluto al segundo componente. Esto permite
controlar el orden en que los objetos son recibidos por el segundo
componente.
La asignación de prioridades absolutas o
relativas a los objetos (o a clases de objetos) se podría realizar
de un modo dinámico. Una vez que se ha asignado inicialmente una
prioridad, esta prioridad se puede establecer con respecto a
valores absolutos específicos como umbrales o con respecto a
prioridades de otros objetos. Basándose en el establecimiento, se
puede decidir si se va a retardar o no un objeto. Antes del
establecimiento, se podría evaluar de nuevo una prioridad asignada
inicialmente a un objeto con el fin de determinar si la prioridad
inicial tiene que actualizarse.
El componente intermedio se podría operar para
reordenar objetos recibidos del primer componente. De ese modo, el
retardo de los objetos se realiza preferiblemente de tal manera que
el orden en que el componente intermedio recibe los objetos del
primer componente difiera del orden en que los objetos se
transmiten al segundo componente. La reordenación se podría basar
en las prioridades de los objetos a transferir. Durante la
reordenación, podría surgir la situación en la que, debido al
retardo de algunos objetos, se acelerase realmente la transferencia
de otros objetos.
La solicitud de objeto que se ha enviado al
primer componente podría ser generada por el componente intermedio.
Cuando el objeto solicitado es recibido por el componente
intermedio, éste lo "impulsa" al segundo componente, sin
haber recibido una solicitud explícita de objeto del segundo
componente. Alternativamente, la solicitud de objeto podría ser
generada por el segundo componente y enviarse al componente
intermedio. Tras la recepción de la solicitud de objeto del segundo
componente, se podría procesar por el componente intermedio y
enviarse al primer componente.
Cuando el componente intermedio recibe del primer
componente el objeto solicitado, el objeto recibido podría o bien
retardarse o bien enviarse directamente al segundo componente.
Existen diversas posibilidades en la forma en que se podría
retardar el objeto solicitado que es recibido por el componente
intermedio. El retardo del objeto solicitado puede incluir, por
ejemplo, al menos una de las operaciones de dar instrucciones al
segundo componente para que repita la solicitud de objeto, suspender
una conexión al segundo componente de red por medio del cual se va
a enviar el objeto solicitado, e informar al segundo componente de
que el objeto solicitado se enviará automáticamente (por ejemplo,
sin ninguna solicitud adicional de objeto del segundo componente)
al segundo componente en un instante posterior.
Si el retardo del objeto solicitado incluye dar
instrucciones al segundo componente de repetir la solicitud de
objeto, el componente intermedio podría realizar las etapas de
asignar un atributo específico al objeto a retardar, informar del
atributo al segundo componente, recibir una referencia al atributo
(por ejemplo, el propio atributo o una referencia no ambigua
obtenida del atributo) del segundo componente y, después de
recibir la referencia al atributo, enviar el objeto retardado al
segundo componente o retardar más el objeto retardado. La decisión
de si un objeto retardado tiene que enviarse al segundo componente
o retardarse adicionalmente se podría basar en la prioridad
relativa recientemente establecida del objeto solicitado
repetidamente.
El atributo se puede considerar como un
denominador común que permite que el componente intermedio y el
segundo componente decidan sobre la transferencia del objeto al que
se ha asignado el atributo. Usualmente, la forma del atributo
depende de las características del protocolo de transferencia que
se haya usado para la transferencia del objeto. Por ejemplo, en el
caso del HTTP, el atributo podría estar constituido por un URL
virtual creado por el componente intermedio. Debe hacerse notar que
el plan de retardo basado en un atributo de dar instrucciones al
segundo componente para repetir la solicitud de objeto se puede usar
generalmente para retardar objetos, y no requiere necesariamente
que se hayan asignado prioridades a los objetos a transferir.
En el esquema de retardo basado en la asignación
de un atributo, el objeto se podría enviar desde el componente
intermedio al segundo componente en respuesta a una solicitud de
objeto recibida del segundo componente o de acuerdo con un plan de
impulsión, es decir, independientemente de dicha solicitud de
objeto desde el segundo componente. Si el esquema de retardo se
basa en una solicitud de objeto recibida del segundo componente,
el segundo componente podría ser informado sobre el atributo en
contexto con una instrucción para repetir la solicitud de objeto.
En tal caso, la referencia al atributo podría ser recibida por el
componente intermedio en contexto con una solicitud repetida de
objeto procedente del segundo componente.
Los objetos a transferir al segundo componente se
pueden transmitir al segundo componente por medio de una sola
conexión o mediante una pluralidad de conexiones entre el componente
intermedio y el segundo componente. En el caso de las múltiples
conexiones, las seleccionadas de las conexiones al segundo
componente se podrían suspender, dependiendo de las prioridades
(inicial o actualizada) de los objetos solicitados que se van a
enviar por medio de las seleccionadas de las conexiones al segundo
componente. Así, el componente intermedio podría suspender una o
más conexiones, de tal manera que los objetos que tengan una
prioridad alta puedan hacer uso del ancho de banda adicional que se
libera en el vínculo entre el componente intermedio y el segundo
componente. Con el fin de no desperdiciar el ancho de banda
disponible, el componente intermedio se configura preferiblemente
de tal manera que asegure que un vínculo formado por una o más
conexiones se usa totalmente antes de suspender una o más
conexiones del mismo.
Existen varias técnicas para suspender una
conexión. Por ejemplo, se podría bloquear la transmisión sobre la
conexión durante un período de tiempo específico mientras se deja la
conexión como tal (estado intermedio = abierta). Alternativamente,
la conexión se podría cerrar (estado intermedio = cerrado) mientras
se guarda el estado de la conexión. En tal caso, la conexión se
podría volver a abrir en un instante posterior en el mismo estado
en el que se ha cerrado. De acuerdo con una tercera posibilidad, la
conexión se podría cerrar por completo sin guardar ninguna
información sobre el estado de la conexión. En cualquier caso, se
puede informar al segundo componente que el objeto o los objetos
que se van a transmitir a través de la conexión cerrada se
enviarán posteriormente, bien en respuesta a o independientemente de
una solicitud de objeto (repetida).
En lugar de o además de suspender conexiones
individuales, la transferencia de objeto se podría retardar también
mediante un ajuste basado en la prioridad de la velocidad de
transferencia. En este sentido, se podría asignar dinámicamente
una participación específica de posibilidades de tratamiento a cada
objeto o a cada conexión. En el caso de conexiones múltiples, todas
las conexiones o al menos algunas conexiones obtienen una
participación del tiempo de unidad central de tratamiento (en
adelante CPU), es decir, una participación en el ancho de banda de
red. La participación de las posibilidades de tratamiento asignada a
una conexión específica se podría cambiar (por ejemplo
disminuyéndola constantemente) mientras uno o más objetos son
transferidos por medio de la conexión respectiva.
Se ha mencionado anteriormente que la
transferencia de objeto se basa en una pluralidad de solicitudes de
objeto relacionada con objetos a los que se ha hecho referencia en
uno o más códigos. De acuerdo con una primera variante del
invento, se dispone fácilmente de un código para al menos uno del
segundo componente y del componente intermedio. De acuerdo con una
segunda variante del invento, el código tiene todavía que cargarse
por uno cualquiera del segundo componente y del componente
intermedio. En éste último caso, el componente intermedio podría
enviar una solicitud de código que se ha generado por el segundo
componente o por el componente intermedio al primer componente o a
un tercer componente que sea diferente del primer componente.
Cuando se recibe del primer componente o del tercer componente el
código solicitado, podría ser analizado por el componente
intermedio con respecto a referencias a objetos comprendidos dentro
del código. Entonces, se podrían establecer cualesquiera
referencias a objetos contenidos en el código con el fin de asignar
prioridades (iniciales) a los objetos a los que se haya hecho
referencia en el código recibido. El código recibido del primer o
del tercer componente se podría enviar eventualmente por el
componente intermedio al segundo componente.
Tras recibir una respuesta del primer componente,
el objeto solicitado contenido en la respuesta se podría evaluar
con respecto a la prioridad del objeto recibido. Por ejemplo, en ese
sentido se podrían analizar al menos uno del tamaño del objeto,
contenido del objeto y un encabezamiento de la respuesta. Luego, se
puede determinar si tiene que actualizarse o no una prioridad
inicial de un objeto recibido.
Preferiblemente, al menos alguna información
sobre cada objeto o cada clase de objeto se guarda, por ejemplo,
mediante el componente intermedio. La información guardada podría
comprender información de prioridad para objetos individuales o
clases de objetos, en la forma de una lista de prioridades. Esta
lista de prioridades se podría establecer en repetidas ocasiones.
Este establecimiento se podría relacionar al menos con una
operación de actualizar la información de prioridad y de suprimir
objetos o clases de objetos de la lista de prioridades.
El invento se podría realizar como una solución
de hardware o como una solución de software. En el caso de una
solución de hardware, el invento se podría realizar en la forma de
un producto de programa de ordenador que comprenda partes de
código de programa para llevar a cabo las etapas individuales del
invento. El producto de programa de ordenador se podría guardar en
un medio de almacenamiento legible por ordenador.
De acuerdo con una realización preferida del
invento, el componente intermedio se implementa como un componente
proxy (filtro) en la forma de una parte de software que se ejecuta
sobre el primero o el segundo componente de la red de
comunicaciones. Si el invento se va a implementar como una solución
de hardware, el componente intermedio podría estar constituido por
una parte separada de hardware como un servidor proxy dispuesto
entre los componentes primero y segundo en la red de
comunicaciones. El componente intermedio podría incluir una o más
interfaces de comunicación apropiadamente configuradas para
comunicar con al menos el primero y el segundo componente de la
red de comunicaciones, así como por una unidad para realizar el
tratamiento en contexto con el retardo de objetos.
En la red de comunicaciones existe un primer
vínculo entre el componente intermedio y el primer componente y un
segundo vínculo entre el componente intermedio y el segundo
componente. Preferiblemente, el primer vínculo y el segundo
vínculo tienen diferentes tasas de transferencia. Por ejemplo, se
podría proveer un vínculo rápido entre el componente intermedio y
el primer componente, y un vínculo comparativamente más lento entre
el componente intermedio y el segundo componente. Esta situación se
presenta usualmente cuando el primer componente es un servidor de
red, el segundo componente es un cliente de red y el componente
intermedio está situado en las proximidades de (en cuanto a
vínculos de red) o en el servidor de red. No obstante, el
componente intermedio podría también estar situado muy cerca (en
cuanto a vínculos de red) o en el cliente de red. En tal caso, el
vínculo entre el componente intermedio y el segundo componente (el
cliente de red) tiene una capacidad mucho mayor y un estado
latente mucho menor que el vínculo entre el componente intermedio y
el primer componente (el servidor de red).
Debe hacerse notar que el invento no está
restringido al caso en que el primer componente actúa como un
servidor de red y el segundo componente actúa como un cliente de
red. En particular, el componente intermedio se podría usar
también para mejorar la transferencia de objetos entre dos clientes
de red o dos servidores de red.
De acuerdo con una realización especialmente
preferida del invento, el componente intermedio es parte de una
red de comunicaciones inalámbricas como una red celular GSM, GPRS,
etc. En dicha red, el segundo componente podría estar constituido
por un terminal móvil.
Los aspectos y ventajas adicionales del invento
resultarán evidentes tras la lectura de la siguiente descripción
detallada de realizaciones preferidas del invento y con referencia a
los dibujos, en los que:
La Figura 1 es un diagrama esquemático que
ilustra una transferencia de objeto entre un servidor de red y un
cliente de red de acuerdo con el HTTP;
La Figura 2 es un diagrama de bloques de un
sistema de red que comprende un componente intermedio en la forma
de un servidor proxy de HTTP de acuerdo con el invento;
La Figura 3 es un diagrama de bloques del
servidor proxy de HTTP de la Figura 2;
La Figura 4 es un diagrama esquemático que
representa un retardo de objeto basado en redirección en el sistema
de red dibujado en la Figura 2;
La Figura 5 es un diagrama de flujo que refleja
las etapas que preceden a un retardo de objeto;
La Figura 6 es un diagrama de flujo que presenta
las decisiones implicadas en una transferencia de objeto de
acuerdo con el invento; y
La Figura 7 es un diagrama de bloques que
representa un componente proxy de acuerdo con el invento situado
en un cliente de red.
Aunque el presente invento se puede llevar a la
práctica en cualquier red de comunicaciones en la que se realice
una transferencia de objeto basada en solicitudes a través de un
componente intermedio, la descripción que sigue de realizaciones
preferidas se expone a título de ejemplo con respecto a la
transferencia de código HTML de acuerdo con el protocolo HTTP sobre
la WWW. En principio, se podrían usar también protocolos de
transferencia diferentes del HTTP, como el protocolo de transporte
inalámbrico WAP o algunos mecanismos de llamada de procedimiento
distante (en adelante RPC), y códigos diferentes del HTML, por
ejemplo el lenguaje WAP (en adelante WML) o cualesquiera
derivaciones del lenguaje extensible (en adelante XML). Además,
aunque la descripción siguiente concierne principalmente a una
transferencia de objeto de un servidor a un cliente, la
transferencia de objeto se podría realizar también entre
cualesquiera de dos o más componentes de red.
En la Figura 2 se ha representado un diagrama de
bloques de un sistema de red 10 de acuerdo con el invento. Como
resulta evidente a partir de esta Figura, el sistema 10 de red
comprende un primer componente en la forma de un servidor 20, un
componente intermedio en la forma de un servidor proxy 30 de HTTP y
un segundo componente en la forma de un cliente 40. El servidor
proxy 30 está dispuesto en el sistema 10 de red de tal manera que
tiene un vínculo rápido 12 hacia el servidor 20 y un vínculo 14
comparativamente más lento hacia el cliente 40. Cada vínculo 12,
14 está constituido por una pluralidad de conexiones de protocolo
de control de transmisión (en adelante TCP) 50. Cada conexión 50 de
TCP está configurada para permitir la transferencia de las
solicitudes de HTTP y las respuestas de HTTP entre el servidor 20 y
el cliente 40.
El servidor proxy 30 realiza algunas funciones
tradicionales de filtración tales como acumular y filtrar objetos.
Adicionalmente, el servidor proxy 30 está configurado para retardar
artificialmente un objeto que se recibe del servidor 20 y que tiene
que enviarse al cliente 40. Esto se hace mediante el uso de una
combinación de suspensión temporal de transferencia de datos en
algunas conexiones 50 y de mensajes de redirección de HTTP que
fuerzan a un explorador que funciona sobre el cliente 40 a repetir
un objeto solicitado después de un período determinado de tiempo.
Mediante el uso de estos mecanismos, el servidor proxy 30 reordena
las respuestas de HTTP recibidas del servidor 20 de tal manera que
los objetos que tengan una prioridad mayor se descarguen primero
al cliente 40. Para este fin, el servidor proxy 20 asigna
dinámicamente prioridades a los objetos que se van a enviar al
cliente 40. Con el fin de asegurar que el retardo de los objetos
menos importantes no dé lugar a que el vínculo 14 entre el servidor
proxy 30 y el cliente 40 llegue a trabajar en vacío, el servidor
proxy 30 vigila continuamente o al menos repetidamente el tráfico en
este vínculo 14.
En la Figura 3 se ha representado con más detalle
la construcción del servidor proxy 30. Como se puede ver
evidentemente en la Figura 3, el servidor proxy 20 comprende una
interfaz 32 de comunicaciones acoplada entre el primer vínculo 12
al servidor 20 y el segundo vínculo al cliente 40. La interfaz 32
de comunicaciones está configurada de tal manera que permite el
envío de solicitudes de objeto para finalizar la recepción de los
objetos solicitados del servidor 20. Una unidad 34 de tratamiento
del servidor proxy 30 comunica con la interfaz 32 de
comunicaciones. La unidad 34 de tratamiento permite establecer y/o
adaptar la prioridad de cualquier objeto recibido del servidor 20
por medio del primer vínculo 12. Adicionalmente, la unidad 34 de
tratamiento permite asignar una prioridad inicial a un objeto
solicitado basándose en un análisis de al menos uno de la
solicitud de objeto y del código que se refiere al objeto
solicitado. Más adelante se describen con más detalle esquemas
posibles de asignación.
Dependiendo de la prioridad inicial o actualizada
de un objeto solicitado, la unidad 34 de tratamiento controla la
interfaz 32 de comunicaciones de tal manera que un objeto solicitado
recibido del servidor 30 es retardado o enviado a través del
segundo vínculo 14 al cliente 40. Si un objeto solicitado recibido
del servidor 20 tiene que retardarse, se guarda provisionalmente en
una memoria intermedia 36 a la que se puede acceder tanto por
medio de la interfaz 32 de comunicaciones como por la unidad 34 de
tratamiento. Alternativa o adicionalmente, la memoria intermedia 36
se puede implementar como un componente de software o de hardware
de la unidad 34 de tratamiento.
Además de las tareas anteriormente descritas, la
unidad 34 de tratamiento está configurada adicionalmente de tal
manera que permita asignar un atributo específico a un objeto que
tiene que retardarse (un formato ejemplar de este atributo se
describe más adelante con mayor detalle). La unida 34 de
tratamiento permite controlar la interfaz 32 de comunicaciones de
tal manera que la interfaz 32 de comunicaciones informe al cliente
40 sobre este atributo. Si la interfaz 32 de comunicaciones recibe
del cliente 40 una referencia al atributo, la unidad 34 de
tratamiento evalúa esta referencia y controla la interfaz 32 de
comunicaciones de tal manera que el objeto retardado al que se ha
asignado previamente este atributo y que actualmente está guardado
en la memoria intermedia 36, o bien es enviado al cliente 40, o
bien se retarda adicionalmente. Podría llegar a ser necesario un
retardo adicional del objeto guardado en la memoria intermedia 36
si deben enviarse primero al cliente 40 objetos de una prioridad
más alta.
A continuación se describe, a título de ejemplo,
un modo operativo preferido del sistema 10 de red mostrado en la
Figura 2.
Cuando un usuario entra en un URL, hace clic en
un vínculo o sigue una señal, el explorador que se funciona sobre
el cliente 40 emite una solicitud de HTTP para la correspondiente
página de HTML que incluye el código de HTML. La solicitud de HTTP
emitida por el explorador es recibida por el servidor proxy 30 a
través del vínculo 14 y enviada a través del vínculo 12 al servidor
de destino 20. El servidor 20 contesta enviando el código de HTML
para la página solicitada al servidor proxy 30, el cual analiza el
código de HTML recibido del servidor 20 para asignar una prioridad
inicial a cualquier clase de objetos como vínculos, tramos,
secuencias de comandos, imágenes, etc, a los que se haya hecho
referencia en el código de HTML (fase de primer análisis).
Independientemente de este análisis del código
HTML, el servidor proxy 30 envía el código de HTML a través del
vínculo 14 al cliente 40. Cuando el explorador que se ejecuta sobre
el cliente 40 recibe la página de HTML que incluye el código de
HTML, procesa el código de HTML. Si el explorador detecta que el
código de HTML incluye objetos adicionales, emite solicitudes
adicionales de HTTP para los objetos a los que se haya hecho
referencia en el código de HTML. Estas solicitudes de HTTP para
objetos adicionales se reciben y evalúan mediante el servidor
proxy 30. Para la mayor parte de los objetos solicitados, se habrá
asignado ya una prioridad inicial durante el análisis previo por
parte del servidor proxy 30 del código de HTML que se haya enviado
al servidor 30. Sin embargo, en esta segunda fase de análisis el
servidor proxy 30 o bien asigna prioridades iniciales a los
objetos a los que no se haya asignado aún una prioridad, o bien
actualiza la prioridad de dichos objetos a los que ya se haya
asignado una prioridad. La prioridad se actualiza basándose en la
información disponible en la solicitud de HTTP recibida del cliente
40.
El servidor proxy 30 envía al servidor 20
cualesquiera solicitudes HTTP de objetos adicionales recibidas del
cliente 40. El servidor 20 responde enviando los objetos solicitados
al servidor proxy 30. El servidor proxy 30 analiza las respuestas
de HTTP (incluyendo los objetos solicitados) del servidor 20 en una
tercera fase de análisis y actualiza - si es necesario - las
prioridades de los objetos comprendidos en la respuesta de HTTP.
Adicionalmente, el servidor proxy 30 establece la prioridad relativa
de cualquier objeto recibido con respecto a la prioridad de
objetos recibidos previamente que todavía estén guardados en la
memoria intermedia 36 (véase Figura 3) y las prioridades de los
objetos que se esperan pronto. La información relativa a los
objetos que se recibirán pronto del servidor 20 se puede obtener del
código de HTML que haya sido enviado previamente al cliente 40 o
de las solicitudes de HTML del cliente 40 para las que los objetos
correspondientes no se hayan recibido todavía del servidor 20.
Alternativa o adicionalmente, el servidor proxy 30 podría
configurarse de tal manera que compare una prioridad de un objeto
que se acabe de recibir del servidor 40 con un valor absoluto como
un umbral de prioridad.
Basándose en la evaluación de la prioridad
absoluta o relativa de un objeto y en el tráfico actual y/o
previsto en el vínculo 14, el servidor proxy 30 decide si hay que
retrasar este objeto, por ejemplo, si este objeto se va a guardar
provisionalmente en la memoria intermedia 36 o si la
correspondiente solicitud de HTTP no se va a enviar todavía al
servidor 20, o si el objeto se va a enviar inmediatamente al
cliente 40.
El retardo intencionado de los objetos
individuales mejora la transferencia total de objetos desde el
punto de vista de un usuario. Por ejemplo, es bien sabido que la
importancia relativa de los diversos objetos incluidos en una
página web varía enormemente: una imagen que se use para construir
un menú gráfico podría ser esencial para la navegación de un
sitio, mientras que una imagen de fondo simplemente hace que la
página parezca más bonita. Por tanto, el invento se puede emplear
para proporcionar al usuario en primer lugar la información más
importante. Tan pronto como haya suficiente información de una
página web presentada visualmente en la pantalla de un usuario,
éste puede decidir hacer clic en un vínculo y solicitar otra página
web sin tener que esperar por las partes restantes (menos
importantes) de la página web anterior que todavía se está
transfiriendo. Como resultado, el usuario ya no está obligado a
esperar hasta que sean transferidos algunos objetos no interesantes
antes de poder ver los importantes. Esto es especialmente útil
conjuntamente con la Internet móvil, que usualmente es más lenta y
más cara que la Internet fija.
Como ha resultado evidente a partir de lo
anteriormente expuesto, el servidor proxy 30 puede asignar o
ajustar la prioridad de un objeto a enviar al cliente 20 durante
tres fases diferentes, a saber, cuando se ha encontrado en un
código de HTML una referencia a ese objeto (es decir, en un objeto
previo) que tenga que enviarse al cliente 40, cuando el explorador
que funciona sobre el cliente 40 emite una solicitud de HTTP
relacionada con dicho objeto, o cuando la respuesta correspondiente
HTTP que contiene el objeto solicitado se recibe del servidor
20.
En lo que sigue se describen a título de ejemplo
varios planes para asignar o actualizar prioridades durante cada
una de estas tres fases. Durante cualquiera de las tres fases, se
genera o actualiza una lista de prioridades que contiene
información de prioridad para objetos individuales o clases de
objetos. En la lista de prioridades, los objetos individuales o
clases de objetos se ordenan con respecto a una prioridad creciente
o decreciente. El orden de los objetos en la lista de prioridades
se puede considerar así como información de prioridad. Sin
embargo, la información adicional de prioridad como los valores
(números) absolutos o relativos de prioridad podría alternativa o
adicionalmente formar parte de la lista de prioridades.
La prioridad exacta asignada a objetos o clases
de objetos específicas depende de la implementación, y, en la
realización ejemplar, es configurable por el operador del servidor
proxy 30 o por un usuario del explorador que funciona sobre el
cliente 40. Por ejemplo, con el fin de permitir que el operador del
servidor proxy 20 tenga más control sobre la prioridad de algunos
objetos, podrían existir una o varias listas de URL (usando
conjugación de patrones) que permitan que el operador aumente o
disminuya la prioridad de los objetos que aparezcan en estas
listas. Por ejemplo, un operador podría decidir aumentar o
disminuir la prioridad de todas las imágenes descargadas de una
compañía de publicidad. Las mismas posibilidades se podrían poner a
la disposición del usuario. Por ejemplo, el usuario podría enviar
sus preferencias al servidor proxy 30. Esto puede hacerse mediante
un software específico que se ejecute sobre el cliente 40 o bien
utilizando páginas web designadas provistas directamente por el
servidor proxy 30 y que permitan al usuario ajustar sus
preferencias.
En la primera fase de análisis, el servidor proxy
30 puede asignar una prioridad inicial a un objeto mediante el
análisis de un código de HTML que haya sido solicitado del servidor
20 por el cliente 40. En particular, se podrían establecer en ese
sentido referencias a objetos a los que se haya hecho referencia en
el código de HTML. De este modo, se podría generar una lista de
prioridades que relacione objetos individuales a los que se haya
hecho referencia en el código de HTML en el orden siguiente (los
objetos con la máxima prioridad se mencionan en primer lugar):
- vínculos con otras páginas
- tramos de datos
- imágenes en línea (si la etiqueta IMG incluye
información de anchura y altura, esta información se puede usar
para realinear la prioridad de las imágenes dependiendo de las
dimensiones previstas, de tal manera que las imágenes más pequeñas
tengan una prioridad más alta que las imágenes grandes).
- hojas de estilo
- secuencias de comandos (JavaScript, VBScript,
etc.), objetos empotrados y subprogramas
- imagen de fondo (fondo de página, fondo de
mesa, hoja de estilo, etc.
- cualquier objeto que ya se haya enviado al
cliente 40 obtiene la prioridad mínima.
Además, se puede disminuir la prioridad de un
objeto específico si el objeto no está situado en el mismo servidor
20 o en el mismo dominio que la página actuadle HTML.
Se produce una posibilidad adicional para asignar
o ajustar la prioridad de un objeto cuando el explorador emite una
solicitud para ese objeto y dicha solicitud es recibida por el
servidor proxy 30. En tal caso, el servidor proxy 30 puede analizar
la solicitud de HTTP en un contexto de URL (segunda fase de
análisis). Puesto que ya se han asignado las prioridades iniciales
durante el análisis del código de HTML que condujo a esa solicitud
de HTTP, el análisis de la solicitud de HTTP resultará usualmente
en un ajuste de la prioridad inicial. Sin embargo, en algunos casos
se podrían asignar también prioridades iniciales (véase descripción
anterior).
El ajuste o la asignación de prioridades
iniciales en la segunda fase de análisis se pueden realizar
dependiendo de la información adicional disponible, por ejemplo, en
el encabezamiento de la solicitud de HTTP. Se podrían implementar
una o más de las reglas siguientes para actualizar las
prioridades:
- -
- El análisis conduce al resultado de que el explorador ya ha solicitado una vez el mismo objeto. A dicho objeto usualmente se le asigna una prioridad muy alta, con el fin de evitar los bucles infinitos causados por exploradores que no cumplan la norma HTTP/1 e ignoren el encabezamiento "Reintentar- Después de" (este encabezamiento se describe con más detalle a continuación).
- -
- El objeto no tiene todavía una prioridad, pero la extensión parece como HTML ("HTML", "HTM", o XML ("XML") o parece como un índice de directorio (finales en "/"). Esta asignación de prioridad asegura que una página de HTML solicitada de las señales o tecleada directamente se solicitará con una prioridad alta.
- El explorador hace una solicitud condicional de
HTTP para un objeto, usando condiciones
si-modificada-desde o condiciones
similares. Esto indica que el explorador ha guardado probablemente
una copia del objeto. Se espera que la respuesta sea pequeña si la
copia guardada todavía es válida (código de HTML de respuesta
"304 no modificado").
- Se encontró el URL del objeto solicitado
mientras se analizaba una página de HTML anterior.
- Cualquier objeto que no se hubiese insertado en
la lista mientras se analizaban las etiquetas de HTML de una
página anterior se solicitó probablemente de un modo indirecto
mediante una secuencia de comandos, y debería obtener una
prioridad menor que la mayor parte de los objetos solicitados.
En la tercera fase de análisis, el ajuste de las
prioridades de los objetos se basó en un análisis de la respuesta
de HTTP del servidor 20. El ajuste de las prioridades en la tercera
fase de análisis ( así como en la segunda fase de análisis
anteriormente mencionada) se puede calcular como una suma ponderada
de varios criterios. Los pesos relativos podrían ser configurables
por el operador del servidor proxy 30 o por el usuario del
explorador que funciona sobre el cliente 40.
En la tercera fase de análisis, todos los objetos
tendrán probablemente una prioridad asignada a ellos. Sin embargo,
esta prioridad se puede actualizar antes de enviar los objetos
solicitados al cliente 40. Para ajustar las prioridades, se podrían
establecer los encabezamientos y contenidos de las respuestas HTTP
recibidas del servidor 20. Luego se podrían ajustar las prioridades
de acuerdo con una o más de las reglas siguientes.
- Establecimiento del código de respuesta: la
prioridad relativa de las respuestas de HTTP depende del primer
dígito del código de respuesta. Los códigos de error (4xx.5xx)
deberían tener una prioridad más alta que las respuestas normales
(2xx).
- Establecimiento del tipo de contenido: un
código de HTML debería tener una prioridad mayor que cualquier
imagen.
- Establecimiento del tamaño de los objetos
(obtenido de la longitud del contenido si se ha especificado en
los encabezamientos, o del tamaño total si el objeto ya se ha
guardado): los objetos más pequeños deberían tener una prioridad
un poco mayor que los grandes.
- Análisis del contenido: por ejemplo, a las
imágenes animadas se les puede asignar una prioridad menor que a
las imágenes estáticas. El análisis del contenido puede también
constituir la base para estimar el tamaño del objeto si no se
dispone de esta información en el encabezamiento de HTTP y el
objeto no se ha guardado todavía.
- Si el código de respuesta es una redirección
permanente o provisional (3xx) que especifique una nueva
localización para el objeto solicitado, entonces esta nueva
localización obtiene la misma prioridad que el objeto
original.
En las tres fases de análisis anteriormente
descritas, el servidor proxy 30 establece y actualiza las
prioridades de los objetos que se van a transferir al cliente 40.
De ese modo, el servidor proxy 30 mantiene cierta información
sobre cada objeto como el URL de objetos, prioridad, hora de la
última solicitud y, si se requiere, algunos parámetros
adicionales. Sin embargo, esta información no se puede mantener
indefinidamente, porque de lo contrario el servidor proxy 30
funcionaría fuera de memoria. Además, si a un objeto al que se haya
asignado una prioridad alta nunca se le solicita, se toma
preferiblemente la medida de que no impida que se transfieran otros
objetos.
Por estas razones, se implementa una rutina que
asegure que se suprima la información que ya no esté actualizada o
que ya no se necesite. Para ello, se podrían usar uno o más de los
mecanismos siguientes:
- Cualquier objeto que se haya transferido de
forma satisfactoria al cliente es marcado como que se ha enviado o
se traslada a una lista separada de objetos que se han enviado al
cliente 40.
- Se establece un tamaño máximo para una o más
listas que contengan información relevante y se configura que los
objetos más antiguos o los objetos con la mínima prioridad caduquen
primero.
- Siempre que el cliente reconfigura una conexión
de TCP antes de que el objeto se haya transferido totalmente (lo
que significa que el usuario ha detenido la descarga y podría haber
seleccionado otra página), aclarar la información de los objetos a
enviar.
- Como una alternativa a la solución anterior,
mantener contrarreferencias para cada objeto con el fin de asociar
cada página de HTML con los objetos que contiene, y viceversa.
Cuando el cliente 40 reconfigura una conexión de TCP, retirar
solamente los objetos que están incluidos en la misma página de
HTML.
- La prioridad de todos los objetos se puede
disminuir después de un período de tiempo especificado o después
que se han tratado algún número de solicitudes de HTTP o de
respuestas de HTTP.
En el capítulo anterior se han descrito la
generación de una lista de prioridades para los objetos solicitados
que se van a transferir al cliente 40, así como posibles mecanismos
de actualización para esta lista de prioridades. Usualmente, los
objetos solicitados serán recibidos por el servidor proxy 30 del
servidor 20 en un orden que es diferente del orden indicado en la
lista de prioridades. Por consiguiente, el servidor proxy 30 tiene
que reordenar los objetos recibidos del servidor 20 de tal manera
que se envíen desde el servidor proxy 30 al cliente 40 en un orden
que refleje el orden en la lista de prioridades con la mayor
aproximación posible. El servidor proxy 30 reordena los objetos
recibidos del servidor 20 mediante el retardo intencionado de los
objetos que tienen una prioridad inferior y mediante el envío al
cliente 40 de los objetos que tengan una prioridad más alta sin
ningún retardo sustancial.
El servidor proxy 30 usa una combinación de
diferentes mecanismos de retardo para reordenar los objetos
recibidos del servidor 20. En lo que sigue se describirán con más
detalle a título de ejemplo dos de estos mecanismos de retardo, a
saber, la suspensión de las conexiones de TCP, por una parte, y
las redirecciones de HTTP por otra parte.
Como resulta evidente en la Figura 2, el vínculo
14 entre el servidor proxy 30 y el cliente 40 está constituido por
una pluralidad de conexiones 50 de TCP. Dependiendo de las
prioridades de los objetos solicitados que se van a enviar por
medio de conexiones individuales de las conexiones 50, una o más de
las conexiones 50 que están destinadas para la transferencia de
objetos que tienen una prioridad baja están suspendidas. Esta
suspensión de conexiones individuales libera cierto ancho de banda
en el vínculo 14 que ahora está disponible para transferir con
preferencia objetos que tengan una prioridad más alta. Por
consiguiente, los objetos que tengan una prioridad más alta se
descargarán antes que los objetos que tengan una prioridad más
baja.
La suspensión de una conexión individual 50 se
realiza de tal manera que la conexión 50 se deja abierta sin
transferir objetos durante un período determinado de tiempo.
Alternativamente, la suspensión de una conexión 50 se podría
efectuar cerrando la conexión 50 con o sin guardar el estado de la
conexión 50 antes de su suspensión. Cuando el estado de la conexión
suspendida se guarda, se puede abrir en un momento posterior en el
mismo estado en que se ha suspendido (es decir, cerrado).
La suspensión de una conexión 50 tiene la ventaja
de que no hay que enviar datos extraordinarios a través del
vínculo 14. Preferiblemente, una conexión 50 se suspende sólo si el
ancho de banda liberado se puede usar totalmente por algunas otras
conexiones 50 para la transferencia de objetos que tengan una
prioridad alta.
Por tanto, el servidor proxy 30 está configurado
de tal manera que comprueba que el vínculo 14 se ha usado
totalmente antes de suspender una conexión 50, a fin de no
desperdiciar ancho de banda disponible. Una rutina posible para
predecir si el vínculo 14 está o estará parcialmente vacío incluye
comparar la salida promedio (durante los N últimos segundos) de
todas las conexiones que van al cliente 40 con la cantidad de datos
que actualmente se estén acumulando o guardando en la memoria
intermedia 36 del servidor proxy 30 (véase Figura 3) y están
listos para ser enviados. Se podrían implementar otras técnicas y en
particular más sencillas para estimar la utilización del vínculo
14, así como, especialmente, si se conoce por otros medios el ancho
de banda disponible en el vínculo 14.
Si el servidor proxy 30 espera que los objetos
que tienen una prioridad alta tendrán que transferirse pronto al
cliente 40 (por ejemplo, porque el servidor proxy 30 ha detectado
previamente vínculos a estos objetos mientras enviaba un código de
HTML de una página de HTML al cliente 40), y la suspensión de una
conexión 50 desperdiciaría algo de ancho de banda porque
actualmente no habría nada más para transferir en las otras
conexiones 50, entonces el servidor proxy 30 podría utilizar otro
plan de retardo. Un plan posible de retardo que se podría aplicar
en tal caso incluye dar instrucciones al cliente para repetir una
solicitud de objeto en un momento posterior.
Aunque el HTTP especifica que cualesquiera
respuestas de HTTP deben enviarse al cliente 40 en el mismo orden
con que el explorador que funciona sobre el cliente 40 ha emitido
las solicitudes de HTTP, es posible dar instrucciones al
explorador para reintentar más tarde una solicitud de HTTP. Esto se
puede hacer enviando una respuesta de HTTP con el código de estado
"302" al cliente 40, junto con el campo de encabezamiento
"Reintentar-Después de". Este campo del
encabezamiento comunica al cliente 40 que reintente su solicitud de
HTTP después de un período de tiempo especificado. En respuesta a
la recepción del código de estado "302" (posiblemente
incluyendo el campo de encabezamiento
"Reintentar-Después de"), los exploradores
actuales reprograman la solicitud HTTP después que se han
procesado todas las solicitudes de HTTP pendientes.
El código de estado "302", según se ha
especificado en la norma HTTP 1.1,comunica al explorador que un
objeto determinado se puede encontrar (provisionalmente) en una
localización que es diferente de la que se ha solicitado. La
respuesta de HTTP enviada al cliente 40 incluye la nueva
localización del objeto. Este mecanismo se usa para implementar el
plan de retardo de acuerdo con el invento.
De acuerdo con el invento, el servidor proxy 30
genera un atributo en la forma de un nuevo URL (virtual) para el
objeto a retardar. El servidor proxy 30 entonces da instrucciones al
explorador que funciona sobre el cliente 40 de intentar otra vez
la solicitud de HTTP, usando este atributo provisional (es decir,
URL) como la nueva localización del objeto. De ese modo, el
explorador ha recibido instrucciones para reprogramar la solicitud
de HTTP en un momento posterior. Cuando el explorador repite la
solicitud de HTTP (incluyendo el atributo provisional, es decir el
URL virtual), el servidor proxy 30 convierte el atributo al URL
original, y envía la solicitud de HTTP al servidor 20.
Alternativamente, la solicitud original de HTTP se podría haber
enviado al servidor 20 después de su recepción por el servidor
proxy 30 En tal caso, la respuesta de HTTP recibida del servidor
20 se guarda provisionalmente por el servidor proxy 30 hasta que
recibe del cliente 40 la solicitud repetida de HTTP.
En lo que sigue, se describe a título de ejemplo
con más detalle el mecanismo de retardo del invento con referencia
a las Figuras 4 y 5. Se supondrá que la solicitud de HTTP recibida
por el servidor proxy 30 del cliente 40 se refiere a un objeto que
el servidor proxy 30 considera de baja prioridad.
En una primera etapa 402 de la Figura 4, el
servidor proxy 30 recibe una solicitud de HTTP del cliente 40 por
medio del vínculo 14. En el caso ejemplar de HTTP, esta primera
solicitud del cliente tiene el siguiente formato:
\vskip1.000000\baselineskip
- GET htp://ejemplo.com/some/image.png HTTP/1.1
- central: ejemplo.com
- Agente de usuario: Moxilla/5.0 (X11; Linux 686; en-US; rv: 0.9.9
- Gecko/20020311
- Conexión: muy próxima
\vskip1.000000\baselineskip
En respuesta a la solicitud de HTTP recibida en
la etapa 402 del cliente 40, el servidor proxy 30 redirige al
cliente 40 en la etapa 304 a una nueva localización (virtual) y da
instrucciones al cliente 40 para esperar un período determinado de
tiempo (retardo) antes de volver a intentar la solicitud de HTTP.
El mensaje de redirección procedente del servidor proxy 30
basándose en el código de estado "302" según se ha
especificado en la morma HTTP 1.1 puede tener el siguiente
formato:
\vskip1.000000\baselineskip
- HTTP /1.1 302 encontrado
- Fecha: martes, 21 marzo 2002 15:12:47
- Servidor: PrioTest/0.9
- Localización: HTTP//example.com /some/() image (0001.png
- Reintentar-después de: 5
- Conexión: muy próxima
- Transferencia-Codificación: fragmentada
- Tipo de contenido: texto/html: conjunto de caracteres = iso-8859-1
- (sigue algún texto humano legible)
\vskip1.000000\baselineskip
El servidor proxy 30 puede ahora solicitar del
servidor 20 el objeto en cualquier momento tras la recepción de la
solicitud inicial de HTTP del cliente 40 (etapa 402) y el momento en
el que decide descargar el objeto al cliente 40 (etapas 406 y
408).
Después de recibir el mensaje de redirección
anteriormente expuesto, el cliente 40 espera durante un período de
tiempo especificado en el mensaje de redirección, es decir, cinco
segundos (o hasta que se hayan transferido todos los demás
objetos). En la etapa 412, el cliente 40 repite entonces la
solicitud de HTTP que indica la nueva localización (virtual) del
modo siguiente:
\vskip1.000000\baselineskip
- GET HTTP: //example.com/some /() image (00001). png HTTP/1.1
- Central: example.com
- Agente de usuario: Mozilla/5.0 (X11; Linux i686; en-US; rv:0.9.9)
- Gecko/20020311
- Conexión: muy próxima
\vskip1.000000\baselineskip
Tras recibir del cliente la solicitud repetida de
HTTP, el servidor proxy 30 decide si retarda adicionalmente el
objeto solicitado (por ejemplo, mediante la suspensión de una
conexión 50 o mediante un mensaje adicional de redirección) o si
envía el objeto retardado al cliente 40. Si el servidor proxy 30
decide enviar el objeto retardado sin ningún retardo adicional,
esta operación se puede hacer en el siguiente formato:
\vskip1.000000\baselineskip
- HTTP/1.1 200 OK
- Fecha: martes, 21 de marzo 2002 15:12:50
- Servidor: Apache/1.3.23 (Unís)
- Tipo de contenido: imagen/png
- Longitud de contenido: 1520
- (sigue el contenido de la imagen)
\vskip1.000000\baselineskip
A continuación se explican las decisiones tomadas
por el servidor proxy 30 en el transcurso de la rutina de
redirección anteriormente descrita con referencia a la Figura 5.
En la etapa 502, el servidor proxy 30 recibe la
solicitud de HTTP del cliente 40. En la etapa siguiente 504 el
servidor proxy 30 determina si el URL incluido en la solicitud de
HTTP es un URL modificado, es decir, el resultado de una
redirección anterior. Si es así, el servidor proxy 30 descodifica
el URL y restablece la localización original en la etapa 506 y se
desplaza a través del nodo 508 a la etapa 510. De lo contrario, el
método directamente se desplaza desde la etapa 504 por medio del
nodo 508 a la etapa 510.
En la etapa 510, el servidor proxy 30 determina
si el objeto solicitado por medio de la solicitud de HTTP ya está
disponible, es decir, guardado en la memoria intermedia 36 del
servidor proxy 30 (véase Figura 3). Si el objeto no se ha
guardado, el servidor proxy 30 solicita del servidor 20 el objeto,
o lo marca para una recuperación posterior en la etapa 514. Desde
la etapa 514, el método se desplaza por medio del nodo 512 a la
etapa 516. La etapa 516 se puede alcanzar también directamente desde
la etapa 510 a través del nodo 512 en el caso de que ya esté
disponible el objeto solicitado por el cliente 40.
En la etapa 516, la respuesta de HTTP que incluye
el objeto solicitado ya está lista para enviarse al cliente 40.
Esto corresponde a la primera etapa en el diagrama de flujo de la
Figura 6, que se describe más adelante.
En principio, el mensaje de redirección (etapa
504 en la Figura 4) se puede enviar al cliente 40 en cualquier
momento mientras se realizan las etapas 502 a 516 o después de la
etapa 516. Debe hacerse notar que la disponibilidad de un objeto
(es decir, si un objeto solicitado ya está guardado, actualmente en
transferencia o si el objeto todavía no ha sido solicitado) es un
factor adicional que influye en la prioridad inicial de un objeto
solicitado.
Una vez que la respuesta de HTTP está lista para
enviarse al cliente 40 (etapa 516 de la Figura 5), hay que decidir
si un objeto comprendido en la respuesta de HTTP debería realmente
descargarse al cliente 40, si el cliente 40 debería redirigirse o
si debería suspenderse la conexión 50 a través de la cual este
objeto se va a enviar al cliente 40. En la Figura 6 se ha
representado un diagrama de flujo que presenta un plan de decisión
a título de ejemplo.
En la etapa 602, la respuesta de HTTP está lista
para enviarse al cliente. En la etapa siguiente 604 se evalúa la
prioridad de este objeto con respecto al hecho de si hay que
actualizar o no la prioridad. Si tiene que actualizarse la
prioridad del objeto, el ajuste de prioridad se realiza en la etapa
604.
En la etapa siguiente 606 se establece la
prioridad actual del objeto para averiguar si tiene la máxima
prioridad de todos los objetos que se están transfiriendo o que se
espera transferir pronto. Si en la etapa 606 se determina que el
objeto solicitado realmente tiene la máxima prioridad, el método se
desplaza a través del nodo 610 a la etapa 612. En la etapa 612, el
objeto solicitado se envía al cliente 40.
Si la comparación entre la prioridad del objeto
solicitado actualmente y la prioridad de otros objetos, realizada
en la etapa 606, conduce al resultado de que el objeto actualmente
solicitado no tiene la máxima prioridad, el método continúa con la
etapa 514. Con respecto a la etapa 606, debe hacerse notar que, en
lugar de comparar la prioridad del objeto solicitado actualmente
con las prioridades de otros objetos, también es posible comparar
la prioridad del objeto actualmente solicitado con un umbral fijo o
añadir una desviación en la comparación para que dos prioridades
tengan que diferir en más de un umbral predefinido antes de que la
diferencia se considere bastante significativa.
En la etapa 614, el servidor proxy 30 estima si
el vínculo 14 al cliente 40 está o estará vacío. Como se ha
explicado anteriormente, hay varias formas de hacerlo. Una de ellas
consiste en calcular un promedio de funcionamiento de la máxima
cantidad de datos que se han enviado y de la que se ha acusado
recibo durante los N últimos segundos sobre todas las conexiones 50
que van al mismo cliente 40. Esto da una estimación de la máxima
capacidad de ejecución disponible.
El resultado así obtenido se compara luego con la
cantidad de datos que están listos para enviarse sobre las
conexiones 50 que no están suspendidas. Si el servidor proxy 30
detecta que no tiene datos suficientes para enviar con el fin de
llenar el vínculo durante al menos una vez de ida y vuelta
completa, entonces considera que existe alguna parte de reserva de
ancho de banda en el vínculo 14 hacia el cliente 40, y continúa
con la etapa 615.
En la etapa 616 se realiza una comparación
similar a la de la etapa 606. Si en la etapa 616 se determina que
el objeto solicitado actualmente tiene una prioridad mayor que
todos los objetos esperados pronto, el servidor proxy 30 continúa a
través del nodo 610 con la etapa 612 y envía el objeto actualmente
solicitado de forma inmediata al cliente 40. De lo contrario, el
método continúa con la etapa 618 y se envía un mensaje de
redirección (código de estado "302") al cliente 40 según se ha
expuesto anteriormente en relación con la Figura 4.
La decisión tomada en la etapa 616 podría estar
influida por el tamaño del objeto solicitado actualmente (si ya es
conocido). Si se sabe que el objeto es pequeño (por ejemplo, menor
que el doble del tamaño de un mensaje de redirección), entonces el
servidor proxy enviará siempre el objeto en lugar de enviar un
mensaje de redirección, incluso si hasta entonces al objeto se le ha
asignado una prioridad muy baja (esto puede considerarse como una
forma de actualizar la prioridad).
Si, en la etapa 614, se determina que hay datos
suficientes para enviar con el fin de llenar el vínculo 14, el
método continúa con la etapa 620 y suspende la conexión 50 al
cliente a través de la cual se vaya a transferir el objeto
actualmente solicitado
Desde una cualquiera de las etapas 612, 618 y 620
el método continúa con la etapa 622. En la etapa 622, el servidor
proxy 30 re-evalúa todas las conexiones suspendidas
para averiguar si una cualquiera de la conexiones suspendidas 50
tiene que volverse a abrir.
El protocolo HTTP/1.1 soporta la opción de
canalización, que permite al cliente 40 enviar varias solicitudes
al servidor 20 o al servidor proxy 30 sobre la misma conexión de
TCP sin esperar por las respuestas previas. En el caso de que se
use la canalización, se podría enviar más de un objeto que esté
listo para ser enviado sobre la misma conexión 50 hacia el cliente
40. Es evidente que en ese caso, un objeto que tenga una prioridad
baja podría bloquear a un segundo objeto que tenga una prioridad
alta que se vaya a enviar sobre la misma conexión 50. Si hay varios
objetos a la espera sobre la misma conexión 50, se podría
determinar la prioridad máxima o media de estos objetos y
considerarse en las etapas 606 y 616. Esto asegura que los objetos
de prioridad inferior no bloqueen a objetos de prioridad
superior.
Se podrían implementar varias extensiones,
algunas de las cuales se han descrito ya brevemente, a la
realización ejemplar descrita con referencia a las Figuras 1 a
6.
Una de estas extensiones se refiere a restringir
la velocidad de transferencia sobre el vínculo 14, dependiendo de
la prioridad de los objetos que se vayan a transferir. Esto podría
hacerse, por ejemplo, mediante la asignación de una participación
específica de posibilidades de proceso a cada conexión 50
dependiendo de la prioridad de los objetos a transferir. La
prioridad de los objetos individuales se disminuye mientras el
proceso está ejecutándose. Si el servidor proxy 30 procesa
conexiones 50 en una modalidad con retorno al punto de origen, esta
característica se implementaría mediante la limitación de la
cantidad de datos transmitidos por turno sobre cada conexión 50
mediante un número que se obtiene a partir de la prioridad de ese
objeto. La asignación dinámica de posibilidades de proceso se puede
combinar ventajosamente con los mecanismos de suspensión y
redirección anteriormente descritos. Las posibilidades de proceso
pueden incluir también cualquier transformación de los objetos o
códigos que se transfieren.
De acuerdo con una extensión adicional del
invento, las prioridades se asignan directamente por el explorador
que trabaja sobre el cliente 40. El explorador puede entonces
programar las solicitudes de HTTP para objetos individuales de
acuerdo con su prioridad. Si el explorador asigna directamente las
prioridades, hay varios factores adicionales que se pueden usar
para refinar la prioridad de cada objeto:
- situación del objeto en la página
(coordenadas)
- situación relativa del área visible (los
objetos que están fuera del área visible tienen una prioridad
inferior)
- si la carga de imágenes o la ejecución de
secuencias de comandos están inhabilitadas, el explorador sabe
inmediatamente que no es necesario asignar una prioridad a estos
objetos.
Adicionalmente, el explorador sabe cuándo un
usuario selecciona una nueva página de HTML a partir de las
señales o tecleando un nuev URL. De ese modo, el explorador puede
aclarar la lista de objetos que ya no son necesarios.
Una extensión adicional del invento se refiere a
un componente proxy que esté situado en el mismo ordenador
(cliente) que el explorador o muy cerca de este ordenador en cuanto
a vínculos de red. Esta situación se ha representado en la Figura
7.
Como resulta evidente en la Figura 7, el cliente
40 no sólo comprende un componente de explorador 42, sino un
componente proxy adicional 30 (que tiene la estructura mostrada en
la Figura 3) en comunicación con el componente de explorador 42.
En tal caso, el vínculo 14 entre el componente proxy 30 y el
componente de explorador 42 tiene una capacidad mucho mayor y un
estado latente menor que el vínculo 12 entre el componente proxy 30
y el servidor 20 (no representado en la Figura 7).
Como resultado, el componente proxy 30 del lado
cliente influye en la corriente de solicitudes porque no puede
hacer mucho sobre la corriente de respuestas. Basándose en la
información de prioridades obtenida de la solicitud actual de HTTP
y de las respuestas anteriores de HTTP (por ejemplo, códigos
anteriores de HTML que se refieran a objetos adicionales) así como
en una estimación de la disponibilidad de vínculo, el componente
proxy 30 del lado cliente decidirá si se debe enviar al servidor
una solicitud de HTTP y/o si debería contestar inmediatamente con
un mensaje de redirección.
Las decisiones a tomar son más sencillas de lo
que se ha representado en el diagrama de flujo de la Figura 6. Más
particularmente, las decisiones se pueden limitar a evaluar si el
objeto solicitado actualmente tiene una prioridad más baja que
algunos de los objetos que se están transfiriendo o que se espera
que se transfieran pronto, y si el vínculo ya se ha usado por
completo. Si se dan ambas condiciones, entonces se envía un mensaje
de redirección al componente de explorador 42. En todos los demás
casos, la solicitud de HTTP se envía inmediatamente al
servidor.
Si se usa la canalización de HTTP sobre una
conexión específica y se están procesando algunas solicitudes
anteriores de HTTP, entonces el componente proxy 30 del lado cliente
puede suspender la solicitud de HTTP hasta que pueda tomar la
decisión. Tendrá que tomar una decisión lo más tarde cuando se
hayan recibido totalmente los objetos anteriores.
Todavía una extensión más del invento se refiere
al bloqueo de descargas para algunos objetos basándose en su
prioridad. Esto significa que la prioridad que se asigne a los
objetos se puede usar también para bloquearlos completamente. Si
se ha establecido un umbral sobre la prioridad, todo objeto que
tenga una prioridad que sea inferior a este umbral no se enviará al
cliente 40. En este caso, el servidor proxy (o el componente proxy)
30 simplemente devolvería al cliente 40 uno de los códigos de
estado "4xx" ó "5xx" definidos en la norma HTTP 1.1
cuando detectase dicho objeto. Son códigos de estado posibles "403
prohibido", "409 conflicto" o "servicio 503 no
disponible".
Como una extensión adicional, se podrían usar las
prioridades asignadas a los objetos para efectuar una
pre-búsqueda. Un mecanismo de
pre-búsqueda permite al servidor proxy 30 llenar su
memoria intermedia 36 (véase Figura 3) con algunos objetos antes
de que el cliente 40 los solicite realmente. Dicho mecanismo de
pre-búsqueda se podría basar, por ejemplo, en el
análisis de un código de HTML que se envíe desde el servidor proxy
30 al cliente 40 y que incluya referencias a objetos adicionales.
Basándose en el análisis de las referencias a los objetos, el
componente proxy 30 asigna prioridades a los objetos individuales
y, basándose en esta asignación, se define qué objetos se van a
buscar previamente y en qué orden. Preferiblemente, los objetos se
buscan previamente empezando con los objetos que tengan la
prioridad máxima.
De acuerdo con todavía otra extensión adicional
que se puede combinar con el mecanismo de
pre-búsqueda descrito anteriormente, se implementan
planes específicos de impulsión que permiten transferir objetos
desde el servidor proxy 30 al cliente 40 sin haber recibido del
cliente 40 una solicitud explícita de objeto
Son posibles diversas modificaciones de la
realización preferida sin apartarse del alcance del presente
invento. Aunque se ha descrito el invento en relación con una
realización preferida, se entenderá que esta descripción no tiene
carácter limitativo al mismo. Más bien, el invento está destinado a
cubrir todas las modificaciones y/o adiciones a la descripción
anteriormente mencionada, sin apartarse del alcance del
invento.
Claims (24)
1. Un método de controlar, en una red (10) de
comunicaciones, una transferencia de objeto desde un primer
componente (20) a través de un componente intermedio (30) a un
segundo componente (40) que está distante del primer componente
(20), en el que la transferencia de objeto se basa en una pluralidad
de solicitudes de objeto relacionada con objetos a los que se ha
hecho referencia en uno o más códigos que se van a procesar mediante
el segundo (40) u otro componente de la red (10) de comunicaciones,
cuyo componente intermedio realiza las etapas de:
- -
- enviar una solicitud (406) de objeto al primer componente (20);
- -
- recibir del primer componente (20) el objeto solicitado (408); caracterizado porque el componente intermedio realiza además las etapas de
- -
- establecer y/o actualizar una prioridad del objeto solicitado (604),
en el que se ha asignado una prioridad inicial al
objeto solicitado basándose en un análisis de al menos uno de la
solicitud de objeto y del código que se refiere al objeto
solicitado; y
- dependiendo de la prioridad del objeto
solicitado, retardar (618; 404, 410, 412) el objeto solicitado o
enviar (612) el objeto solicitado al segundo componente (40).
2. El método de la reivindicación 1,
en el que el retardo (618; 404, 410, 412) se
realiza de tal manera que el orden en el que se reciben del primer
componente (20) los objetos difiere del orden en el que los objetos
se envían al segundo componente (40).
3. El método de la reivindicación 1 ó 2,
en el que la solicitud de objeto se recibe (402)
del segundo componente (40) o se genera mediante el componente
intermedio (30).
4. El método de una de las reivindicaciones 1 a
3,
en el que el retardo (618; 404, 410, 412) del
objeto solicitado incluye al menos una de las operaciones de dar
instrucciones al segundo componente (20) para repetir la solicitud
de objeto, suspender una conexión (620) al segundo componente (40) a
través de la cual se va a enviar el objeto solicitado, e informar al
segundo componente (40) que el objeto solicitado se enviará
automáticamente en un instante posterior.
5. El método de la reivindicación 3,
en el que la operación de dar instrucciones al
segundo componente (40) para repetir la solicitud de objeto
incluye:
- asignar un atributo específico al objeto que se
va a retardar;
- Informar del atributo al segundo componente
(40);
- recibir del segundo componente (40) una
referencia al atributo; y
- tras la recepción de la referencia al atributo,
enviar el objeto retardado al segundo componente (40) o retardar
adicionalmente el objeto retardado.
6. El método de una cualquiera de las
reivindicaciones 1 a 5,
en el que los objetos solicitados se envían al
segundo componente (40) a través de una pluralidad de conexiones
(50) al segundo componente (40).
7. El método de la reivindicación 6,
en el que las seleccionadas de las conexiones
(50) al segundo componente (40) se suspenden dependiendo de las
prioridades de los objetos solicitados que se recibieron del primer
componente (20) y que se van a enviar a través de las seleccionadas
de las conexiones (50).
8. El método de las reivindicaciones 6 ó 7,
en el que a cada conexión se le asigna
dinámicamente una participación específica de las posibilidades de
proceso.
\newpage
9. El método de una de las reivindicaciones 1 a
8,
que comprende además:
- enviar una solicitud de código al primero (20)
o a un tercer componente;
- recibir del primero (20) o del tercer
componente el código solicitado;
- analizar el código recibido con respecto a
referencias a objetos;
- establecer las referencias a objetos con el fin
de asignar prioridades iniciales a los objetos a los que se ha hecho
referencia en el código recibido.
10. El método de una de las reivindicaciones 1 a
9.,
en el que, tras recibir del primer componente
(20) una respuesta que contiene el objeto solicitado, la respuesta
se evalúa con respecto a la prioridad del objeto recibido con el fin
de determinar si hay que actualizar o no la prioridad inicial del
objeto recibido.
11. El método de una de las reivindicaciones 1 a
10,
que comprende además generar una lista de
prioridades que contiene información de prioridad para objetos
individuales o clases de objetos.
12. El método de la reivindicación 11,
que comprende además establecer repetidamente la
lista de prioridades con respecto al menos a una de las operaciones
de actualizar la información de prioridad y de suprimir objetos o
clases de objetos, o la información correspondiente, de la lista de
prioridades.
13. El método de una de las reivindicaciones 1 a
12,
en el que las etapas se realizan mediante un
componente proxy situado en el primer componente, en el segundo
componente o configurado como un componente de hardware (30)
separado de la red de comunicaciones.
14. Un método de retardar, en una red (10) de
comunicaciones, una transferencia de objeto desde un primer
componente (20) a través de un componente intermedio (30) a un
segundo componente (40) que está distante del primer componente
(20),
en el que la transferencia de objeto se basa en
una pluralidad de solicitudes de objeto relacionadas con objetos a
los que se ha hecho referencia en uno o más códigos que se van a
procesar mediante el segundo (40) u otro componente de la red de
comunicaciones, caracterizado porque el componente intermedio
realiza las etapas de:
- asignar un atributo específico a un objeto que
se va a retardar;
- informar sobre el atributo al segundo
componente (40);
- recibir del segundo componente (40) una
referencia al atributo; y
- tras la recepción de la referencia al atributo,
enviar el objeto retardado al que se le ha asignado el atributo al
segundo componente (40) o retardar adicionalmente el objeto
retardado.
15. El método de la reivindicación 14,
en el que el objeto se envía al segundo
componente (40) de acuerdo con un plan de impulsión o en respuesta a
una solicitud de objeto recibida del segundo componente (40).
16. El método de la reivindicación 15,
en el que se informa al segundo componente (40)
sobre el atributo en relación con una instrucción de repetir la
solicitud de objeto, y en el que la referencia al atributo se recibe
del segundo componente (40) en relación con una solicitud repetida
de objeto.
17. Un producto de programa de ordenador que
comprende partes de código de programa para realizar las etapas de
las reivindicaciones 1 a 16 cuando el producto de programa de
ordenador se ejecuta sobre un sistema (30) de ordenador.
\newpage
18. El producto de programa de ordenador de la
reivindicación 17, guardado en un medio de almacenamiento legible
por ordenador.
19. Un componente intermedio (30) para controlar,
en una red (10) de comunicaciones, una transferencia de objeto desde
un primer componente (20), a través del componente intermedio (30),
a un segundo componente (40) que está distante del primer componente
(20), en el que la transferencia de objeto se basa en una pluralidad
de solicitudes de objeto relacionadas con objetos a los que se ha
hecho referencia en uno o más códigos que se van a procesar mediante
el segundo u otro componente de la red de comunicaciones, cuyo
componente intermedio (30) comprende una interfaz (32) de
comunicaciones para enviar una solicitud de objeto al primer
componente (20) y para recibir del primer componente (20) el objeto
solicitado, caracterizado porque el componente intermedio
(30) comprende una unidad (34) de tratamiento para establecer y/o
actualizar una prioridad del objeto solicitado, en el que se ha
asignado una prioridad inicial al objeto solicitado basándose en un
análisis de al menos uno de la solicitud de objeto y del código que
se refiere al objeto solicitado, y en el que la unidad (34) de
tratamiento, dependiendo de la prioridad del objeto solicitado,
retarda el objeto solicitado o controla la interfaz (32) de
comunicaciones para enviar al segundo componente (40) el objeto
solicitado.
20. Un componente intermedio (30) para retardar,
en una red (10) de comunicaciones, una transferencia de objeto desde
un primer componente 820) a través del componente intermedio (30) a
un segundo componente (40) que está distante del primer componente
(20), en el que la transferencia de objeto se basa en una pluralidad
de solicitudes de objeto a los que se hace referencia en uno o más
códigos que se van a procesar mediante el segundo u otro componente
de la red de comunicaciones,
caracterizado porque el componente
intermedio (30) comprende,
una unidad (34) de tratamiento para asignar un
atributo específico a un objeto que se va a retardar y una interfaz
(32) de comunicaciones para informar al segundo componente (40)
sobre el atributo, para recibir del segundo componente (40) una
referencia al atributo, y, tras la recepción de la referencia al
atributo, para enviar el objeto retardado al que se le ha asignado
el atributo al segundo componente (40) o para retardar
adicionalmente el objeto retardado.
21. El componente intermedio de las
reivindicaciones 19 ó 20, configurado como un servidor proxy
(filtro).
22. Un sistema (10) de red que comprende al menos
uno de los componentes (30) de las reivindicaciones 19 a 21.
23. El sistema de red de la reivindicación 22,
que comprende además un primer vínculo (12) entre el componente
intermedio (30) y el primer componente (20) y un segundo vínculo
(14) entre el componente intermedio (30) y el segundo componente
(40), en el que el primer vínculo (12) y el segundo vínculo (14)
tiene diferentes tasas de transferencia.
24. El sistema de red de las reivindicaciones 22
ó 23, que comprende un segundo componente (40) en la forma de un
terminal móvil.
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/EP2002/003802 WO2003085924A1 (en) | 2002-04-05 | 2002-04-05 | Object transfer control in a communications network |
Publications (1)
Publication Number | Publication Date |
---|---|
ES2257543T3 true ES2257543T3 (es) | 2006-08-01 |
Family
ID=28685820
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES06000930T Expired - Lifetime ES2317348T3 (es) | 2002-04-05 | 2002-04-05 | Prioridades de transferencia de objeto en una red de comunicaciones. |
ES02727530T Expired - Lifetime ES2257543T3 (es) | 2002-04-05 | 2002-04-05 | Control de transferencia de objeto en una red de comunicaciones. |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES06000930T Expired - Lifetime ES2317348T3 (es) | 2002-04-05 | 2002-04-05 | Prioridades de transferencia de objeto en una red de comunicaciones. |
Country Status (10)
Country | Link |
---|---|
US (2) | US7721294B2 (es) |
EP (2) | EP1650931B1 (es) |
CN (1) | CN100531186C (es) |
AT (2) | ATE413763T1 (es) |
AU (1) | AU2002257754A1 (es) |
DE (2) | DE60229796D1 (es) |
ES (2) | ES2317348T3 (es) |
IL (3) | IL163889A0 (es) |
PT (2) | PT1493257E (es) |
WO (1) | WO2003085924A1 (es) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2015052354A1 (es) * | 2013-10-07 | 2015-04-16 | Telefonica Digital España, S.L.U. | Procedimiento y sistema para definir el orden de obtención de recursos web por un navegador web |
Families Citing this family (68)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2003058879A1 (en) | 2002-01-08 | 2003-07-17 | Seven Networks, Inc. | Secure transport for mobile communication network |
US20040158582A1 (en) * | 2003-02-11 | 2004-08-12 | Shuichi Takagi | Method and apparatus for synchronously transferring data from a local storage medium to a remote storage medium, and method and system for managing transfer of data from a source storage medium to a repository storage medium |
US9357033B2 (en) * | 2003-06-17 | 2016-05-31 | Citrix Systems, Inc. | Method and system for dynamic interleaving |
TWI234717B (en) * | 2003-12-04 | 2005-06-21 | Inst Information Industry | Method and system for dynamically determining web resource to be loaded and saving space |
US7673018B2 (en) | 2004-04-08 | 2010-03-02 | Research In Motion Limited | Message send queue reordering based on priority |
DK1585282T3 (da) * | 2004-04-08 | 2006-12-04 | Research In Motion Ltd | Genordning af meddelelsesafsendelseskö baseret på prioritet |
US7865511B2 (en) * | 2004-06-25 | 2011-01-04 | Apple Inc. | News feed browser |
US8023408B2 (en) * | 2004-11-19 | 2011-09-20 | International Business Machines Corporation | Dynamically changing message priority or message sequence number |
US8438633B1 (en) | 2005-04-21 | 2013-05-07 | Seven Networks, Inc. | Flexible real-time inbox access |
US8583827B2 (en) * | 2005-05-26 | 2013-11-12 | Citrix Systems, Inc. | Dynamic data optimization in data network |
US8943304B2 (en) | 2006-08-03 | 2015-01-27 | Citrix Systems, Inc. | Systems and methods for using an HTTP-aware client agent |
US9692725B2 (en) * | 2005-05-26 | 2017-06-27 | Citrix Systems, Inc. | Systems and methods for using an HTTP-aware client agent |
WO2006136660A1 (en) | 2005-06-21 | 2006-12-28 | Seven Networks International Oy | Maintaining an ip connection in a mobile network |
US8612844B1 (en) * | 2005-09-09 | 2013-12-17 | Apple Inc. | Sniffing hypertext content to determine type |
US8533350B2 (en) * | 2005-11-01 | 2013-09-10 | Ravenwhite Inc. | Method and apparatus for storing information in a browser storage area of a client device |
EP1796338A1 (de) * | 2005-12-07 | 2007-06-13 | Siemens Aktiengesellschaft | Verfahren zur Kommunikation eines Clients mit einem Server sowie Client und Server zur Durchführung dieses Verfahrens |
CN101432730B (zh) | 2006-05-05 | 2012-04-25 | 汤姆森许可贸易公司 | 在提供服务中使用的对服务请求进行调度的方法和设备 |
WO2008049425A1 (en) * | 2006-10-24 | 2008-05-02 | Medianet Innovations A/S | Method and system for firewall friendly real-time communication |
US9489456B1 (en) * | 2006-11-17 | 2016-11-08 | Blue Coat Systems, Inc. | Previewing file information over a network |
US7743160B2 (en) * | 2007-03-29 | 2010-06-22 | Blue Coat Systems, Inc. | System and method of delaying connection acceptance to support connection request processing at layer-7 |
US8805425B2 (en) | 2007-06-01 | 2014-08-12 | Seven Networks, Inc. | Integrated messaging |
US8521891B1 (en) * | 2007-06-21 | 2013-08-27 | Mcafee, Inc. | Network browser system, method, and computer program product for conditionally loading a portion of data from a network based on a data transfer rate |
KR100925644B1 (ko) | 2007-10-22 | 2009-11-06 | 에스케이 텔레콤주식회사 | 오브젝트 전송 시스템 및 그 제어방법 |
US9002828B2 (en) | 2007-12-13 | 2015-04-07 | Seven Networks, Inc. | Predictive content delivery |
US8862657B2 (en) | 2008-01-25 | 2014-10-14 | Seven Networks, Inc. | Policy based content service |
US20090193338A1 (en) | 2008-01-28 | 2009-07-30 | Trevor Fiatal | Reducing network and battery consumption during content delivery and playback |
US8850029B2 (en) * | 2008-02-14 | 2014-09-30 | Mcafee, Inc. | System, method, and computer program product for managing at least one aspect of a connection based on application behavior |
US9262357B2 (en) * | 2008-09-29 | 2016-02-16 | International Business Machines Corporation | Associating process priority with I/O queuing |
US8909759B2 (en) | 2008-10-10 | 2014-12-09 | Seven Networks, Inc. | Bandwidth measurement |
JP5669460B2 (ja) * | 2010-06-30 | 2015-02-12 | キヤノン株式会社 | 情報処理装置、情報処理システム、情報処理装置の制御方法及びプログラム |
US9043433B2 (en) * | 2010-07-26 | 2015-05-26 | Seven Networks, Inc. | Mobile network traffic coordination across multiple applications |
US8838783B2 (en) | 2010-07-26 | 2014-09-16 | Seven Networks, Inc. | Distributed caching for resource and mobile network traffic management |
CA2806549C (en) | 2010-07-26 | 2014-10-28 | Seven Networks, Inc. | Context aware traffic management for resource conservation in a wireless network |
EP2625655A4 (en) | 2010-10-06 | 2014-04-16 | Planet Data Solutions | SYSTEM AND METHOD FOR INDEXING ELECTRONIC DETECTION DATA |
WO2012060995A2 (en) | 2010-11-01 | 2012-05-10 | Michael Luna | Distributed caching in a wireless network of content delivered for a mobile application over a long-held request |
US8843153B2 (en) | 2010-11-01 | 2014-09-23 | Seven Networks, Inc. | Mobile traffic categorization and policy for network use optimization while preserving user experience |
US8868638B2 (en) | 2010-11-09 | 2014-10-21 | Usablenet Inc. | Methods for reducing latency in network connections using automatic redirects and systems thereof |
US8984164B2 (en) * | 2010-11-09 | 2015-03-17 | Usablenet Inc. | Methods for reducing latency in network connections and systems thereof |
CN103404193B (zh) | 2010-11-22 | 2018-06-05 | 七网络有限责任公司 | 调校数据传输以优化为通过无线网络的传输建立的连接 |
US8769000B2 (en) * | 2011-02-01 | 2014-07-01 | Microsoft Corporation | Adaptive network communication techniques |
US9009253B2 (en) * | 2011-02-16 | 2015-04-14 | Yahoo! Inc. | Optimizing server resources using multiple retry for high traffic websites |
WO2012125347A1 (en) * | 2011-03-11 | 2012-09-20 | Citrix Systems, Inc. | SYSTEMS AND METHODS OF QoS FOR SINGLE STREAM ICA |
GB2504037B (en) | 2011-04-27 | 2014-12-24 | Seven Networks Inc | Mobile device which offloads requests made by a mobile application to a remote entity for conservation of mobile device and network resources |
US20130104025A1 (en) * | 2011-10-20 | 2013-04-25 | Microsoft Corporation | Enabling immersive search engine home pages |
US9207754B2 (en) | 2011-10-20 | 2015-12-08 | Microsoft Technology Licensing, Llc | Enabling immersive, interactive desktop image presentation |
WO2013078687A1 (zh) * | 2011-12-02 | 2013-06-06 | 华为技术有限公司 | 一种内容分发网络路由方法、系统和用户终端 |
US8918503B2 (en) | 2011-12-06 | 2014-12-23 | Seven Networks, Inc. | Optimization of mobile traffic directed to private networks and operator configurability thereof |
WO2013086214A1 (en) | 2011-12-06 | 2013-06-13 | Seven Networks, Inc. | A system of redundantly clustered machines to provide failover mechanisms for mobile traffic management and network resource conservation |
GB2498064A (en) | 2011-12-07 | 2013-07-03 | Seven Networks Inc | Distributed content caching mechanism using a network operator proxy |
US9537899B2 (en) | 2012-02-29 | 2017-01-03 | Microsoft Technology Licensing, Llc | Dynamic selection of security protocol |
US9215127B2 (en) * | 2012-03-12 | 2015-12-15 | Network Coding, Inc. | Non-intrusive proxy system and method for applications without proxy support |
US8868762B1 (en) | 2012-03-23 | 2014-10-21 | Google Inc. | Efficient proximity detection |
US8812695B2 (en) | 2012-04-09 | 2014-08-19 | Seven Networks, Inc. | Method and system for management of a virtual network connection without heartbeat messages |
US8923204B2 (en) * | 2012-05-29 | 2014-12-30 | Alcatel Lucent | Message handling extension using context artifacts |
US9037926B2 (en) * | 2012-06-07 | 2015-05-19 | International Business Machines Corporation | Background buffering of content updates |
WO2014011216A1 (en) | 2012-07-13 | 2014-01-16 | Seven Networks, Inc. | Dynamic bandwidth adjustment for browsing or streaming activity in a wireless network based on prediction of user behavior when interacting with mobile applications |
JP6021487B2 (ja) | 2012-07-18 | 2016-11-09 | キヤノン株式会社 | 情報処理システム、制御方法、サーバ、情報処理装置およびコンピュータプログラム |
US9148383B2 (en) | 2012-07-31 | 2015-09-29 | International Business Machines Corporation | Transparent middlebox with graceful connection entry and exit |
US9311280B2 (en) * | 2012-08-27 | 2016-04-12 | Qualcomm Innovation Center, Inc. | Re-ordering of iFrame execution to reduce network activity window |
US8874761B2 (en) | 2013-01-25 | 2014-10-28 | Seven Networks, Inc. | Signaling optimization in a wireless network for traffic utilizing proprietary and non-proprietary protocols |
US9471533B1 (en) * | 2013-03-06 | 2016-10-18 | Amazon Technologies, Inc. | Defenses against use of tainted cache |
US9398066B1 (en) | 2013-03-06 | 2016-07-19 | Amazon Technologies, Inc. | Server defenses against use of tainted cache |
US8750123B1 (en) | 2013-03-11 | 2014-06-10 | Seven Networks, Inc. | Mobile device equipped with mobile network congestion recognition to make intelligent decisions regarding connecting to an operator network |
US9065765B2 (en) | 2013-07-22 | 2015-06-23 | Seven Networks, Inc. | Proxy server associated with a mobile carrier for enhancing mobile traffic management in a mobile network |
US9992263B2 (en) * | 2014-10-10 | 2018-06-05 | Pulse Secure, Llc | Predictive prioritized server push of resources |
CN106330845A (zh) * | 2015-07-02 | 2017-01-11 | 中兴通讯股份有限公司 | 一种传输流媒体数据的方法和装置 |
US20180063220A1 (en) * | 2016-08-30 | 2018-03-01 | Citrix Systems, Inc. | Systems and methods to provide hypertext transfer protocol 2.0 optimization through multiple links |
EP3772207B1 (en) * | 2019-08-01 | 2024-03-20 | ISS IP Holding LLC | Method and system for data transmission with significantly reduced latency losses |
Family Cites Families (28)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5046121A (en) * | 1989-01-31 | 1991-09-03 | Konica Corporation | Image data compression apparatus |
US6512791B1 (en) * | 1991-05-15 | 2003-01-28 | Canon Kabushiki Kaisha | Image processing apparatus having means for controlling exposure using an orthogonal transformation coefficient |
DE69616031T2 (de) * | 1995-12-21 | 2002-06-20 | Koninkl Philips Electronics Nv | Rauschreduzierung in einem bild |
US5778372A (en) * | 1996-04-18 | 1998-07-07 | Microsoft Corporation | Remote retrieval and display management of electronic document with incorporated images |
US5826031A (en) * | 1996-06-10 | 1998-10-20 | Sun Microsystems, Inc. | Method and system for prioritized downloading of embedded web objects |
US5675721A (en) * | 1996-08-08 | 1997-10-07 | Freedman; Aaron S. | Computer network data distribution and selective retrieval system |
US6421733B1 (en) | 1997-03-25 | 2002-07-16 | Intel Corporation | System for dynamically transcoding data transmitted between computers |
US6343085B1 (en) * | 1997-08-28 | 2002-01-29 | Microsoft Corporation | Adaptive bandwidth throttling for individual virtual services supported on a network server |
US6085193A (en) * | 1997-09-29 | 2000-07-04 | International Business Machines Corporation | Method and system for dynamically prefetching information via a server hierarchy |
US6266742B1 (en) * | 1997-10-27 | 2001-07-24 | International Business Machines Corporation | Algorithm for cache replacement |
US5987466A (en) * | 1997-11-25 | 1999-11-16 | International Business Machines Corporation | Presenting web pages with discrete, browser-controlled complexity levels |
US6769019B2 (en) * | 1997-12-10 | 2004-07-27 | Xavier Ferguson | Method of background downloading of information from a computer network |
US6154769A (en) * | 1998-03-27 | 2000-11-28 | Hewlett-Packard Company | Scheduling server requests to decrease response time and increase server throughput |
JPH11284683A (ja) * | 1998-03-30 | 1999-10-15 | Canon Inc | データ転送装置とデータの転送方法、及び情報処理システム |
US6144996A (en) * | 1998-05-13 | 2000-11-07 | Compaq Computer Corporation | Method and apparatus for providing a guaranteed minimum level of performance for content delivery over a network |
US6563517B1 (en) * | 1998-10-02 | 2003-05-13 | International Business Machines Corp. | Automatic data quality adjustment to reduce response time in browsing |
US6658485B1 (en) * | 1998-10-19 | 2003-12-02 | International Business Machines Corporation | Dynamic priority-based scheduling in a message queuing system |
US6389462B1 (en) | 1998-12-16 | 2002-05-14 | Lucent Technologies Inc. | Method and apparatus for transparently directing requests for web objects to proxy caches |
US6763371B1 (en) * | 1999-05-10 | 2004-07-13 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for collaborative communication in a communication network |
US7340499B1 (en) * | 1999-12-03 | 2008-03-04 | Sun Microsystems, Inc. | Dynamic embedding of literal object data in supplied instance of information object |
US20020073167A1 (en) * | 1999-12-08 | 2002-06-13 | Powell Kyle E. | Internet content delivery acceleration system employing a hybrid content selection scheme |
DE19964030A1 (de) * | 1999-12-30 | 2001-07-05 | Ibm | Effizientes Laden von Dokumenten auf dem Internet |
US7552233B2 (en) * | 2000-03-16 | 2009-06-23 | Adara Networks, Inc. | System and method for information object routing in computer networks |
US6925484B2 (en) * | 2000-03-29 | 2005-08-02 | Matsushita Electric Industrial Co., Ltd. | Dynamic proxy server apparatus |
US6954429B2 (en) * | 2000-04-05 | 2005-10-11 | Dyband Corporation | Bandwidth control system |
WO2001090912A1 (en) * | 2000-05-25 | 2001-11-29 | Qmgn, Inc. | Enhanced downloading from a computer network and profiling of a user of a computer network |
US7401118B1 (en) * | 2000-07-19 | 2008-07-15 | Hitachi, Ltd. | Web information preferential transfer system |
DE10049619A1 (de) * | 2000-10-05 | 2002-04-18 | Alcatel Sa | Verfahren zur Erbringung von Diensten in einem Netzwerk-Management-System mit einer offenen Systemarchitektur sowie Dienst-Objekt, Anforderungs-Objekt und Anforderungs-Manager hierzu |
-
2002
- 2002-04-05 CN CNB028287088A patent/CN100531186C/zh not_active Expired - Lifetime
- 2002-04-05 ES ES06000930T patent/ES2317348T3/es not_active Expired - Lifetime
- 2002-04-05 IL IL16388902A patent/IL163889A0/xx unknown
- 2002-04-05 AT AT06000930T patent/ATE413763T1/de not_active IP Right Cessation
- 2002-04-05 AU AU2002257754A patent/AU2002257754A1/en not_active Abandoned
- 2002-04-05 AT AT02727530T patent/ATE316312T1/de not_active IP Right Cessation
- 2002-04-05 EP EP06000930A patent/EP1650931B1/en not_active Expired - Lifetime
- 2002-04-05 PT PT02727530T patent/PT1493257E/pt unknown
- 2002-04-05 DE DE60229796T patent/DE60229796D1/de not_active Expired - Lifetime
- 2002-04-05 ES ES02727530T patent/ES2257543T3/es not_active Expired - Lifetime
- 2002-04-05 WO PCT/EP2002/003802 patent/WO2003085924A1/en active Application Filing
- 2002-04-05 DE DE60208786T patent/DE60208786T2/de not_active Expired - Lifetime
- 2002-04-05 EP EP02727530A patent/EP1493257B1/en not_active Expired - Lifetime
- 2002-04-05 US US10/509,979 patent/US7721294B2/en not_active Expired - Lifetime
- 2002-04-05 PT PT06000930T patent/PT1650931E/pt unknown
-
2004
- 2004-09-02 IL IL163889A patent/IL163889A/en active IP Right Grant
-
2008
- 2008-02-26 IL IL189779A patent/IL189779A/en active IP Right Grant
- 2008-11-24 US US12/276,780 patent/US20090077205A1/en not_active Abandoned
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2015052354A1 (es) * | 2013-10-07 | 2015-04-16 | Telefonica Digital España, S.L.U. | Procedimiento y sistema para definir el orden de obtención de recursos web por un navegador web |
Also Published As
Publication number | Publication date |
---|---|
ATE316312T1 (de) | 2006-02-15 |
PT1650931E (pt) | 2009-02-13 |
ATE413763T1 (de) | 2008-11-15 |
WO2003085924A1 (en) | 2003-10-16 |
US20090077205A1 (en) | 2009-03-19 |
IL163889A0 (en) | 2005-12-18 |
EP1650931B1 (en) | 2008-11-05 |
AU2002257754A1 (en) | 2003-10-20 |
EP1650931A1 (en) | 2006-04-26 |
IL189779A (en) | 2010-05-17 |
EP1493257B1 (en) | 2006-01-18 |
IL189779A0 (en) | 2008-08-07 |
US7721294B2 (en) | 2010-05-18 |
ES2317348T3 (es) | 2009-04-16 |
EP1493257A1 (en) | 2005-01-05 |
DE60208786T2 (de) | 2006-09-28 |
IL163889A (en) | 2010-02-17 |
DE60208786D1 (de) | 2006-04-06 |
DE60229796D1 (de) | 2008-12-18 |
PT1493257E (pt) | 2006-06-30 |
US20050240940A1 (en) | 2005-10-27 |
CN1625877A (zh) | 2005-06-08 |
CN100531186C (zh) | 2009-08-19 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
ES2257543T3 (es) | Control de transferencia de objeto en una red de comunicaciones. | |
KR100307374B1 (ko) | 지연을감소시키고사용자제어를향상시키기위한인터넷데이터전송의여과된사용 | |
CN101226525B (zh) | 控制web页面的下载和显示的方法、服务器、客户端及系统 | |
ES2415179T3 (es) | Sistema y método para actualizar una base de datos remota en una red | |
JP6323107B2 (ja) | スイッチ装置、情報処理システムおよびスイッチ装置の制御方法 | |
US20110145362A1 (en) | Method and system for preloading resources | |
JP4976121B2 (ja) | 移動通信ネットワークシステム及びサーバ装置 | |
JP2020529655A (ja) | プロキシベースのネットワーク通信における制御データのトランスポート | |
CN102937897B (zh) | 异步数据绑定 | |
CN105007238B (zh) | 轻量级跨平台消息中间件的实现方法及系统 | |
JP2009237768A (ja) | データ受信装置、データ受信方法およびデータ処理プログラム | |
ES2235662B2 (es) | Metodo para una interconexion mejorada de una aplicacion de usuario y un servidor. | |
CA2816338A1 (en) | Methods for reducing latency in network connections using automatic redirects and systems thereof | |
US9515777B2 (en) | Snoop virtual receiver time | |
US7000027B2 (en) | System and method for knowledgeable node initiated TCP splicing | |
US20220121725A1 (en) | Prefetching using a chain of fetch operations | |
WO2015052354A1 (es) | Procedimiento y sistema para definir el orden de obtención de recursos web por un navegador web | |
JP2002312262A (ja) | 遠隔要求を処理する方法および装置 | |
ES2270292T3 (es) | Reordenacion de una cola de envio de mensajes en base a la prioridad. | |
US20220150091A1 (en) | Apparatus for transmitting data over a bus system and operating method for that purpose | |
ES2291853T3 (es) | Gestion de direcciones en entornos basados en ip movil (mobile ip). | |
WO2009071718A1 (es) | Método de reducción del tiempo de descarga de páginas web | |
JP4664026B2 (ja) | コンピュータシステム、データ転送装置、及びデータ転送方法 | |
WO2003084136A1 (en) | Selectively routing data through a path based on connectivity conditions and parameters | |
CN109716315A (zh) | 使用报头修改的预取高速缓存管理 |