PT1650931E

PT1650931E - Prioridades de transferência de objectos numa rede de comunicações

Info

Publication number: PT1650931E
Application number: PT06000930T
Authority: PT
Inventors: Raphael Quinet; Daniel Schaffrath
Original assignee: Ericsson Telefon Ab L M
Priority date: 2002-04-05
Filing date: 2002-04-05
Publication date: 2009-02-13
Also published as: ES2257543T3; ATE316312T1; ATE413763T1; WO2003085924A1; US20090077205A1; IL163889A0; EP1650931B1; AU2002257754A1; EP1650931A1; IL189779A; EP1493257B1; IL189779A0; US7721294B2; ES2317348T3; EP1493257A1; DE60208786T2; IL163889A; DE60208786D1; DE60229796D1; PT1493257E

Description

ΕΡ 1 650 931/ΡΤ

DESCRIÇÃO "Prioridades de transferência de objectos numa rede de comunicações"

ANTECEDENTES DO INVENTO

Campo técnico 0 invento, em geral, refere-se ao campo de redes de comunicações e, mais em particular, a uma transferência de objecto de um primeiro componente de rede através de um componente intermédio para um segundo componente de rede, estando o segundo componente de rede distante do primeiro componente de rede.

Descrição da técnica anterior A transferência de informação através de redes de comunicação modernas como a Internet pública ou redes internas baseia-se em protocolos de transferência específicos. 0 World Wide Web por exemplo, que constitui um principal aspecto da Internet, utiliza o protocolo de transferência de hiper texto (HTTP) para trocar ficheiros que compreendem texto, imagens, som, vídeo e outros conteúdos.

Qualquer servidor WWW contém, para além dos ficheiros que o mesmo pode disponibilizar, um componente HTTP que está concebido para esperar por solicitações HTTP e processar as mesmas quando chegam. Um motor de busca WWW pode ser considerado como um cliente HTTP que está configurado para enviar solicitações HTTP para servidores WWW. Sempre que um utilizador do motor de busca introduz uma solicitação de ficheiro quer por "abertura" de um ficheiro WWW (ao digitar um localizador uniformizado de recursos (URL)) quer ao clicar numa ligação de hiper texto, o motor de busca constrói uma solicitação HTTP correspondente para o ficheiro e envia a mesma para o endereço de destino. O componente HTTP no servidor de destino recebe a solicitação HTTP e devolve o ficheiro solicitado. 2 ΕΡ 1 650 931/ΡΤ Ο ficheiro solicitado pode ser constituído por uma página de linguagem de marcação de hipertexto (HTML) que inclui código HTML. Quando o motor de busca recebe a página HTML do servidor e detecta que o código HTML, que pode ser considerado, ele próprio, como um objecto, inclui mais objectos tais como imagens (de fundo), sons, guiões ou quadros HTML, o motor de busca emite mais solicitações HTTP para o servidor a fim de pesquisar e carregar os objectos adicionais que estão incluídos no código HTML. Após a recepção das solicitações HTTP adicionais, o servidor envia respostas HTTP que incluem os objectos solicitados como imagens para o motor de busca. Como se torna evidente da Fig. 1, as respostas HTTP são enviadas do servidor para o motor de busca que corre no cliente pela mesma ordem que o motor de busca emitiu as solicitações HTTP. A ordem pela qual quaisquer objectos adicionais incluídos no código HTML da página HTML são solicitados pelo motor de busca depende do modo como a página HTML foi escrita. Por exemplo, um objecto que está incluído no início do código HTML não é necessariamente exibido no topo da página HTML devido a características tais como tabelas, níveis e quadros que permitem que o autor do HTML utilize configurações complexas. Além disso, a ordem pela qual um motor de busca emite solicitações HTTP depende também de algoritmos de motor de busca internos. Por exemplo alguns motores de busca utilizam heurísticas complexas para gerar as solicitações de HTTP ao iniciarem a solicitar os primeiros quatro objectos como aparecem no código HTML da página. Depois dos primeiros quatro objectos terem sido solicitados, são solicitados todos os segundos objectos que se iniciem a partir do topo da área que é visível no momento pelo utilizador, depois todos os quartos objectos e assim sucessivamente. Outros motores de busca utilizam algoritmos mais simples que solicitam os objectos um por um à medida que os mesmos aparecem no código HTML. Do referido acima fica evidente que é habitualmente difícil prever a ordem pela qual são geradas solicitações HTTP para objectos referidos num código HTML.

Para além disso, é difícil prever a ordem pela qual os objectos solicitados são recebidos pelo motor de busca. 3 ΕΡ 1 650 931/ΡΤ

Apesar da norma HTTP actual (HTTP/1.1) requerer que em cada ligação de protocolo de controlo de transferência (TCP) as respostas HTTP sejam enviadas do servidor para o motor de busca pela mesma ordem que as solicitações HTTP são recebidas pelo servidor, a ordem pela qual as respostas HTTP são recebidas torna-se imprevisível logo que mais do que uma ligação for aberta pelo servidor. A razão, por conseguinte, é o facto que devido à variação de condições de rede e diferentes tempos de processamento de solicitações, algumas ligações podem transferir respostas HTTP mais rápidas do que outras. A US 5987466 descreve um método de pesquisa no World Wide Web da Internet e apresenta elementos de uma página Web a um utilizador. O motor de busca Web solicita um HTML desejado e então solicita outros elementos da página com base em níveis de prioridade definidos pelo utilizador. Os elementos são apresentados ao utilizador em sequência de prioridade logo que recebidos.

Na US-A-6 144 996 um servidor "proxy" (serviço de rede de computadores que permite aos clientes fazerem ligações de rede indirectas a outros serviços de rede) é descrito como acelerando a transferência de objectos Web ao atrasar a entrega de uma página Web se o conteúdo da página não estiver totalmente armazenado localmente no procurador.

Existe uma necessidade de um método e de um dispositivo que permitam uma transferência melhorada de objectos de um primeiro componente de rede para um segundo componente de rede que esteja distante do primeiro componente de rede.

SUMÁRIO DO INVENTO A necessidade é satisfeita pelo ensinamento das reivindicações independentes. Concretizações preferidas adicionais são descritas nas reivindicações dependentes.

De acordo com um aspecto do invento esta necessidade é satisfeita por um método de controlar numa rede de comunicações uma transferência de objectos de um primeiro componente através de um componente intermédio (suporte 4

ΕΡ 1 650 931/PT físico ou suporte lógico) para um segundo componente que está distante do primeiro componente, em que a transferência do objecto é baseada numa pluralidade de solicitações de objecto relativas a objectos referidos num ou mais códigos a processar pelo segundo ou outro componente da rede de comunicações e em que o componente intermédio realiza os passos de enviar uma solicitação para o objecto ao primeiro componente, receber o objecto solicitado do primeiro componente, pelo menos um de avaliação e actualização de uma prioridade do objecto solicitado, em que uma prioridade inicial foi atribuída ao objecto solicitado com base numa análise de pelo menos uma solicitação de objecto e no código que se refere ao objecto solicitado e, em função da prioridade do objecto solicitado, atrasar o objecto solicitado ou transmitir o objecto solicitado para o segundo componente. Um objecto pode, por si próprio, compreender porções de código referentes a um ou mais objectos adicionais. Para além disso, um código pode, por si próprio, formar um objecto (por exemplo solicitado anteriormente).

Ao atrasar intencionalmente a transferência do objecto com base na prioridade atribuída, a transferência global de objectos é melhorada do ponto de vista de um utilizador (mesmo se a quantidade total de dados a transferir não for diminuída) devido aos objectos importantes serem transferidos preferencialmente. Para além disso, ao implementar esquemas de atribuição de prioridades adequados a transferência de objectos do primeiro componente de rede para o segundo componente de rede torna-se mais previsível. Por exemplo, pode ser atribuída maior prioridade a objectos que sejam de maior significado para o utilizador e, deste modo, serem transferidos com preferência para o segundo componente. Por outro lado, objectos que sejam de menor significado podem ser atrasados. No caso extremo, um objecto com baixo significado poder ser atrasado tanto que não é transferido para o segundo componente. Isto permite controlar a ordem pela qual os objectos são recebidos pelo segundo componente. A atribuição de prioridades absolutas ou relativas a objectos (ou classes de objectos) pode ser realizada de forma dinâmica. Uma vez atribuída a prioridade, esta prioridade pode ser avaliada em relação a valores absolutos específicos 5

ΕΡ 1 650 931/PT como limiares ou em relação a prioridades de outros objectos. Com base na avaliação pode ser decidido se um objecto se destina a ser atrasado ou não. Antes da avaliação uma prioridade inicialmente atribuída a um objecto pode ser avaliada de novo com a finalidade de determinar se a prioridade inicial tem de ser actualizada. 0 componente intermédio pode ser utilizado para reordenar objectos recebidos do primeiro componente. 0 atraso de objectos é, deste modo, realizado com preferência tal que a ordem pela qual o componente intermédio recebe os objectos do primeiro componente difere da ordem pela qual os objectos são transmitidos para o segundo componente. A reordenação pode ser baseada nas prioridades dos objectos a transferir. Durante a reordenação pode surgir a situação que devido ao atraso de alguns objectos a transferência de outros objectos seja na realidade acelerada. A solicitação de objecto que é enviada para o primeiro componente pode ser gerada pelo componente intermédio. Quando o objecto solicitado é recebido pelo componente intermédio, é "impelido" para o segundo componente sem ter recebido uma solicitação de objecto explícita do segundo componente. Em alternativa, a solicitação de objecto pode ser gerada pelo segundo componente e enviada para o componente intermédio. Após a recepção da solicitação de objecto do segundo componente, o mesmo pode ser processado pelo componente intermédio e transmitido para o primeiro componente.

Quando o componente intermédio recebe o objecto solicitado do primeiro componente, o objecto recebido pode ser atrasado ou transmitido directamente para o segundo componente. Existem várias possibilidades do objecto solicitado que é recebido pelo componente intermédio poder ser atrasado. 0 atraso do objecto solicitado pode, por exemplo, incluir pelo menos um de instrução do segundo componente para repetir a solicitação de objecto, suspensão de uma ligação ao segundo componente de rede através do qual o objecto solicitado se destina a ser transmitido e informação do segundo componente de que o objecto solicitado será automaticamente (por exemplo sem qualquer solicitação de 6

ΕΡ 1 650 931/PT objecto adicional do segundo componente) transmitido para o segundo componente mais tarde.

Se o atraso do objecto solicitado incluir a instrução do segundo componente para repetir a solicitação de objecto, o componente intermédio pode realizar os passos de atribuição de um atributo especifico ao objecto a atrasar, informação do segundo componente do atributo, recepção de uma referência para o atributo (por exemplo o próprio atributo ou uma referência ambígua derivada do atributo) do segundo componente e, após recepção da referência para o atributo, o envio do objecto atrasado para o segundo componente ou atrasando mais o objecto atrasado. A decisão se um objecto atrasado se destina a ser enviado para o segundo componente ou mais atrasado também pode ser baseada na prioridade relativa avaliada recentemente do objecto solicitado de forma repetida. 0 atributo pode ser considerado como um denominador comum que permite que o componente intermédio e o segundo componente negoceiem sobre a transferência do objecto ao qual o atributo foi atribuído. Habitualmente, a forma do atributo depende das características do protocolo de transferência que é utilizado para a transferência do objecto. No caso de HTTP por exemplo, o atributo pode ser constituído por um URL virtual criado pelo componente intermédio. Deverá ser notado que o esquema de atraso com base em atributo de instrução do segundo componente para repetir a solicitação de objecto pode, em geral, ser utilizado para atrasar objectos e não necessariamente solicitar que prioridades foram atribuídas aos objectos a transferir.

No esquema de atraso com base no atributo o objecto pode ser enviado do componente intermédio para o segundo componente em resposta a uma solicitação de objecto recebida do segundo componente ou de acordo com um esquema de impelir, isto é, de forma independente de uma solicitação de objecto deste tipo do segundo componente. Se o esquema de atraso for baseado numa solicitação de objecto recebida do segundo componente, o segundo componente pode ser informado sobre o atributo no contexto com uma instrução para repetir a solicitação de objecto. Num caso deste tipo a referência ao 7

ΕΡ 1 650 931/PT atributo pode ser recebida pelo componente intermédio no contexto com uma solicitação de objecto repetida do segundo componente.

Os objectos a transferir para o segundo componente podem ser transmitidos para o segundo componente através de uma única ligação ou através de uma pluralidade de ligações entre o componente intermédio e o segundo componente. Num cenário de múltiplas ligações deste tipo, as seleccionadas das ligações ao segundo componente podem ser suspensas em função das prioridades (inicial ou actualizada) dos objectos solicitados que se destinam a ser transmitidos através das seleccionadas das ligações ao segundo componente. 0 componente intermédio pode, deste modo, suspender uma ou mais ligações para que objectos que tenham uma prioridade elevada possam utilizar a largura de banda adicional que é liberta na ligação entre o componente intermédio e o segundo componente. A fim de não desperdiçar largura de banda disponível, o componente intermédio é, de preferência, configurado tal que o mesmo garante que uma ligação formada por duas ou mais ligações é completamente utilizada antes da suspensão de uma ou mais destas ligações.

Existem várias técnicas para suspender uma ligação. Por exemplo a transmissão através da ligação poderia ser bloqueada durante um período de tempo específico enquanto se deixaria a ligação como que aberta (estado intermédio = aberto). Em alternativa, a ligação poderia ser fechada (estado intermédio = fechado) enquanto se guarda o estado da ligação. Neste caso a ligação pode ser reaberta mais tarde no mesmo estado em que a mesma foi fechada. De acordo com uma terceira possibilidade, a ligação pode ser completamente fechada sem gravação de qualquer informação sobre o estado da ligação. Em qualquer caso o segundo componente pode ser informado que um ou mais objectos que se destinam a ser transmitidos através da ligação fechada serão enviados mais tarde, em resposta ou de forma independente de uma solicitação de objecto (repetida).

Em vez ou para além de suspender ligações individuais, a transferência de objectos pode ser também atrasada por uma prioridade com base no ajustamento da velocidade de 8

ΕΡ 1 650 931/PT transferência. Para aquele fim, uma partilha especifica de capacidades de processamento pode ser atribuída de forma dinâmica a cada objecto ou a cada ligação. No caso de ligações múltiplas, todas as ligações ou pelo menos algumas ligações obtêm uma partilha do tempo de CPU, isto é, uma partilha da largura de banda de rede. A partilha de capacidades de processamento atribuídas a uma ligação específica pode ser alterada (por exemplo diminuída de forma constante) enquanto um ou mais objectos são transferidos através da respectiva ligação.

Foi referido acima que a transferência de objectos é baseada numa pluralidade de solicitações de objectos relativas a objectos referidos num ou mais códigos. De acordo com uma primeira variante do invento um código está facilmente disponível para pelo menos um do segundo e do componente intermédio. De acordo com uma segunda variante do invento o código tem ainda de ser carregado por qualquer um do segundo e do componente intermédio. No último caso o componente intermédio pode enviar uma solicitação de código que foi gerada pelo segundo componente ou pelo componente intermédio para o primeiro componente ou um terceiro componente que é diferente do primeiro componente. Quando o código solicitado é recebido do primeiro componente ou do terceiro componente, o mesmo pode ser analisado pelo componente intermédio em relação a referências a objectos compreendidos no código. Quaisquer referências a objectos contidos no código podem ser então avaliadas com a finalidade de atribuir prioridades (iniciais) aos objectos referidos no código recebido. 0 código recebido do primeiro ou do terceiro componente pode eventualmente ser transmitido pelo componente intermédio para o segundo componente.

Após a recepção de uma resposta do primeiro componente o objecto solicitado contido na resposta pode ser avaliado em relação à prioridade do objecto recebido. Por exemplo, pelo menos um de dimensão do objecto, conteúdo do objecto e um cabeçalho da resposta pode ser analisado para aquele fim. Pode então ser determinado se uma prioridade inicial de um objecto recebido foi actualizada ou não. 9 ΕΡ 1 650 931/ΡΤ

De preferência, pelo menos alguma informação sobre cada objecto ou cada classe de objectos é armazenada por exemplo pelo componente intermédio. A informação armazenada pode compreender informação prioritária para objectos individuais ou para uma classe de objectos, de preferência, na forma de uma lista de prioridades. Esta lista de prioridades pode ser avaliada de forma repetida. Uma avaliação deste tipo pode relacionar pelo menos um de informação de prioridade de actualização e apagar objectos ou classes de objectos da lista de prioridades. O invento pode ser implementado como uma solução de suporte físico ou uma solução de suporte lógico. No caso de uma solução de suporte lógico o invento pode ser concretizado na forma de um produto informático que compreende porções de código informático para realizar os passos individuais do invento. O produto informático pode ser armazenado num meio de gravação de leitura por computador.

De acordo com uma concretização preferida do invento o componente intermédio é implementado como um componente procurador na forma de uma peça de suporte lógico que corre no primeiro ou no segundo componente da rede de comunicações. Se o invento for implementado como uma solução de suporte físico, o componente intermédio pode ser constituído por uma peça separada de suporte físico como um servidor "proxy" disposto entre o primeiro componente e o segundo na rede de comunicações. O componente intermédio pode incluir um ou mais interfaces de comunicação configurados de forma adequada para comunicação com, pelo menos, o primeiro e o segundo componentes da rede de comunicações bem como com uma unidade para realizar o processamento no contexto com atraso de objectos.

Na rede de comunicações existe uma primeira ligação entre o componente intermédio e o primeiro componente e uma segunda ligação entre o componente intermédio e o segundo componente. De preferência, a primeira ligação e a segunda ligação têm velocidades de transferência diferentes. Por exemplo, uma ligação rápida pode ser prevista entre o componente intermédio e o primeiro componente e uma ligação comparativamente mais lenta pode ser prevista entre o 10

ΕΡ 1 650 931/PT componente intermédio e o segundo componente. Esta situação, habitualmente, dá-se quando o primeiro componente é um servidor de rede, o segundo componente é um cliente de rede e o componente intermédio está localizado na vizinhança (em termos de ligações de rede) ou no servidor de rede. No entanto, o componente intermédio também poderia estar localizado próximo (em termos de ligações de rede) ou no cliente de rede. Neste tipo de caso a ligação entre o componente intermédio e o segundo componente (o cliente de rede) tem uma capacidade muito maior e latência inferior do que a ligação entre o componente intermédio e o primeiro componente (o servidor de rede).

Deverá ser notado que o invento não se restringe ao caso em que o primeiro componente actua como servidor de rede e o segundo componente actua como cliente de rede. Em particular, o componente intermédio poderia também ser utilizado para melhorar a transferência de objectos entre dois clientes de rede ou dois servidores de rede.

De acordo com uma concretização, especialmente preferida, do invento, o componente intermédio é parte de uma rede de comunicações sem fios como uma rede celular GSM, GPRS, etc. Numa rede deste tipo o segundo componente pode ser constituído por um terminal móvel.

BREVE DESCRIÇÃO DOS DESENHOS

Mais aspectos e vantagens do invento serão evidentes após a leitura da seguinte descrição detalhada de concretizações preferidas do invento e após referência aos desenhos, em que: a Fig. 1 é um diagrama esquemático que ilustra uma transferência de objectos entre um servidor de rede e um cliente de rede de acordo com HTTP; a Fig. 2 é um diagrama de blocos de um sistema de rede que compreende um componente intermédio na forma de um servidor "proxy" HTTP de acordo com o invento; 11 ΕΡ 1 650 931/ΡΤ a Fig. 3 é um diagrama de blocos do servidor HTTP da Fig. 2; a Fig. 4 é um diagrama esquemático que representa um atraso de objecto com base em redireccionamento no sistema de rede representado na Fig. 2; a Fig. 5 é um fluxograma que reflecte os passos que precedem um atraso de objecto; a Fig. 6 é um fluxograma que representa as decisões envolvidas numa transferência de objecto de acordo com o invento; e a Fig. 7 é um diagrama de blocos que representa um componente procurador de acordo com o invento localizado num cliente de rede.

DESCRIÇÃO DE UMA CONCRETIZAÇÃO PREFERIDA

Apesar do presente invento poder ser concretizado em qualquer rede de comunicações em que uma transferência de objecto com base em solicitação através de um componente intermédio seja realizada, a seguinte descrição de concretizações preferidas é expressa de forma exemplificativa em relação à transferência de código HTML de acordo com o protocolo HTTP sobre WWW. Em principio, protocolos de transferência diferentes de HTTP, tipo protocolo de transporte WAP sem fios ou alguns mecanismos de chamada de procedimento remoto (RCP) e códigos diferentes de HTML, por exemplo a linguagem de marcação WAP (WML) ou quaisquer derivadas da linguagem de marcação extensível (XML), também poderiam ser utilizados. Para além disso, apesar da seguinte descrição referir-se principalmente a uma transferência de objectos de um servidor para um cliente, a transferência de objectos poderia ser realizada entre quaisquer dois ou mais componentes de rede.

Na Fig. 2 representa-se um diagrama de blocos de um sistema de rede 10 de acordo com o invento. Como é evidente da Fig. 2, o sistema de rede 10 compreende um primeiro componente na forma de um servidor 20, um componente 12

ΕΡ 1 650 931/PT intermédio na forma de um servidor "proxy" HTTP 3 0 e um segundo componente na forma de um cliente 40. O servidor "proxy" 30 está arquitectado no sistema de rede 10 tal que o mesmo tem uma ligação rápida 12 para o servidor 20 e uma ligação comparativamente mais lenta 14 para o cliente 40. Cada ligação 12, 14 é constituída por uma pluralidade de ligações TCP 50. Cada ligação TCP 50 está configurada para permitir a transferência de solicitações HTTP e respostas HTTP entre o servidor 20 e o cliente 40. O servidor 30 realiza algumas funções de procurador tradicionais como colocação em memória intermédia e filtragem de objectos. Para além disso, o servidor "proxy" 30 está configurado para atrasar de forma artificial um objecto que é recebido do servidor 20 e que é transmitido para o cliente 40. Isto é feito através da utilização de uma combinação de suspensão temporária de transferência de dados em algumas direcções 50 e mensagens de redireccionamento HTTP que forçam um motor de busca a correr no cliente 40 a repetir um objecto solicitado depois de um certo período de tempo. Através da utilização destes mecanismos o servidor "proxy" 30 reordena as respostas HTTP recebidas do servidor 20 de uma forma tal que objectos com uma prioridade mais alta são entregues primeiro ao cliente 40. Para este objectivo o servidor "proxy" 30 atribui, de forma dinâmica, prioridades aos objectos a transmitir para o cliente 40. A fim de garantir que o atraso dos objectos menos importantes não leva a que a ligação 14 entre o servidor "proxy" 30 e o cliente 40 fique em vazio, o servidor "proxy" 30 de forma continua, ou pelo menos de forma repetida, monitoriza o tráfego nesta ligação 14. A estrutura do servidor "proxy" 30 está representada em mais detalhe na Fig. 3. Como é evidente da Fig. 3, o servidor "proxy" 30 compreende uma interface de comunicações 32 ligada entre a primeira ligação 12 para o servidor 20 e a segunda ligação 14 para o cliente 40. A interface de comunicações 32 está configurada de modo que a mesma permite o envio de solicitações de objectos e a recepção dos objectos solicitados do servidor 20. Uma unidade de processamento 34 do servidor "proxy" 30 comunica com a interface de comunicações 32. A unidade de processamento 34 permite 13 ΕΡ 1 650 931/ΡΤ avaliar e/ou adaptar a prioridade de qualquer objecto recebido através da primeira ligação 12 do servidor 20. Além disso, a unidade de processamento 34 permite atribuir uma prioridade inicial a um objecto solicitado com base numa análise de pelo menos uma solicitação de objecto e do código que se refere ao objecto solicitado. Esquemas de atribuição possíveis serão explicados posteriormente em mais detalhe.

Em função da prioridade inicial ou actualizada de um objecto solicitado a unidade de processamento 34 controla a interface de comunicações 32 de modo que um objecto solicitado recebido do servidor 20 é atrasado ou transmitido através da segunda ligação 14 para o cliente 40. Se um objecto solicitado recebido do servidor 20 se destina a ser atrasado, o mesmo é temporariamente armazenado numa memória temporária 36 que pode ser acedida tanto pela interface de comunicações 32 como pela unidade de processamento 34. Em alternativa, ou além disso, a memória intermédia 36 pode ser implementada como um componente de suporte lógico ou um componente de suporte físico da unidade de processamento 34.

Para além das tarefas expressas acima, a unidade de processamento 34 está também configurada de modo que a mesma permite atribuir um atributo específico a um objecto que se destina a ser atrasado (um formato exemplificativo deste atributo será explicado mais tarde em maior detalhe). A unidade de processamento 34 permite controlar a interface de comunicações 32 tal que a interface de comunicações 32 informa o cliente 40 sobre este atributo. Se a interface de comunicações 32 recebe uma referência para o atributo do cliente 40, a unidade de processamento 34 avalia esta referência e controla a interface de comunicações 32 de modo que o objecto atrasado a que este atributo foi anteriormente atribuído e que está no momento armazenado na memória temporária 36 é enviado para o cliente 40 ou mais atrasado. Um atraso adicional do objecto armazenado na memória temporária 36 pode tornar-se necessário se objectos de maior prioridade tiverem de ser transmitidos para o cliente 40 primeiro. 14

ΕΡ 1 650 931/PT A seguir, um modo operacional preferido do sistema de rede 10 mostrado na Fig. 2 será descrito de forma exemplificativa.

Quando um utilizador introduz um URL, clica numa ligação ou segue um marcador, o motor de busca que corre no cliente 40 emite uma solicitação de HTTP para a página HTML correspondente que inclui o código HTML. A solicitação HTTP emitida pelo motor de busca é recebida pelo servidor "proxy" 30 através da ligação 14 e transmitida através da ligação 12 para o servidor de destino 20. 0 servidor 20 responde através do envio do código HTML para a página solicitada para o servidor "proxy" 30, que analisa o código HTML recebido do servidor 20 para atribuir uma prioridade inicial a qualquer espécie de objectos como ligações, quadros, guiões, imagens, etc. referidos no código HTML (primeira fase de análise).

Independentemente desta análise do código HTML, o servidor "proxy" 30 transmite o código HTML através da ligação 14 para o cliente 40. Quando o motor de busca que corre no cliente 40 recebe a página HTML que inclui o código HTML processa o código HTML. Se o motor de busca detecta que o código HTML inclui mais objectos, emite mais solicitações HTTP para os objectos referidos no código HTML. Estas solicitações HTTP para objectos adicionais são recebidas e avaliadas pelo servidor "proxy" 30. Para a maior parte dos objectos solicitados uma prioridade inicial já foi atribuída durante a análise anterior do servidor "proxy" 30 do código HTML que foi transmitido para o servidor 40. No entanto, nesta segunda fase de análise o servidor "proxy" 30 atribui prioridades iniciais àqueles objectos aos quais ainda não foi atribuída uma prioridade ou actualiza a prioridade àqueles objectos a que já foi atribuída uma prioridade inicial. A prioridade é actualizada com base em informação adicional disponível na solicitação HTTP recebida do cliente 40. O servidor "proxy" 30 transmite quaisquer solicitações HTTP para objectos adicionais recebidos do cliente 40 para o servidor 20. O servidor 20 responde através do envio dos objectos solicitados para o servidor "proxy" 30. O servidor "proxy" 30 analisa as respostas HTTP (que incluem os objectos solicitados) do servidor 20 numa terceira fase de análise e 15

ΕΡ 1 650 931/PT actualiza - se necessário - as prioridades dos objectos incluídos na resposta HTTP. Para além disso, o servidor "proxy" 30 avalia a prioridade relativa de qualquer objecto recebido em relação à prioridade de objectos recebidos anteriormente que estão ainda armazenados na memória temporária 36 (ver Fig. 3) e as prioridades de objectos que são esperados em breve. A informação relativa a objectos que serão recebidos em breve do servidor 20 pode ser obtida do código HTML que foi anteriormente transmitido para o cliente 40 ou a partir de solicitações HTTP do cliente 40 cujos objectos correspondentes não foram ainda recebidos do servidor 20. Em alternativa ou além disso, o servidor "proxy" 30 pode ser configurado de tal modo que o mesmo compara uma prioridade de um objecto que acabou de ser recebido do servidor 40 com um valor absoluto como um limiar de prioridade.

Com base na avaliação de uma prioridade absoluta e/ou relativa e no tráfego actual e/ou estimado na ligação 14, o servidor "proxy" 30 decide se este objecto tem de ser atrasado, por exemplo se este objecto tem de ser armazenado temporariamente na memória temporária 36 ou se a solicitação HTTP correspondente não se destina ainda a ser transmitida para o servidor 20 ou se o objecto tem de ser transmitido imediatamente para o cliente 40. O atraso intencional de objectos individuais melhora a transferência global de objectos do ponto de vista de um utilizador. É, por exemplo, bem conhecido que a importância relativa dos vários objectos incluídos numa página Web varia muito: Uma imagem que é utilizada para construir um menu gráfico pode ser essencial para a navegação de um sítio, enquanto que uma imagem de fundo apenas faz a página parecer com melhor aspecto. O invento pode, deste modo, ser empregue para munir primeiro o utilizador com a informação mais importante. Logo que exista informação suficiente de uma página Web exibida no ecrã do utilizador, o utilizador pode decidir clicar numa ligação e solicitar outra página Web sem ter de esperar pelas partes restantes (menos importantes) da página Web anterior que ainda estão a ser transferidas. Em consequência, o utilizador deixa de ser forçado a esperar por alguns objectos sem interesse até que os mesmos sejam 16

ΕΡ 1 650 931/PT transferidos antes de poder ver os importantes. Isto é especialmente útil em conjunto com a Internet móvel, que é habitualmente mais lenta e mais cara do que a Internet fixa.

Atribuição e ajustamento de prioridades

Como ficou evidente do referido acima, o servidor "proxy" 30 pode atribuir ou ajustar a prioridade de um objecto a enviar para o cliente 20 durante três fases diferentes, designadamente quando uma referência àquele objecto é encontrada num código HTML (isto é um objecto anterior) que é transmitido para o cliente 40, quando uma solicitação HTTP relativa àquele objecto é emitida pelo motor de busca que corre no cliente 40 ou quando a resposta HTTP correspondente que contém o objecto solicitado é recebida do servidor 2 0. A seguir, vários esquemas para atribuição ou actualização de prioridades durante cada uma destas três fases são descritos de forma exemplificativa. Durante quaisquer das três fases uma lista de prioridades que contém informação de prioridade para objectos individuais ou classes de objectos é gerada ou actualizada. Na lista de prioridades, os objectos individuais ou classes de objectos são ordenados por ordem crescente ou decrescente de prioridade. A ordem dos objectos na lista de prioridades pode, deste modo, ser considerada como informação de prioridade. No entanto, informação de prioridade adicional tipo valores absolutos ou relativos (números) pode em alternativa ou de forma complementar ser parte da lista de prioridade. A prioridade exacta atribuída a objectos específicos ou classes de objectos é dependente da implementação e na concretização exemplificativa configurável pelo operador do servidor "proxy" 30 ou por um utilizador do motor de busca que corre no cliente 40. Por exemplo a fim de permitir que o operador do servidor "proxy" 20 tenha mais controlo sobre a prioridade de alguns objectos, poderá existir uma ou várias listas de URL (com utilização de correspondência de padrão) que permitem que o operador aumente ou diminua a prioridade dos objectos que aparecem naquelas listas. Por exemplo, um operador poderia decidir aumentar ou diminuir a prioridade de 17 ΕΡ 1 650 931/ΡΤ todas as imagens descarregadas de uma empresa de anúncios. As mesmas possibilidades podem ser disponibilizadas ao utilizador. Por exemplo o utilizador poderia enviar as suas preferências para o servidor "proxy" 30. Isto pode ser realizado através de um suporte lógico especifico que corra no cliente 40 ou através da utilização de designadas páginas Web disponibilizadas directamente pelo servidor "proxy" 30 e que permitam que o utilizador defina as suas preferências.

Na primeira fase de análise o servidor "proxy" 30 pode atribuir uma prioridade inicial a um objecto através da análise de um código HTML que foi solicitado pelo cliente 40 a partir do servidor 20. Em particular, referências a objectos referidos no código HTML podem ser avaliadas para aquele fim. Desta forma uma lista de prioridades pode ser gerada que lista objectos individuais que estejam referidos no código HTML pela ordem seguinte (objectos de maior prioridade são referidos primeiro): - ligações para outras páginas - quadros - imagens em linha (se a etiqueta IMG incluir informação de largura e altura, esta informação pode ser utilizada para melhorar a prioridade de imagens em função das dimensões esperadas para que imagens mais pequenas obtenham maior prioridade do que as maiores) - folhas de estilo - guiões (guiões Java, guiões VBS, etc.), objectos e aplicações incorporadas - imagem de fundo (fundo de página, fundo de tabela, folha de estilo, etc.) - qualquer objecto que já foi enviado para o cliente 40 adquire a prioridade mais baixa 18

ΕΡ 1 650 931/PT

Além disso, a prioridade de um objecto especifico pode ser reduzida se o objecto não estiver localizado no mesmo servidor 20 ou no mesmo domínio da página HTML actual.

Uma possibilidade adicional de atribuir ou ajustar a prioridade de um objecto ocorre quando uma solicitação para aquele objecto é emitida pelo motor de busca e recebida pelo servidor "proxy" 30. Nestes casos a solicitação HTTP pode ser analisada pelo servidor "proxy" 30 num contexto URL (segunda fase de análise) . Uma vez que as prioridades iniciais foram atribuídas durante a análise do código HTML que levou àquela solicitação HTTP, a análise da solicitação HTTP resulta habitualmente num ajustamento da prioridade inicial. No entanto, nalguns casos as prioridades iniciais também podem ser atribuídas (ver abaixo). O ajustamento ou atribuição de prioridades iniciais na segunda fase de análise pode ser realizada em função da informação adicional disponível, por exemplo, no cabeçalho da solicitação HTTP. Podem ser implementadas uma ou mais das seguintes regras indicadas abaixo para actualização das prioridades. - A análise leva ao resultado de que o motor de busca já solicitou o mesmo objecto uma vez. Uma prioridade muito elevada é, de preferência, atribuída a um objecto destes a fim de evitar ciclos infinitos provocados pelos motores de busca que não estão completamente em conformidade com HTTP/1.1 e ignoram o cabeçalho Repetir-Depois (este cabeçalho será explicado abaixo em maior detalhe). - O objecto não tem ainda uma prioridade, mas a extensão do ficheiro parece HTML (".HTML",".HTM") ou XML (". XML") ou parece ser do tipo índice de directoria (termina com "/"). Uma atribuição de prioridade deste tipo garante que uma página HTML solicitada das marcações ou digitada directamente será solicitada com uma prioridade elevada. - O motor de busca faz uma solicitação HTTP condicional para um objecto, através da utilização de "se 19

ΕΡ 1 650 931/PT modificado desde" que ou condições semelhantes. Isto indica que o motor de busca provavelmente tinha colocado em memória intermédia uma cópia do objecto. Espera-se que a resposta seja pequena se a cópia em memória intermédia for ainda válida (código de resposta HTTP "304 não modificado"). - 0 URL do objecto solicitado foi encontrado durante a análise de uma página HTML anterior. - Qualquer objecto que não foi inserido na lista durante a análise das etiquetas HTML de uma página anterior foi provavelmente solicitado de forma indirecta por um guião e deverá obter uma mais baixa do que a maior parte dos outros objectos solicitados.

Na terceira fase de análise, o ajustamento das prioridades de objectos é baseado numa análise da resposta HTTP do servidor 20. O ajustamento das prioridades na terceira fase de análise (bem como na segunda fase de análise referida acima) pode ser calculada como uma soma ponderada de vários critérios. As ponderações podem ser configuráveis pelo operador do servidor "proxy" 30 ou pelo utilizador do motor de busca que corre no cliente 40.

Na terceira fase de análise, todos os objectos terão habitualmente uma prioridade atribuída aos mesmos. No entanto, esta prioridade pode ser actualizada antes do envio dos objectos solicitados para o cliente 40. Para ajustar as prioridades, os cabeçalhos e conteúdos das respostas HTTP recebidas do servidor 20 podem ser avaliados. As prioridades podem, então, ser ajustadas de acordo com uma ou mais das seguintes regras indicadas abaixo. - Avaliação do código de resposta: a prioridade relativa das respostas HTTP depende do primeiro dígito do código de resposta. Os códigos de erro (4xx, 5xx) deverão ter uma prioridade superior às respostas normais (2xx). - Avaliação do tipo de conteúdo: um código HTML deverá ter uma prioridade superior à de qualquer imagem. 20 ΕΡ 1 650 931/ΡΤ - Avaliação da dimensão dos objectos (obtida do comprimento ou conteúdo se especificado nos cabeçalhos ou da dimensão total se o objecto já estiver em memória intermédia): os objectos inferiores deverão ter uma prioridade ligeiramente superior à dos outros. - Análise do conteúdo: por exemplo pode ser atribuída uma mais baixa do que as imagens animadas do que a imagens estáticas. A análise do conteúdo também pode formar a base para a estimativa da dimensão do objecto se esta informação não estiver disponível no cabeçalho HTTP e o objecto não tiver ainda sido colocado em memória intermédia. - Se o código de resposta for um redireccionamento permanente ou temporário (3xx) que especifique uma nova localização para o objecto solicitado, então esta nova localização adquire a mesma prioridade do objecto inicial.

Nas três fases de análise descritas acima o servidor "proxy" 30 define e actualiza as prioridades dos objectos a transferir para o cliente 40. 0 servidor "proxy" 30 mantém assim alguma informação sobre cada objecto como o URL do objecto, a prioridade, tempo da última solicitação e, se necessário, mais alguns parâmetros. No entanto, esta informação não pode ser mantida para sempre uma vez que, de outro modo, o servidor "proxy" 30 ficaria sem memória. Para além disso, se um objecto ao qual foi atribuída uma prioridade elevada nunca for solicitado, é, de preferência, tomada alguma acção para que o mesmo não impeça outros objectos de serem transferidos.

Por estas razões é implementada uma rotina que garante que informação que deixou de estar actualizada ou que deixou de ser necessária seja eliminada. Para aquele fim podem ser utilizados um ou mais dos mecanismos seguintes, indicados abaixo.

Qualquer objecto que seja transferido com sucesso para o cliente é marcado como tendo sido enviado ou é 21

ΕΡ 1 650 931/PT deslocado para uma lista separada de objectos que foram enviados para o cliente 40. - Uma dimensão máxima para uma ou mais listas que contenham informação relevante é definida e configurada de modo que objectos mais antigos ou objectos com a mais baixa expirem primeiro. - Sempre que o cliente reinicializa uma ligação TCP antes do objecto ser completamente transferido (o que significa que o utilizador parou de descarregar e pode ter seleccionado outra página), eliminar a informação de objectos a enviar. - Como uma alternativa à solução anterior, manter referências para cada objecto a fim de associar cada página HTML aos objectos que a mesma contém e vice-versa. Quando o cliente 40 reinicializa uma ligação TCP, remover apenas os objectos que estão incluídos na mesma página HTML. - A prioridade de todos os objectos pode ser diminuída depois de uma quantidade específica de tempo ou depois de algum número de solicitações HTTP ou respostas HTTP terem sido processadas.

Reordenação de objectos

No capítulo anterior, a geração de uma lista de prioridades para os objectos solicitados para serem transferidos para o cliente 40 bem como possíveis mecanismos de actualização para esta lista de prioridades foram descritos. Habitualmente, os objectos solicitados são recebidos pelo servidor "proxy" 30 a partir do servidor 20 numa ordem que é diferente da ordem indicada na lista de prioridades. Em consequência, o servidor "proxy" 30 tem de reordenar os objectos recebidos do servidor 20 de uma forma tal que os mesmos são transmitidos do servidor "proxy" 30 para o cliente 40 numa ordem que reflecte a ordem na lista de prioridades tão próximo quanto possível. O servidor "proxy" 30 reordena os objectos recebidos do servidor 20 ao atrasar de forma intencional objectos que tenham uma mais baixa e ao 22 ΕΡ 1 650 931/ΡΤ transmitir objectos que tenham uma prioridade superior sem qualquer atraso substancial para o cliente 40. 0 servidor "proxy" 30 utiliza uma combinação de diferentes mecanismos de atraso para reordenar os objectos recebidos do servidor 20. A seguir, dois destes mecanismos de atraso, designadamente suspensão de ligações TCP por um lado e redireccionamentos HTTP por outro lado, serão descritos de forma exemplificativa em maior detalhe.

Suspensão das ligações TCP

Como fica evidente da Fig. 2, a ligação 14 entre o servidor "proxy" 30 e o cliente 40 é constituída por uma pluralidade de ligações TCP 50. Em função das prioridades dos objectos solicitados para serem transmitidos através das ligações individuais das ligações 50, uma ou mais das ligações 50 que se destinam à transferência de objectos com uma mais baixa são suspensas. Esta suspensão de ligações individuais liberta alguma largura de banda na ligação 14 que fica assim disponível para transferir, de preferência, objectos com uma prioridade mais alta. Em consequência, objectos com uma prioridade mais alta serão entregues antes de objectos com uma mais baixa. A suspensão de uma ligação individual 50 é realizada de tal modo que a ligação 50 é deixada aberta sem transferência de objectos durante um certo período de tempo. Em alternativa, a suspensão de uma ligação 50 poderia ser efectuada através do fecho da ligação 50, com ou sem guardar o estado da ligação 50 antes da sua suspensão. Quando o estado da ligação suspensa 50 for guardado, a mesma pode ser aberta mais tarde no mesmo estado em que tinha sido suspensa (isto é fechada). A suspensão de uma ligação 50 tem a vantagem de dados extra não terem sido enviados através da ligação 14. De preferência, uma ligação 50 é suspensa apenas se a largura de banda libertada poder ser completamente utilizada por alguma das outras ligações 50 para a transferência de objectos com uma prioridade mais alta. 23

ΕΡ 1 650 931/PT Ο servidor "proxy" 30 é, assim, configurado de tal modo que o mesmo verifica se a ligação 14 está completamente utilizada antes de suspender uma ligação 50 a fim de não desperdiçar largura de banda disponível. Uma possível rotina para determinar se a ligação 14 está ou estará parcialmente em vazio inclui a comparação do débito médio (nos últimos N segundos) de todas as ligações 50 que vão para o cliente 40 com a quantidade de dados que estão no momento em memória intermédia ou armazenados de forma temporária na memória temporária 36 do servidor "proxy" 30 (ver Fig. 3) e prontos para serem enviados. Outras, e em particular, técnicas mais simples para estimar a utilização da ligação 14 poderiam ser também implementadas, em especial se a largura de banda disponível na ligação 14 for conhecida por outros meios.

Redireccionamentos de HTTP

Se o servidor "proxy" 30 esperar que objectos com uma prioridade elevada tenham de ser transferidos em breve para o cliente 14 (por exemplo devido a ligações a estes objectos terem sido anteriormente detectadas pelo servidor "proxy" 30 enquanto transmitiam o código HTML de uma página HTML para o cliente 40) e a suspensão de uma ligação 50 desperdiçaria alguma largura de banda devido a no momento não existir algo para transferir sobre as outras ligações 50, então o servidor "proxy" 30 pode utilizar outro esquema de atraso. Um esquema de atraso possível que é aplicável num caso deste tipo inclui a instrução do cliente 40 para repetir uma solicitação de objecto mais tarde.

Apesar do HTTP especificar que quaisquer respostas HTTP têm de ser enviadas para o cliente 40 pela mesma ordem em que o motor de busca que corre no cliente 40 emitiu as solicitações HTTP, é possível instruir o motor de busca para repetir uma solicitação HTTP mais tarde. Isto pode ser efectuado através do envio de uma resposta HTTP com o código de estado "302" para o cliente 40, em conjunto com o campo de cabeçalho "Repetir-Depois". Este campo de cabeçalho diz ao cliente 40 para repetir esta solicitação HTTP depois de uma quantidade específica de tempo. Em resposta à recepção do código de estado "302" (possivelmente com a inclusão do campo de cabeçalho "Repetir-Depois") , os motores de busca actuais 24

ΕΡ 1 650 931/PT reagendam a solicitação HTTP depois de todas as solicitações HTTP pendentes terem sido processadas. 0 código de estado "302" como especificado na norma HTTP 1.1 diz ao motor de busca que um dado objecto pode ser encontrado (temporariamente) numa localização que é diferente daquela em que foi solicitado. A resposta HTTP enviada ao cliente 40 inclui a nova localização do objecto. Este mecanismo é utilizado para implementar o esquema de atraso de acordo com o invento.

De acordo com o invento o servidor "proxy" 30 gera um atributo na forma de um novo URL (virtual) para o objecto a atrasar. O servidor "proxy" 30 então instrui o motor de busca que corre no cliente 40 para tentar novamente a solicitação HTTP, através da utilização deste atributo temporário (isto é URL) como a nova localização do objecto. O motor de busca é, assim, instruído para reagendar a solicitação HTTP para um momento posterior. Quando o motor de busca repete a sua solicitação HTTP (que inclui o atributo temporário, isto o URL virtual), o servidor "proxy" 30 converte o atributo para o URL original e transmite a solicitação HTTP para o servidor 20. Em alternativa, a solicitação HTTP original pode ter sido transmitida para o servidor 20 depois de recebida do mesmo pelo servidor "proxy" 30. Num caso destes a resposta HTTP recebida do servidor 20 é armazenada temporariamente pelo servidor "proxy" 30 até que o mesmo receba a solicitação HTTP repetida do cliente 40. A seguir, o mecanismo de atraso do invento explicado acima será descrito de forma exemplificativa em maior detalhe com referência às Fig. 4 e 5. Será assumido que a solicitação HTTP recebida pelo servidor "proxy" 30 do cliente 40 se refere a um objecto que é considerado pelo servidor "proxy" 30 como tendo uma prioridade baixa.

Num primeiro passo 402 da Fig. 4, o servidor "proxy" 30 recebe uma solicitação HTTP do cliente 40 através da ligação 14. No caso exemplificativo de HTTP esta primeira solicitação do cliente poderia ter o formato seguinte: 25 ΕΡ 1 650 931/ΡΤ GET http://example.com/some/image/png ΗΤΤΡ/1.1 Host: exemple.com

User-Agent: Mozílla/5.0 Xll; Linux Í686; en-US; rv: 0.9.9)

Gecko/20020311 Connection: dose

Na resposta à solicitação HTTP recebida no passo 402 do cliente 40, o servidor "proxy" 30 redirecciona o cliente 40 no passo 404 para uma nova localização (virtual) e instrui o cliente 40 para esperar durante um certo período de tempo (atraso) antes de repetir a solicitação HTTP. A mensagem de redireccionamento do servidor "proxy" 30 na base do código de estado "302" como especificado na norma HTTP 1.1 pode ter o formato seguinte: HTTP/l.1 302 Found

Date: Thu, 21 de Mar 2002, 15:12:47 Server: PrioTest/0.9

Location: http://example.com/some/ ()image(0001) .png Retry-After: 5 Connection: dose Tranfer-Encoding: chunked

Content-Type: text/html; charset=iso~8859-l (segue algum texto legível por humanos) O servidor "proxy" 30 pode agora solicitar o objecto do servidor 20 em qualquer altura depois da recepção da solicitação HTTP inicial do cliente 40 (passo 402) e da altura em que o mesmo decide entregar o objecto ao cliente 40 (passos 406 e 408).

Após a recepção da mensagem de redireccionamento acima o cliente 40 espera durante um período de tempo especificado na mensagem de redireccionamento, isto é, cinco segundos (ou até que todos os outros objectos tenham sido transferidos). No passo 412 o cliente 40 então repete a sua solicitação HTTP que indica a nova localização (virtual) como se segue: GET http.'//example.com/some/()image(00001).png HTTP/l.1 Host: exemple.com

User-Agent: Mozilla/5.0 (Xll; Linux i686; en-US; rv: 0.9.9)

Gecko/2 0 02 0311 Connection: dose 26 ΕΡ 1 650 931/ΡΤ

Após a recepção da solicitação HTTP repetida do cliente 40, o servidor "proxy" 30 decide se atrasa mais o objecto solicitado (por exemplo através da suspensão de uma ligação 50 ou através de mais uma mensagem de redireccionamento) ou se transmite o objecto atrasado para o cliente 40. Se o servidor "proxy" 30 decide transmitir o objecto atrasado sem qualquer atraso adicional, isto pode ser realizado no seguinte formato:

HTTP/l.1 200 OK

Date: Thu, 21 Mar 2002, 15:12:50 Server: Apache/1.3.23 (Unix)

Content-Type: image/png

Content-Length: 1520 (segue o conteúdo da imagem)

Agora, as decisões tomadas pelo servidor "proxy" 30 no decurso da rotina de redireccionamento explicada acima com referência à Fig. 4 serão explicadas com referência à Fig. 5.

No passo 502 o servidor "proxy" 30 recebe a solicitação HTTP do cliente 40. No passo seguinte 504 o servidor "proxy" 30 determina se o URL incluído na solicitação HTTP é um URL modificado, isto é o resultado de um redireccionamento anterior. Se for este o caso, o servidor "proxy" 30 descodifica o URL e recupera a localização original no passo 506 e desloca-se via nó 508 para o passo 510. De outro modo, o método desloca-se directamente do passo 504 via nó 508 para o passo 510.

No passo 510 o servidor "proxy" 30 determina se o objecto solicitado por meio da solicitação HTTP já está disponível, isto é armazenado na memória temporária 36 do servidor "proxy" 30 (ver Fig. 3). Se o objecto não estiver já em memória intermédia, o servidor "proxy" 30 solicita o objecto do servidor 20 ou marca o mesmo para recuperação posterior no passo 514. Do passo 514 o método desloca-se via nó 512 para o passo 516. O passo 516 também pode ser alcançado directamente do passo 510 via nó 512 no caso do objecto solicitado pelo cliente 40 já estar disponível. 27

ΕΡ 1 650 931/PT

No passo 516 a resposta HTTP que inclui o objecto solicitado está pronta para ser enviada para o cliente 40. Isto corresponde ao primeiro passo no fluxograma da Fig. 6 que será explicado abaixo.

Em princípio, a mensagem de redireccionamento (passo 404 na Fig. 4) pode ser enviada para o cliente 40 a qualquer altura enquanto os passos 502 a 516 são realizados ou depois do passo 516. Deverá ser notado que a disponibilidade de um objecto (isto é se um objecto solicitado já está em memória intermédia, em transferência no momento ou se o objecto ainda não foi solicitado) é um factor adicional que influencia a prioridade inicial de um objecto solicitado.

Decisões de reordenação

Logo que a resposta HTTP esteja pronta para ser enviada para o cliente 40 (passo 516 na Fig. 5), tem de ser decidido se um objecto compreendido na resposta HTTP deverá na realidade ser entregue ao cliente 40, se o cliente 40 deverá ser redireccionado ou se a ligação 50 através da qual este objecto se destina a ser enviado para o cliente 40 deverá ser suspensa. Um fluxograma que representa um esquema exemplificativo de decisão a este respeito está representado na Fig. 6.

No passo 602 a resposta HTTP está pronta para ser enviada para o cliente. No passo seguinte 604 a prioridade deste objecto é avaliada em relação ao facto se a prioridade tem ou não de ser actualizada. Se a prioridade do objecto tiver de ser actualizada, a prioridade é ajustada no passo 604.

No passo seguinte 606 a prioridade actual do objecto é avaliada para se determinar se o mesmo tem a prioridade mais elevada de todos os objectos a transferir ou que são esperados em breve. Se for determinado no passo 606 que o objecto solicitado na realidade tem a prioridade mais elevada, o método desloca-se via nó 610 para o passo 612. No passo 612 o objecto solicitado é enviado para o cliente 40. 28

ΕΡ 1 650 931/PT

Se a comparação da prioridade do objecto solicitado no momento com a prioridade de outros objectos no passo 606 conduzir ao resultado que o objecto solicitado no momento não tem a prioridade mais elevada, o método continua com o passo 614. Em relação ao passo 606 deverá ser notado que em vez da comparação da prioridade do objecto solicitado no momento com as prioridades de outros objectos é também possível comparar a prioridade do objecto solicitado no momento com um limiar fixo ou adicionar um desvio na comparação de modo que duas prioridades tenham de ser diferentes por mais do que um limiar predefinido antes da diferença ser considerada suficientemente significativa.

No passo 614 o servidor "proxy" 30 estima se a ligação 14 ao cliente 40 (ver Fig. 2) está ou estará em vazio. Como explicado acima, existem várias formas de o fazer. Uma delas compreende o cálculo de uma média móvel da quantidade máxima de dados que foram enviados e reconhecidos durante os últimos N segundos através das ligações 50 que vão para o mesmo cliente 40. Isto dá uma estimativa do débito máximo disponível. O resultado obtido deste modo é então comparado com a quantidade de dados que estão prontos para serem enviados através das ligações 50 que não estão suspensas. Se o servidor "proxy" 30 detectar que não tem dados suficientes para enviar a fim de preencher a ligação durante pelo menos um ciclo completo, então o mesmo considera que existe alguma largura de banda de reserva na ligação 14 para o cliente 40 e continua com o passo 616.

No passo 616 uma comparação semelhante à do passo 606 é realizada. Se for determinado no passo 616 que o objecto solicitado no momento tem uma prioridade mais elevada do que todos os objectos esperados em breve, o servidor "proxy" 30 continua via nó 610 com o passo 612 e envia o objecto solicitado no momento imediatamente para o cliente 40. De outro modo o método contínua com o passo 618 e uma mensagem de redireccionamento (código de estado "302") é enviada para o cliente 40 como explicado acima em ligação com a Fig. 4. 29 ΕΡ 1 650 931/ΡΤ A decisão tomada no passo 616 pode ser influenciada pela dimensão do objecto solicitado no momento (se a mesma já for conhecida). Se o objecto for conhecido como sendo pequeno (por exemplo duas vezes inferior à dimensão de uma mensagem de redireccionamento), então o servidor "proxy" envia sempre o objecto em vez de enviar uma mensagem de redireccionamento, mesmo se o objecto tiver uma prioridade atribuída muito baixa até então (isto pode ser considerado como uma forma de actualização da prioridade).

Se for determinado no passo 614 que existem dados suficientes para serem enviados a fim de preencher a ligação 14, o método continua com o passo 620 e suspende a ligação 50 para o cliente 40 através da qual o objecto solicitado no momento se destina a ser transferido.

De qualquer um dos passos 612, 618 e 620 o método continua com o passo 622. No passo 622 o servidor "proxy" 30 reavalia todas as ligações 50 suspensas para determinar se qualquer das ligações suspensas 50 deve ser aberta de novo. O protocolo HTTP/1.1 suporta a opção de envio em série, a qual permite que o cliente 40 envie várias solicitações para o servidor 20 ou para o servidor "proxy" 30 através da mesma ligação TCP sem esperar pelas respostas anteriores. No caso de ser utilizado envio em série, mais do que um objecto que esteja pronto para ser enviado poderá ser enviado através da mesma ligação 50 para o cliente 40. É evidente que num caso destes um objecto com uma prioridade baixa poderá bloquear um segundo objecto com uma prioridade mais alta que se destina a ser enviado na mesma ligação 50. Se existirem vários objectos à espera através da mesma ligação 50, a prioridade máxima ou média destes objectos pode ser determinada e considerada nos passos 606 e 616. Isto garante que objectos de mais baixa não bloqueiem objectos de maior prioridade.

Extensões possíveis Várias extensões, algumas das quais já foram explicadas brevemente, à concretização exemplificativa descrita com referência às Fig. 1 a 6 poderiam ser implementadas. 30 ΕΡ 1 650 931/ΡΤ

Uma destas extensões refere-se a restrições à velocidade de transferência na ligação 14 em função da prioridade dos objectos a transferir. Isto podia ser realizado por exemplo através da atribuição de uma partilha específica de capacidades de processamento a cada ligação 50 em função da prioridade dos objectos a transferir. A prioridade dos objectos individuais é diminuída enquanto o processo está a correr. Se o servidor "proxy" 30 processa ligações 50 numa forma cíclica, esta funcionalidade pode ser implementada através da limitação da quantidade de dados transferidos por ciclo em cada ligação 50 por um número que é obtido a partir da prioridade daquele objecto. A atribuição dinâmica de capacidades de processamento pode, com vantagem, ser combinada com mecanismos de suspensão e redireccionamento explicados acima. As capacidades de processamento também podem incluir qualquer transformação dos objectos ou códigos a transferir.

De acordo com uma extensão adicional do invento, as prioridades são atribuídas de forma directa pelo motor de busca que corre no cliente 40. 0 motor de busca pode, então, agendar as solicitações HTTP para objectos individuais de acordo com a sua prioridade. Se as prioridades forem atribuídas directamente pelo motor de busca, existem alguns factores adicionais que podem ser utilizados para melhorar a prioridade de cada objecto: - posição do objecto na página (coordenadas) - posição relativa da área visível (objectos que estão fora da área visível têm mais baixa) - se o carregamento da imagem ou a execução do guião forem desactivados, o motor de busca sabe imediatamente que não é necessário atribuir uma prioridade a estes objectos.

Para além disso, os motores de busca sabem quando um utilizador selecciona uma nova página de HTML a partir de marcadores ou ao digitar um novo URL. O motor de busca pode, então, limpar a lista de objectos que deixaram de ser necessários. 31 ΕΡ 1 650 931/ΡΤ

Uma extensão adicional do invento refere-se a um componente procurador que está localizado no mesmo computador (cliente) que o motor de busca ou próximo deste computador em termos de ligações de rede. Esta situação é representada na Fig. 7.

Como fica evidente da Fig. 7, o cliente 40 não só compreende apenas um componente de motor de busca 42 como um componente procurador adicional 30 (com a estrutura mostrada na Fig. 3) em comunicação com o componente de motor de busca 42. Numa caso destes, a ligação 14 entre o componente procurador 30 e o motor de busca 42 tem uma capacidade muito maior e latência inferior do que a ligação 12 entre o componente procurador e o servidor 20 (não mostrado na Fig. 7) .

Em consequência, o componente procurador 30 do lado do cliente influencia a sequência de solicitações devido a não poder fazer muito sobre a sequência de respostas. Com base na informação de prioridade obtida da solicitação HTTP actual e das respostas HTTP anteriores (por exemplo códigos HTML que se referem a mais objectos) bem como uma estimativa da disponibilidade de ligação, o componente procurador 30 do lado do cliente decide se uma solicitação HTTP deverá ser transmitida para o servidor e/ou se deverá ser imediatamente respondida com uma mensagem de redireccionamento.

As decisões a tomar são mais simples do que representado no fluxograma da Fig. 6. Mais em particular, as decisões podem ser reduzidas à avaliação se o objecto solicitado no momento tiver uma mais baixa do que alguns dos objectos que estão a ser transferidos ou esperam ser transferidos em breve e se a ligação já está completamente utilizada. Se ambas as condições se derem, então uma mensagem de redireccionamento é enviada para o componente de motor de busca 42. Em todos os outros casos, a solicitação HTTP é imediatamente transmitida para o servidor.

Se HTTP em série for utilizado numa ligação específica e se algumas solicitações HTTP anteriores forem processadas, então o componente procurador 30 do lado do cliente pode suspender a solicitação HTTP até que possa tomar a decisão. O 32

ΕΡ 1 650 931/PT mesmo terá que tomar uma decisão no limite quando os objectos anteriores tiverem sido completamente recebidos.

Uma extensão ainda adicional do invento refere-se ao bloqueio de descarregamentos para alguns objectos com base na sua prioridade. Isto significa que a prioridade que é atribuída aos objectos também pode ser utilizada para bloquear os objectos completamente. Se um limiar sobre a prioridade tiver sido definido, qualquer objecto que tenha uma prioridade que seja inferior a este limiar não será enviado para o cliente 40. Neste caso, o servidor "proxy" (ou componente procurador) 30 simplesmente devolveria um dos códigos de estado "4xx" ou "5xx" definidos na norma HTTP/1.1 para o cliente 40 quando o mesmo detectar um objecto destes. Códigos de estado possíveis são "403 proibido", "409 conflito" ou "503 serviço indisponível".

Como uma extensão adicional as prioridades atribuídas aos objectos poderiam ser utilizadas para pré-pesquisa e carregamento. Um mecanismo de pré-pesquisa e carregamento permite que o servidor "proxy" 30 preencha a sua memória temporária 36 (ver Fig. 3) com alguns objectos antes do cliente 40 na realidade os solicitar. Um mecanismo de pré-pesquisa e carregamento deste tipo pode, por exemplo, ser baseado na análise de um código HTML que é enviado do servidor "proxy" 30 para o cliente 40 e que inclui referências a mais objectos. Com base na análise das referências aos objectos o componente procurador 30 atribui prioridades aos objectos individuais e com base nesta atribuição é definido quais os objectos que se destinam a ser sujeitos a pré-pesquisa e carregamento e em que ordem. De preferência, os objectos começam a ser sujeitos a pré-pesquisa e carregamento com os objectos que têm a prioridade mais elevada.

De acordo com uma outra extensão que pode ser combinada com o mecanismo de pré-pesquisa e carregamento explicado acima, são implementados esquemas de impulsionamento específicos que permitem transferir objectos do servidor "proxy" 30 para o cliente 40 sem terem recebido uma solicitação de objecto explícita do cliente 40. 33

ΕΡ 1 650 931/PT

Uma concretização do invento refere-se a controlar numa rede de comunicações uma transferência de objectos a partir de um primeiro componente através de um componente intermédio para um segundo componente que está distante do primeiro componente, em que a transferência de objectos se baseia numa pluralidade de solicitações de objectos relativas a objectos referidos num ou mais códigos a processar pelo segundo ou outro componente da rede de comunicações. 0 componente intermédio realiza os passos de enviar uma solicitação de objecto para o primeiro componente; receber o objecto solicitado do primeiro componente (20); avaliar e/ou actualizar uma prioridade do objecto solicitado. Uma prioridade inicial tem de ser atribuída ao objecto solicitado com base numa análise de pelo menos um da solicitação de objecto e do código que se refere ao objecto solicitado. Em função da prioridade do objecto solicitado, o objecto solicitado é atrasado ou o objecto solicitado é transmitido para o segundo componente.

Numa concretização do invento, o atraso é realizado de modo que a ordem pela qual os objectos são recebidos do primeiro componente difere da ordem pela qual os objectos são transmitidos para o segundo componente.

Numa concretização do invento, o objecto solicitado é recebido do segundo componente ou gerado pelo componente intermédio.

Numa concretização do invento, o atraso do objecto solicitado inclui pelo menos um de instruir o segundo componente para repetir a solicitação de objecto, suspender uma ligação para o segundo componente através da qual o objecto solicitado se destina a ser transmitido e informar o segundo componente de que o objecto solicitado será automaticamente transmitido mais tarde.

Numa concretização do invento, a instrução do segundo componente para repetir a solicitação de objecto inclui a atribuição de um atributo específico ao objecto a atrasar; a informação do segundo componente do atributo; a recepção de uma referência para o atributo do segundo componente; e após a recepção da referência para o atributo, o envio do objecto 34 ΕΡ 1 650 931/ΡΤ atrasado para ο segundo componente ou atrasar mais o objecto atrasado.

Numa concretização do invento os objectos solicitados são transmitidos para o segundo componente através de uma pluralidade de ligações para o segundo componente.

Numa concretização do invento as seleccionadas das ligações para o segundo componente são suspensas em função das prioridades dos objectos solicitados que forem recebidos do primeiro componente e que se destinam a ser transmitidas através das ligações seleccionadas.

Numa concretização do invento é atribuída de forma dinâmica a cada ligação uma partilha específica de capacidades de processamento.

Uma concretização do invento compreende os passos de enviar uma solicitação de código para o primeiro ou para um terceiro componente; receber o código solicitado do primeiro ou do terceiro componente; analisar o código recebido relativo às referências a objectos; avaliar as referências a objectos com a finalidade de atribuir prioridades iniciais aos objectos referidos no código recebido.

Numa concretização do invento, uma resposta é avaliada após a recepção da resposta que contém o objecto solicitado a partir do primeiro componente. A resposta é avaliada em relação à prioridade do objecto recebido a fim de determinar se a prioridade inicial do objecto recebido tem ou não de ser actualizada.

Numa concretização do invento é gerada uma lista de prioridades que contém informação de prioridade para objectos individuais ou classes de objectos.

Numa concretização do invento a lista de prioridades é avaliada de forma repetida em relação a pelo menos um de actualização de informação de prioridade e eliminação de objectos ou classes de objectos, ou informação correspondente, da lista de prioridades. 35 ΕΡ 1 650 931/ΡΤ

Numa concretização do invento são realizados passos por um componente procurador situado no primeiro componente, no segundo componente ou configurado como um componente de suporte fisico separado da rede de comunicações.

Uma concretização do invento refere-se ao atraso numa rede de comunicações de uma transferência de objecto a partir de um primeiro componente através de um componente intermédio para um segundo componente que está distante do primeiro componente, em que a transferência de objecto é baseada numa pluralidade de solicitações de objectos relativas a objectos referidos num ou mais códigos a processar pelo segundo ou outro componente da rede de comunicações. O componente intermédio realiza os passos de atribuição de um atributo específico a um objecto a atrasar; informação do segundo componente sobre o atributo; recepção de uma referência ao atributo a partir do segundo componente; e, após recepção da referência do atributo, o envio do objecto atrasado para o qual o atributo foi atribuído ao segundo componente ou atrasar mais o objecto atrasado.

Numa concretização do invento o objecto é enviado para o segundo componente de acordo com um esquema de impulsionamento ou em resposta a uma solicitação de objecto recebida do segundo componente.

Numa concretização do invento o segundo componente é informado sobre o atributo no contexto com uma instrução para repetir a solicitação de objecto. A referência ao atributo é recebida do segundo componente em contexto com uma solicitação de objecto repetida.

Uma concretização do invento refere-se a um produto informático que compreende porções de código de programa para realizar os passos de concretizações descritas acima, quando o produto informático está a correr num sistema informático.

Numa concretização do invento o produto informático é armazenado num meio de gravação de leitura por computador.

Uma concretização do invento refere-se a um componente intermédio para controlar numa rede de comunicações uma 36

ΕΡ 1 650 931/PT transferência de objecto de um primeiro componente através do componente intermédio para um segundo componente que está distante do primeiro componente, em que a transferência de objecto se baseia numa pluralidade de solicitações de objectos relativas a objectos referidos num ou mais códigos a processar pelo segundo ou outro componente da rede de comunicações. 0 componente intermédio compreende uma interface de comunicações para enviar uma solicitação de objecto para o primeiro componente e para receber o objecto solicitado a partir do primeiro componente, uma unidade de processamento para avaliar e/ou actualizar uma prioridade do objecto solicitado, em que uma prioridade inicial foi atribuída ao objecto solicitado com base numa análise de pelo menos um da solicitação de objecto e do código que se refere ao objecto solicitado, e em que a unidade de processamento em função da prioridade do objecto solicitado atrasa o objecto solicitado ou controla a interface de comunicações para transmitir o objecto solicitado para o segundo componente.

Uma concretização do invento refere-se a uma componente intermédia para atrasar numa rede de comunicações uma transferência de objecto de um primeiro componente através do componente intermédio para um segundo componente que está distante do primeiro componente, em que a transferência de objecto se baseia numa pluralidade de solicitações de objectos relativas a objectos referidos num ou mais códigos a processar pelo segundo ou outro componente da rede de comunicação. 0 componente intermédio compreende uma unidade de processamento para atribuir um atributo especifico a um objecto que se destina a ser atrasado e uma interface de comunicações para informar o segundo componente sobre o atributo, para receber uma referência para o atributo do segundo componente e após a recepção da referência ao atributo, para enviar o objecto atrasado para o qual o atributo foi atribuído ao segundo componente ou atrasar mais o objecto atrasado.

Uma concretização do invento refere-se a um componente intermédio como descrito nas duas secções acima, configurado como um servidor "proxy". 37 ΕΡ 1 650 931/ΡΤ

Uma concretização do invento refere-se a um sistema de rede que compreende pelo menos um dos componentes descritos nas três secções acima.

Numa concretização, o sistema de rede compreende uma primeira ligação entre o componente intermédio e o primeiro componente e o primeiro componente e uma segunda ligação entre o componente intermédio e o segundo componente. A primeira ligação e a segunda ligação têm velocidades de transferência diferentes.

Numa concretização, o sistema de rede compreende um segundo componente na forma de um terminal móvel. Várias modificações da concretização preferida são possíveis sem afastamento do âmbito do presente invento. Apesar do invento ter sido descrito em ligação com uma concretização preferida, deve ser entendido que esta descrição não se destina a limitar o invento à mesma. Pelo contrário, considera-se que o invento cobre todas as modificações e/ou adições à descrição referida acima, sem afastamento do espírito e do âmbito do invento.

Lisboa, 2009-02-03

Claims

ΕΡ 1 650 931/ΡΤ 1/4 REIVINDICAÇÕES 1 - Método de operação um servidor "proxy" (serviço de rede de computadores que permite aos clientes fazerem ligações de rede indirectas a outros serviços de rede), em que uma prioridade de um objecto a ser enviado para um cliente é atribuída ou ajustada, quando uma referência ao dito objecto é encontrada num objecto que é para ser transmitida para o cliente.
2 - Método de acordo com a reivindicação 1, em que o objecto anterior compreende o código HTML.
3 - Método de acordo com a reivindicação 1 ou 2, que compreende o passo de geração de uma lista de prioridades que lista os objectos individuais, os quais são referidos no objecto anterior, de acordo com a sua prioridade.
4 - Método de acordo com a reivindicação 1, 2 ou 3, em que a prioridade do objecto é determinada em função da seguinte ordem de prioridade decrescente de um tipo de objecto: uma ligação a outra página, um quadro, uma imagem em linha, uma folha de estilo, a mesma prioridade para um guião ou para um objecto integrado ou uma aplicação, mais baixa para uma imagem de fundo, a menor prioridade para um objecto que já foi enviado para o cliente.
5 - Método de acordo com qualquer das reivindicações anteriores, em que a prioridade do objecto a enviar para um cliente é atribuída ou ajustada, quando é recebida uma solicitação, que é emitida por um motor de busca que corre no cliente, relativa ao dito objecto.
6 - Método de acordo com a reivindicação 5, em que a solicitação é uma solicitação HTTP.
7 - Método de acordo com a reivindicação 6, que compreende o passo de análise da solicitação num contexto URL. ΕΡ 1 650 931/ΡΤ 2/4
8 - Método de acordo com a reivindicação 6 ou 7, em que a prioridade é ajustada ou atribuída na dependência da informação no cabeçalho da solicitação HTTP.
9 - Método de acordo com qualquer das reivindicações 5 a 8, que compreende os passos de determinação se o objecto já foi solicitado uma vez pelo motor de busca, em que o objecto adquire uma prioridade elevada atribuída se o objecto já tiver sido solicitado uma vez pelo motor de busca.
10 - Método de acordo com qualquer das reivindicações 5 a 9, em que o objecto adquire uma prioridade elevada atribuída se o objecto não tem ainda uma prioridade e se a extensão do ficheiro indica um de um ficheiro HTML, um ficheiro XML ou um índice de directoria.
11 - Método de acordo com qualquer das reivindicações 5 a 10, em que a prioridade, que é atribuída ou ajustada em reacção à solicitação recebida, depende se a solicitação é uma solicitação HTTP condicional.
12 - Método de acordo com qualquer das reivindicações 5 a 11, em que a prioridade, a qual é atribuída ou ajustada em reacção à solicitação recebida, é inferior para a maior parte dos outros objectos solicitados, se o objecto foi solicitado de forma indirecta por um guião.
13 - Método de acordo com qualquer reivindicação anterior, em que a prioridade do objecto a enviar para um cliente é atribuída ou ajustada, quando uma resposta correspondente a uma solicitação do objecto é recebida, em que a dita resposta contém o objecto.
14 - Método de acordo com a reivindicação 13, em que a resposta é uma resposta HTTP.
15 - Método de acordo com a reivindicação 14, em que um cabeçalho ou um conteúdo da resposta HTTP é avaliado para ajustar a prioridade.
16 - Método de acordo com a reivindicação 14 ou 15, em que um código de resposta é avaliado para ajustar a ΕΡ 1 650 931/PT 3/4 prioridade e, em que uma prioridade mais alta é atribuída se a avaliação do código de resposta indicar um código de erro do que se a avaliação do código de resposta indicar uma resposta normal.
17 - Método de acordo com a reivindicação 14, 15 ou 16, em que um tipo de conteúdo é avaliado para ajustar a prioridade e em que uma prioridade mais alta é atribuída se a avaliação do tipo de conteúdo indicar um código HTML do que se a avaliação do código de resposta indicar uma imagem.
18 - Método de acordo com qualquer das reivindicações 14 a 17, em que uma dimensão do objecto é avaliada e em que um objecto mais pequeno adquire uma prioridade mais alta do que um objecto maior.
19 - Método de acordo com qualquer das reivindicações 14 a 18, em que um conteúdo do objecto é analisado para ajustar a prioridade.
20 - Método de acordo com a reivindicação 19, em que uma imagem animada adquire uma mais baixa do que uma imagem estática.
21 - Método de acordo com qualquer das reivindicações 14 a 20, em que se um código de resposta é um redireccionamento que especifica uma nova localização para o objecto solicitado, a dita nova localização adquire a mesma prioridade do que o objecto original.
22 - Método de acordo com qualquer reivindicação anterior, em que a prioridade de todos os objectos é reduzida depois de uma quantidade específica de tempo ou depois de várias solicitações HTTP ou respostas HTTP terem sido processadas.
23 - Servidor "proxy" que tem meios adaptados para concretizar o método de acordo com qualquer das reivindicações 1 a 22.
24 - Programa informático que compreende porções de código de programa para execução dos passos das ΕΡ 1 650 931/PT 4/4 reivindicações 1 a 22, quando o programa informático está a correr num sistema informático (30).
25 - Meio de gravação de leitura por computador, que armazena um programa informático da reivindicação 24. Lisboa, 2009-02-03