NO327863B1 - Optimalisert nettverkressurs-sted - Google Patents

Description

Denne oppfinnelse vedrører reprodusering av ressurser i et datamaskinnettverk.

Nærmere bestemt vedrører oppfinnelsen en fremgangsmåte, i et datamaskinnettverk som omfatter et nettverk av forsterkertjenere, for å reprodusere minst noen ressurser lagret i minst én opprinnelsestjener, idet nevnte forsterkertj enere er tilpasset til å levere innhold til minst én klient. Videre vedrører oppfinnelsen et datamaskinnettverk omfattende et nettverk av forsterkertj enere for å reprodusere minst noen ressurser lagret i minst én opprinnelig tjener, idet nevnte tjenere er tilpasset til å levere innhold til minst én klient.

Tilveiebirngelsen av globalt datamaskinnettverk, slik som Internet, har ført til fullstendig nye og forskjellige måter å oppnå informasjon. En bruker av Internet kan nå aksessere informasjon fra hvor som helst i verden, uten hensyn til det faktiske stedet for enten brukeren eller informasjonen. En bruker kan oppnå informasjon ganske enkelt ved å kjenne til en nettverksadresse og gi den adressen til et passende applikasjonsprogram, slik som en nettverksgjennomsøker (browser).

Den hurtige vekst i popularitet av Internet har medført en tung trafikkbyrde på hele nettverket. Løsninger på dette problemet av krav (eksempelvis bedre tilgjengelighet og hurtigere kommunikasjonsforbindelser) øker bare påkjenningen på tilførselen. Internet Web-steder (vist til her som "publiserere") må håndtere stadig økende båndbreddebe-hov, ivareta dynamiske endringer i belastning, og forbedre ytelse for fjerntliggende gjennomsøkende klienter, særlig de som befinner seg oversjøisk. Bruk av innholdsrike applikasjoner, slik som levende audio og video, har ytterligere forsterket problemet.

For å løse grunnleggende båndbreddevektsbehov, vil en Web-publiserer typisk abon-nere på ytterligere båndbredde fra en Internet-tjenesteyter (ISP = Internet service pro-vider), enten i form av større eller ytterligere "rørledninger" eller kanaler fra nevnt ISP til publisererens lokaliteter, eller i form av større båndbreddeforpliktelser i en ISP's fjerntliggende verttjenersamling. Disse inkrementer er ikke alltid så finkomete som publisereren trenger, og ganske ofte kan ledetider bevirke publisererens nettsidekapasitet til å ligge etter behovet.

For å løse mer alvorlige båndbreddevekstproblemer, kan publiserere utvikle mer kom-pliserte og kostbare, tilpassede løsninger. Løsningen på det mest vanlige behov, økende kapasitet, er generelt basert på kopiering av maskinvareressurser og størrelsesinnhold (kjent som speiling), og duplisering avbåndbredderessurser. Disse løsninger er imidler tid vanskelige og kostbare å anbringe og operere. Som et resultat, kan kun de største publiserere ha råd til disse, ettersom kun disse publiserere kan amortisere kostnadene over mange kunder (og nettsidetreff).

Et antall av løsninger er blitt utviklet for å fremskynde kopiering og speiling. Generelt, er disse teknologier utformet for bruk ved hjelp av et enkelt nettsted og innbefatter ikke trekk som tillater deres komponenter å bli delt av mange nettsteder samtidig.

Visse løsningsmekanismer tilbyr kopieringsprogramvare som hjelper til å holde speil-ende tjenere oppdaterte. Disse mekanismer opererer generelt ved å lage en fullstendig kopi av et filsystem synkront. Et annet system tilveiebringer mekanismer for uttrykkelig og regelmessig å kopiere filer som er blitt endret. Databasesystemer er særlig vanskelige å kopiere, etter som de kontinuerlig endrer seg. Flere mekanismer tillater kopiering av databaser, selv om det ikke finnes noen standardløsninger for å oppnå dette. Flere selskaper som tilbyr stedfortrederhurtigbuffere beskriver disse som kopieringsverktøy. Imidlertid, avviker stedfortrederhurtigbuffere fordi de betjenes på vegne av klienter i stedet for publisererne.

Så snart et nettsted betjenes av flere tjenere, er det en utfordring å sikre at belastningen blir på passende måte fordelt eller balansert blant disse tjenere. Domenenavn-tjener-basert solidarisk (round-robin) adresseløsning bevirker forskjellige klienter til å bli dirigert til forskjellige speil.

En annen løsning, belastningsbalansering, tar i betraktning belastningen på hver tjener (målt på et utall av måter) for å velge hvilken tjener som bør håndtere en særlig anmodning.

Belastningsbalanserere anvender et utall av teknikker for å dirigere anmodningen til den passende tjener. Det meste av disse belastningsbalanserende teknikker krever at hver tjener kan være en eksakt kopi av det primære nettstedet. Belastningsbalanserere tar ikke i betraktning "nettverkdistansen" mellom klient og kandidatspeiltj enerne.

Idet det antas at klientprotokoller ikke lett kan endres, finnes det to hovedproblemer ved utplasseringen av kopierte ressurser. Det første er hvorledes man skal velge hvilken kopi av ressursen som skal brukes. Dette betyr, når en anmodning om en ressurs gis til en enkelt tjener, hvorledes bør valget av en kopi av tjeneren (eller av slike data) gjøres. Man kan kalle dette problem "møteproblemet". Det finnes et antall av måter for å få kli enter til å møtes ved fjerntliggende speiltjenere. Disse teknologier, like som belastningsbalanserere, må rute en anmodning til en passende tjener, men i motsetning til belastningsbalanserere tar de nettverkytelse og topologi i betraktning.

Et antall av selskaper tilbyr produkter som forbedrer nettverkytelse ved å prioritere og filtrere nettverktrafikk. Stedfortrederhurtigbuffere tilveiebringer en måte for klientag-gregatorer å redusere nettverkressursforbruk ved å lagre kopier av populære ressurser nær sluttbrukerne. En klientaggregator er en Internet-tjenesteyter eller annen organisa-sjon som bringer et stort antall av klienter som betjener gjennomsøkere til Internet. Kli-entaggregatorer kan anvende stedfortrederhurtigbuffere for å redusere båndbredden som kreves for å betjene nettinnhold til disse gjennomsøkere. Imidlertid, blir tradisjonelle stedfortrederhurtigbuffere betjent på vegne av nettklienter i stedet for nettpubliserere.

Stedfortrederhurtigbuffere lagrer de mest populære ressurser fra alle publiserere, hvilket betyr at de må være meget store for å oppnå rimelig hurtigbuffervirkningsgrad (virk-ningsgraden for en hurtigbuffer defineres som antallet av anmodninger om ressurser som allerede er lagret delt med antallet av anmodninger).

Stedfortrederhurtigbuffere avhenger av hurtigbufferkontrollantydninger levert med ressurser for å bestemme når ressursene bør erstattes. Disse hentydninger er forutsigende, og er ofte feilaktige, slik at stedfortrederhurtigbuffere hyppig betjener forslitte eller gamle data.

Stedfortrederhurtigbuffere skjuler aktiviteten hos klientene fra publisererne. Så snart en ressurs blir lagret, har publisereren ikke lenger noen måte å vite hvor ofte den blir akses-sert fra hurtigbufferen.

Oppfinnelsen tilveiebringer en måte for tjenerne i et datamaskinnettverk å avlaste deres behandling av anmodninger om valgte ressurser ved å bestemme en forskjellig tjener (en "forsterker" (engelsk: "repeater") til å behandle disse anmodninger. Valget av forsterkeren kan foretas dynamisk, basert på informasjoner om mulige forsterkere.

Dersom en ønsket ressurs inneholder referanser til andre ressurser, kan noen eller samtlige av disse referanser erstattes av referanser til forsterkere.

Ifølge oppfinnelsen kjennetegnes den innledningsvis nevnte fremgangsmåte ved at

den omfatter hinnene:

a) å motta, på en programvaremodul, en fordring fra en klient om en ressurs fra en opprinnelig tjener, idet programvaremodulen velger en forsterkertj ener i nettverket av forsterkere til å levere ressursen til klienten, idet valget anvender kostnad innbefattende belastning eller forventet kostnad for transmisjon eller forventet transmisjonshastighet, og å bevirke klienten til å fordre ressursen fra den valgte forsterkertj ener ved å anvende en ressursidentifiserer mottatt fra programvaremodulen, idet ressursidentifisereren utpeker den valgte forsterkertj ener, b) som reaksjon på at den valgte forsterkertj ener anmodes om å levere ressursen til klienten, å bestemme ved den valgte forsterkertj ener hvorvidt den krevde ressurs

er tilgjengelig på den valgte forsterkertjener,

c) når det bestemmes at den krevde ressurs ikke er tilgjengelig på den valgte forsterkertjener, å oppnå den krevde ressurs fra den opprinnelige tjener eller fra en

annen forsterkertjener, og

d) å tilveiebringe ressursen til klienten fra den valgte forsterkertjener.

Ifølge utførelsesformer av fremgangsmåten kan programvaremodulen betjenes på en

nettverksadresse som er forskjellig fra den for den opprinnelige tjener.

Nevnte trinn a) for å bevirke blir utført ved hjelp av midler som er operativt forbundet med den minst ene opprinnelige tjener.

En klient kan fordre en ressurs ved å anvende minst en første ressursidentifiserer, og nevnte trinn a) bevirke returnering av en andre ressursidentifiserer som er distinkt fra nevnte første ressursidentifiserer og som er tilhørende den valgte forsterkertjener i nettverket av forsterkertj enere. Den andre ressursidentifisereren er modifikasjon av den første ressursidentifisereren. Videre kan den første ressursidentifisereren omfatte et vertsnavn. Med fordel kan den andre ressursidentifisereren omfatte en internettproto-koll- (IP) adresse eller et vertsnavn som er tilhørende en forsterkertjener i nettverket av forsterkertj enere. Dessuten kan den første ressursidentifisereren være tilhørende et sted for ressursen.

Ifølge ytterligere utførelsesform kan nevnte bevirkningsdel i trinn a) forsyne klienten med en modifisert ressursidentifiserer som utpeker en valgt forsterker i forsterkertjenernettverket.

Nevnte trinn som er relatert til å velge foretar et valg basert i det minste delvis på en nettverkadresse som er tilhørende klienten.

Det er også mulig å la nevnte trinn som er relatert til foreta et valg basert i det minste delvis på en belastning av minst noen av forsterkertj enerne.

Videre kan trinnet som er relatert til å velge foreta et valg basert på minst delvis en kostnad eller hastighet for transmisjon mellom minst noen av forsterkertj enerne og klienten.

Det nevnte nettverk kan være del av internett, og der den første ressursidentifisereren er en uniform ressurslokaliserer (URL) for å utpeke ressurser på internett.

I en utførelse kan identifiser erne være uniforme ressurslokaliserer e (URL).

Disse ressursidentifisererne kan omfatte navn som skal løses av en domenenavntj eneste (DNS) eller IP-adresser. Disse navn er for eksempel vertsnavn eller domenenavn.

Med fordel kan den første ressursidentifisereren innbefattes i en annen ressurs som tidligere er fordret av og levert til klienten.

Stedet som er angitt av den første ressursidentifisereren kan være en opprinnelig tjener.

Stedet som er angitt av nevnte første ressursidentifiserer er med fordel distinkt fra nettverket av forsterkertj enere.

I en annen utførelsesform er den fordrete ressurs et innleiret bilde.

Den fordrete ressurs kan selv inneholde ressursidentifiserere, idet fremgangsmåten dessuten omfatter å skrive på ny den fordrede ressurs for å erstatte minst noen av ressursidentifisererne som befinner seg deri med modifiserte ressursidentifiserere som utpeker en valgt forsterkertjener i forsterkertjenernettverket. De modifiserte ressursidentifisererne utpeker den valgte forsterker i forsterkertj enernettverket i stedet for en opprinnelig tjener.

Ressursene velges fra gruppen bestående av: statisk og dynamisk videoinhhold, audioinnhold, tekst, bildeinnhold, nettsider, html-filer, xml-filer, filer i et formateringsspråk, dokumenter, hypertekstdokumenter, datafiler og innleirede ressurser.

Det innledningsvis nevnte datamaskinnettverk utmerker seg ved at det at datamaskinnettverket omfatter midler for å utføre den angitte fremgangsmåtetrekk.

Følgelig, i ett aspekt, gjelder denne oppfinnelsen en fremgangsmåte for å behandle res-sursanmodninger i et datamaskinnettverk. Først gjør en klient en anmodning om en bestemt ressurs fra en opprinnelig tjener, idet anmodningen innbefatter en ressursidentifiserer for den bestemt ressursen, idet ressursidentifisereren av og til innbefatter en indikasjon av den opprinnelige tjener. Anmodninger som ankommer ved opprinnelsestjeneren innbefatter ikke alltid en indikasjon av opprinnelsestjeneren. Ettersom de sendes til opprinnelsestjeneren trenger de ikke å navngi denne. En mekanisme som refereres til som en reflektor, samplassert med opprinnelsestjeneren, avskjærer anmodningen fra klienten til opprinnelsestjeneren og bestemmer hvorvidt anmodningen skal reflekteres eller håndteres lokalt. Dersom reflektoren bestemmer å håndtere anmodningen lokalt, sender den denne videre til opprinnelsestjeneren, og ellers velger den en "beste" forsterker til å behandle anmodningen. Dersom anmodningen reflekteres, blir klienten forsynt med en modifisert ressursidentifiserer som betegner forsterkeren.

Klienten får den modifiserte ressursidentifisereren fra reflektoren og foretar en anmodning om den bestemte kilden fra forsterkeren som er utpekt i den modifiserte ressursidentifisereren.

Når forsterkeren får klientens anmodning, reagerer den ved å returnere den anmodede ressurs til klienten. Dersom forsterkeren har en lokal kopi av ressursen, returnerer den denne kopien, men ellers sender den anmodningen videre til opprinnelsestjeneren for å få ressursen, og sparer en lokal kopi av ressursen for å tjene påfølgende anmodninger.

Valget ved hjelp av reflektoren i en passende forsterker for å håndtere anmodningen kan foretas på et antall måter. I den foretrukne utførelsesform, foretas dette ved første opp-deling av nettverket i "kostnadsgruppe" og så bestemme hvilken kostnadsgruppe klienten er i. Dernest, fra et flertall av forsterkere i nettverket, blir et sett av forsterkere valgt, idet elementene i settet har en lav kostnad i forhold til kostnadsgruppen som klienten er i. For å bestemme den laveste kostnaden blir en tabell opprettholdt og regelmessig oppdatert for å definere kostnaden mellom hver gruppe og hver forsterker. Et element i settet blir så valgt, fortrinnsvis vilkårlig, som den beste forsterker.

Dersom den bestemte anmodede ressurs selv kan inneholde identifiserere av andre ressurser, kan ressursen så skrives på ny (før den leveres til klienten). I særdeleshet blir ressursen skrevet på ny for å erstatte minst noen av ressursidentifisererne som befinner seg deri med modifisert ressursidentifiserer som utpeker en forsterker i stedet for opprinnelsestjeneren. Som en konsekvens av denne omskrivningsprosess, når klienten ber om andre ressurser basert på identifiserere i den spesielle anmodede ressurs, vil klienten foreta disse anmodninger direkte til den valgte forsterker, ved fullstendig å gå forbi reflektoren og opprinnelsestjeneren.

Ressursomskrivning må utføres ved hjelp av reflektorer. Den kan også utføres ved hjelp av forsterkere, i den situasjon der forsterkere "stirrer" på hverandre og lager kopier av ressurser som innbefatter omskrivende ressursidentifiserere som betegner en forsterker.

I en foretrukket utførelsesform, er nettverket Internet og ressursidentifisereren er en ens-artet ressurslokaliserer (URL = uniform resource locator) for å utpeke ressurser på Internet, og den modifiserte ressursidentifisereren er en URL som utpeker forsterkeren og indikerer opprinnelsestjeneren (som beskrevet i trinn B3 nedenfor) og den modifiserte ressursidentifisereren gis til klienten ved å anvende en OMDIRIGER-melding. Bemerk at kun når reflektoren "reflekterer" en anmodning blir den modifiserte ressursidentifisereren tilveiebragt ved å anvende en OMDIRIGER-melding.

I et annet aspekt, er oppfinnelsen et datamaskinnettverk som omfatter et flertall av opp-rinnelsestjenere, idet minst visse av opprinnelsestj enerne har reflektorer tilhørende seg, og et flertall av forsterkere.

De ovenstående og andre formål og fordeler ved oppfinnelsen vil være åpenbare ved betraktning av den etterfølgende, detaljerte beskrivelse i forbindelse med de vedlagte teg-ninger, der henvisningstall refererer til like deler overalt og der: Figur 1 viser en del av et nettverkmiljø ifølge den foreliggende oppfinnelsen; og figurene 2-6 er flytskjema over operasjonen ifølge den foreliggende oppfinnelse. Figur 1 viser en del av et nettverkmiljø 100 ifølge den foreliggende oppfinnelse, der en mekanisme (reflektor 108, beskrevet i detalj nedenfor) på en tjener (server) (her opprinnelig tjener 102) opprettholder og holder orden på et antall av delvis kopierte tjenere eller forsterkere 104a, 104b, og 104c. Hver forsterker 104a, 104b og 104c kopierer noe eller all informasjon som er tilgjengelig på den opprinnelige tjener 102, samt informasjon som er tilgjengelig på andre opprinnelige tjenere i nettverket 100. Reflektoren 108 er koblet til en bestemt forsterker kjent som dens "kontakt" forsterker ("forsterker B" 104b i det system som er vist på figur 1). Fortrinnsvis opprettholder hver reflektor en forbindelse med en enkel forsterker som er kjent som dens kontakt, og hver forsterker opprettholder en forbindelse med en spesiell forsterker kjent som dens hovedforsterker (repeater) (f.eks. forsterker 104m for forsterker 104a, 104b og 104c i figur 1).

Således kan en forsterker anses som en dedikert stedfortredertjener som opprettholder et delvis eller sparsomt speil av den opprinnelige tjener 102, ved å implementere en fordelt, koherent hurtigbuffer av den opprinnelige tjeneren. En forsterker kan opprettholde et (delvis) speil av mer enn en orørinnelig tjener. I visse utførelsesformer er nettverket 100 Internet og forsterker speilvalgte ressurser tilveiebragt av opprinnelige tjenere som reaksjon på klienters HTTP (hypertext transfer protocol) og FTP (file transfer protocol) fordringer.

En klient 106 forbinder seg, via nettverket 100, til opprinnelig tjener 102 og eventuelt til en eller flere forsterkere 104a etc.

Opprinnelig tjener 102 er en tjener på hvilken ressurser har opprinnelse. Mer generelt, er den opprinnelige tjener 102 en hvilken som helst prosess eller samling av prosesser som gir ressurser som reaksjon på fordringer fra en klient 106. Opprinnelig tjener 102 kan være en hvilken som helst handelsvare Web-tjener. I en foretrukket utførelsesform er opprinnelig tjener 102 typisk en Web-tjener slik som Apache-tjeneren eller Netscape Communications Corporation's Enterprise™ tjener.

Klient 106 er en prosessorfordrende ressurs fra opprinnelig tjener 102 på vegne av en sluttbruker. Klienten 106 er typisk et brukeimiddel (f.eks. en nettgjennomsøker (Web browser), slik som Netscape Communications Corporation^ Navigator™) eller en sted-fortreder for et brukermiddel. Komponenter som er andre enn reflektoren 108 og forsterkerne 104a, 104b, etc. kan implementeres ved å anvende vanlige tilgjengelige pro-gramvareprogrammer. I særdeleshet virker denne oppfinnelse med hvilken som helst HTTP-klient (f.eks. en nettgjennomsøker), stedfortrederhurtigbuffer, og nett-tjener (Web-server). I tillegg kan reflektoren 108 fullstendig integreres i datatjeneren 112 (eksempelvis i en Web-tjener). Disse komponentene kan løst integreres basert på bruken av forlengelsesmekanismer (slik som såkalt tilføyelsesmoduler) eller tett integreres ved å modifisere tjenestekomponenter for særlig å understøtte forsterkerne.

Ressurser som har opprinnelse på den opprinnelige tjener 102 kan være statiske eller dynamiske. Dette betyr at ressursene kan være faste eller de kan skapes av den opprinnelige tjeneren 102 særlig som reaksjon på en fordring. Bemerk at uttrykkene "statiske" og "dynamiske" er relative, ettersom en statisk ressurs kan endre seg ved et visst regelmessig, selv om langt intervall.

Ressursfordringer fra klienten 106 til den opprinnelige tjener 102 avskjæres av reflektor 108 som for en gitt fordring enten fremmer fordringen videre til den opprinnelige tjener 102 eller betingelsesmessig reflekterer den til en eller annen forsterker 104a, 104b, etc. i nettverket 100. Dette betyr, avhengig av naturen av fordringen fra klienten 106 til den opprinnelige tjener 102, at reflektoren 108 enten betjener fordringen lokalt (ved den opprinnelige tjener 102), eller velger en av forsterkerne (fortrinnsvis den beste forsterkeren for jobben) og reflekterer fordringen til den valgte forsterker. Med andre ord bevirker reflektoren 108 fordringer for ressurser fra den opprinnelige tjener 102, laget av klient 106, for enten å bli betjent lokalt av den opprinnelige server 102 eller gjennom-siktig reflektert til den beste forsterker 104a, 104b, etc. Følelsen av en beste forsterker og måten som den beste forsterkeren velges er beskrevet i detalj nedenfor.

Forsterkere 104a, 104b, etc. er mellomprosessorer som anvendes til å betjene klientfordringer for derved å forbedre ytelse og å redusere kostnader på den måte som er beskrevet her. Innenfor forsterkere 104a, 104b, etc, finnes hvilke som helst prosesser eller samlinger av prosesser som leverer ressurser til klienten 106, på vegne av den opprinnelige tjener 102. En forsterker kan mnbefatte en forsterkerhurtigbuffer 110, anvendt til å unngå unødvendige transaksjoner innenfor den opprinnelige tjener 102.

Reflektoren 108 er en mekanisme, fortrinnsvis et programvareprogram som avskjærer fordringer som normalt ville bli sendt direkte til den opprinnelige tjener 102. Selv om det er vist på tegningene som separate komponenter, er reflektoren 108 og den opprinnelige tjener 102 vanligvis samplasserte, dvs. på et bestemt system slik som en data-tjener 112. (Som omtalt nedenfor, kan reflektoren 108 endog være en "innpluggings"-modul som blir del av den opprinnelige tjener 102).

Figur 1 viser kun en del av nettverket 100 i henhold til denne oppfinnelse. Et fullstendig operativnettverk består av et hvilket som helst antall av klienter, forsterkere, reflektorer og opprinnelige tjenere. Reflektorer kommuniserer med forsterkernettverket, og forsterkerne i nettverket kommuniserer med hverandre.

Hvert sted i et datamaskinriettverk har en adresse som generelt kan spesifiseres som en rekke av navn eller tall. For å aksessere informasjon, må en adresse for den informasjon være kjent. Eksempelvis på det verdensomspennende nettverk World Wide Web ("the Web") som er en underdel av Internet, er den måte som informasjonsadressesteder tilveiebringes blitt standardisert til uniforme ressurslokaliserere (URL = Uniform Resource Locators). Nevnte URL spesifiserer stedet for ressurser (informasjon, datafiler, etc.) for nettverket.

Forestillingen av URL'er blir enda mer nyttig når hypertekstdokumenter anvendes. Et hypertekstdokument er et som innbefatter, innenfor selve dokumentet, tilknytninger (pe-kere eller referanser) til selve dokumentet eller til andre dokumenter. I eksempelvis et direktekoblet lovforskningsprogram, kan hver sak være presentert som et hypertekstdokument. Når andre saker nevnes, kan forbindelsesledd til disse saker tilveiebringes. På denne måte, når en person leser en sak, kan de følge siteringstilknytninger for å lese de passende deler av anførte saker.

I tilfellet av Internet generelt og det verdensomspennende nett (World Wide Web) i særdeleshet, kan dokumenter skapes ved å anvende en standardisert form som er kjent som Hypertext Markup Language (HTML). I HTML består et dokument av data (tekst, bilder, lyder og lignende), som innbefatter tilknytningsforbindelser til andre seksjoner av det samme dokument eller til andre dokumenter. Tilknytningene er generelt tilveiebrakt som URL'er og kan være i relativ eller absolutt form. Relative URL'er utelater ganske enkelt de deler av nevnte URL som er de samme som for dokumentet som innbefatter tilknytningen, slik som adressen for dokumentet (når tilknytning skjer til det samme dokumentet), etc. Generelt, vil et gjennomsøkningsprogram fylle i manglende deler av et URL ved å anvende de tilsvarende deler fra det eksisterende dokumentet, for derved å danne et fullstendig dannet URL som innbefatter et fullstendig kvalifisert domenenavn, etc.

Et hypertekstdokument kan inneholde et hvilket som helst antall av tilknytninger til andre dokumenter, og hvert av disse andre dokumenter kan være for en forskjellig tjener i en forskjellig del av verden. Eksempelvis kan et dokument inneholde tilknytninger til dokumenter i Russland, Afrika, Kina og Australia. En bruker som betrakter det dokumentet hos en bestemt klient kan følge en hvilken som helst av tilknytningene gjennom-siktig (dvs. uten å vite hvor dokumentet som er tilknyttet faktisk beror). Følgelig, kan kostnadene (i form av tid eller penger eller ressursallokering) av den følgende ene tilknytning i forhold til den andre være ganske vesentlig.

URL'er har generelt den følgende form (definert i detalj i T. Berners-Lee et al., Uniform Resource Locators (URL), Network Working Group, Request for Comments: 1738, ka-tegori: Standards Track, desember 1994, plassert på

http:// ds. inteimc. net/ rfc/ rfcl738. txt". hvilken herved innbefattes her ved denne henvisning):

scheme:// host[ :port]/ url- path

der "scheme" kan være et symbol slik som "file" (for en fil i det lokale system), "ftp"

(for en fil på en anonym FTP-filtjener), "http" (for en fil på en fil på en nett-tjener (Web-server)), og "telnet" (for en forbindelse til en Telnet-basert tjeneste). Andre meto-der kan også anvendes og en ny metode tilføyes nå og da. Portnummeret er valgfritt, idet systemet erstatter et aktuelt portnummer (avhengig av fremgangsmåten), dersom intet tilveiebringes. "Host" (vert) feltet kartlegger til en bestemt nettverkadresse for en bestemt datamaskin. Nevnte "url-path" (url-vei) er relativ til datamaskinen som er angitt i "host" feltet. En url-bane er typisk, men ikke nødvendig, banenavnet for en fil i en web-tjenerkatalog.

Eksempelvis er det følgende et URL som identifiserer en fil "F" i banen "A/B/C" på en datamaskin ved , 1www. uspto. gov" :

http: // www . uspto . gov / A / B / C / F

For å aksessere filen "F" (ressursen) angitt ved hjelp av ovennevnte URL, ville et program (f.eks. en gjennomsøker) som løper på en brukers datamaskin (dvs. en klientdata-maskin) først måtte lokalisere datamaskinen (dvs. en tjenerdatamaskin) som er angitt ved vertnavnet. Dette vil si at programmet må lokalisere tjeneren www . uspto . 20w ".. For å gjøre dette, ville den aksessere en domenenavntjener (DNS = Domain Name Server), som forsyner nevnte DNS med vertnavnet (" www. uspto. gow"). Nevnte DNS virker som en type av sentralisert katalog for å løse adresser fra navn. Dersom nevnte DNS bestemmer at det er en (fjerntliggende tjener) datamaskin som svarer til navnet " www. uspto. gow", vil den forsyne programmet med en faktisk datamaskinnettverkad-resse for den tjenerdatamaskinen. På Internet er dette benevnt som en Internet-protokoll (eller IP) adresse og den har formen "123.345.456.678". Programmet på brukerens (klientens) datamaskin ville så anvende den faktiske adresse til å aksessere den fjerntliggende (tjener) datamaskin.

Programmet åpner en forbindelse til HTTP-tjeneren (Web-tjener) på den fjerntliggende datamaskinen " www. uspto. gov" og anvender forbindelsen til å sende en fordringsmel- ding til den fjerntliggende datamaskinen (ved å anvende HTTP-metoden). Meldingen er typisk en HTTP GET-fordring som innbefatter url-banen for den fordrede ressurs, "A/B/C/F". HTTP-tj eneren mottar fordringen og anvender den til å aksessere ressursen angitt av url-banen "A/B/C/F". Tjeneren går tilbake til ressursen over den samme forbindelsen.

Således vil konvensjonelt HTTP-klientfordringer for nett (Web) ressurser på en opprinnelig tjener 102 bli behandlet som følger (se figur 2) (dette er en beskrivelse av prosessen når ingen reflektor 108 er installert): Al. En gjennomsøker (f.eks. Netscape's Navigator) hos klienten mottar en

ressursidentifiserer (dvs. et URL) fra en bruker.

A2. Gjennomsøkeren ekstraherer vert (opprinnelig tjener) navn fra ressursidentifisereren og anvender en domenenavntjener (DNS) til å slå opp nettverk (LP) adressen for den tilsvarende tjener. Gjennomsøkeren ekstraherer også et portnummer, hvis ett er tilstede, eller anvender et gjeldende portnummer (gjeldende portnummer for HTTP-fordringer er 80).

A3. Gjennomsøkeren anvender tjenerens nettverkadresse og portnummer for å eta-blere en forbindelse mellom klienten 106 og verten eller opprinnelsestjeneren 102.

A4. Klienten 106 sender så en (GET) fordring over forbindelsen som identifiserer

den fordrede ressurs.

A5. Den opprinnelige tjener 102 mottar fordringen og

A6. lokaliserer eller komponerer den tilsvarende ressurs.

A7. Opprinnelsestjeneren 102 sender så tilbake til klienten 106 et svar som inneholder den fordrede ressurs (eller en viss form for feilindikator dersom ressursen er utilgjengelig). Svaret sendes til klienten over den samme forbindelsen som den for hvilken fordringen blir mottatt fra klienten.

A8. Klienten 106 mottar svaret fra den opprinnelige tjener 102.

Det finnes mange variasjoner av denne grunnleggende modell. Eksempelvis, i en vari-ant, i stedet for å forsyne klienten med ressursen, kan den opprinnelige tjener fortelle klienten om å fordre på ny ressursen ved hjelp av et annet navn. For å gjøre dette, vil i A7 tjeneren 102 sende tilbake til klienten et svar som kalles et "REDIRECT" (omdiriger) som inneholder et nytt URL som indikerer det andre navnet. Klienten 106 gjentar så hele sekvensen, normalt uten noen brukerintervenering, idet det denne gang fordres ressursen som identifiseres av det nye URL.

I denne oppfinnelsen tar reflektoren 108 effektivt plassen for en ordinær Web-tjener eller opprinnelig tjener 102. Reflektoren 108 gjør dette ved å overta den opprinnelige tjeners IP-adresse og portnummer. På denne måte, når en klient forsøker å koble seg til den opprinnelige tjener 102, vil den i realitet koble seg til reflektoren 108. Den opprinnelige Web-tjener (eller opprinnelige tjener 102) må så godta fordringer på en forskjellig nettverk- (IP) adresse, eller på den samme IP-adresse, men på et forskjellig portnummer. Ved således å anvende denne oppfinnelse, er tjeneren som er referert til i A3-A7 ovenfor faktisk en reflektor 108.

Bemerk at det også er mulig å la den opprinnelige tjeners nettverkadresse vær som den er og la reflektoren løpe på en forskjellig adresse eller på en forskjellig port. På denne måte vil reflektoren ikke avskjøre fordringer som sendes til opprinnelsestj enere, men kan fortsatt bli sendt fordringer og adressert særlig til reflektoren. Således kan systemet testes og konfigureres uten å avbryte dets normale operasjon.

Reflektoren 108 understøtter behandling som følger (se figur 3):

ved mottakelse av en fordring,

Bl. Reflektoren 108 analyserer fordringen for å bestemme hvorvidt den skal reflektere fordringen eller ikke. For å gjøre dette bestemmer den første reflektoren hvorvidt senderen (klient 106) er en gjennomsøker eller en forsterker. Fordringer som avgis av forsterkerne må betjenes lokalt av opprinnelsestjeneren 102. Denne bestemmelse kan foretas ved å se etter nettverk (IP) adressen for en sender i en liste over kjente forsterkernettverk (IP) adresser. Alternativt, kunne denne bestemmelse foretas ved å knytte informasjon til en fordring for å indikere at fordringen er fra en bestemt forsterker, eller forsterkere kan fordre ressurser fra en spesiell port som er en annen enn den ene som anvendes for ordinære klienter.

B2. Dersom fordringen ikke er fra en forsterker, ser reflektoren etter den fordrede ressurs i en tabell (benevnt "rule base" (regelbasen)) for å bestemme hvorvidt ressursen som fordres er "repeatable" (gjentagbar). Basert på denne bestemmelse kan reflektoren enten reflektere fordringen (B3, beskrevet nedenfor) eller betjene fordringen lokalt (B4, beskrevet nedenfor).

Regelbasisen er en liste over regulære uttrykk og tilhørende attributter.

(Regulære uttrykk er velkjente innenfor området av datamaskinteknikk. En liten bibliografi over deres bruk finnes i Aho, et al., "Compilers, Principles, techniques and tools", Addison-Wesley, 1986, s. 157-158). Ressursidenti-fisere-ren (URL) for en gitt fordring finnes i regelbasisen ved å tilpasse den sekvensielt med hvert regulære uttrykk. Den første tilpasning identifiserer attributtene for ressursen, nemlig gjentagbar eller lokal. Dersom det ikke finnes noen tilpasning i regelbasisen, blir en gjeldende attributt anvendt. Hver reflektor har sin egen regelbasis, hvilken manuelt konfigureres av reflektorens operatør.

B3. For å reflektere en fordring, (for å betjene en fordring lokalt gå til B4), som vist på figur 4, bestemmer reflektoren (B3-1) den beste forsterker for å reflektere fordringen til, som beskrevet i detalj nedenfor. Reflektoren kan så skape (B3-2) en ny ressursidentifiserer (URL) (som anvender det fordrede URL og den beste forsterker) som identifiserer den samme ressurs på den valgte forsterker.

Det er nødvendig at refleksjonstrinnet skaper et enkelt URL som inneholder nevnte URL for den opprinnelige ressurs, samt identiteten av den valgte forsterker. En spesiell form av URL skapes for å tilveiebringe denne informasjon. Dette gjøres ved å skape en ny URL som følger: Dl. Gitt et forsterkernavn, metode, opprinnelsestjeners navn og bane, skape et nytt URL. Dersom metoden er "http", anvender den foretrukne utførelsesform det følgende format: http:// <repeater>/ <server>/ <path>

Dersom formen som anvendes er en annen enn "http", anvender den foretrukne utførelsesform det følgende format: http:// <repeater>/ <server>@proxy^ <scheme>@/ <path>

Reflektoren kan også feste en MIME-type til fordringen, for å bevirke forsterkeren til å forsyne den MIME-typen med resultatet. Dette er nyttig fordi mange protokoller (slik som FTP) ikke gir en måte å feste MIME-typen til en ressurs. Formatet er

http:// <repeater>/ <server>@proxy=<scheme>:<type>@/ <path>

Dette URL fortolkes når mottatt av forsterkeren.

Reflektoren sender så (B3-3) et OMDIRIGER-svar (REDIRECT) som inneholder dette nye URL til den fordrende klient. Nevnte HTTP OMDIRIGER-kom-mando tillater reflektoren å sende gjennomsøkeren et enkelt URL for å forsøke fordringen på ny.

B4. For å betjene en fordring lokalt, blir fordringen sendt ved hjelp av reflektoren til ("videresendt til") den opprinnelige tjeneren 102.1 denne modus virker reflektoren som en omvendt stedfortredertjener. Den opprinnelige tjeneren 102 behandler fordringen på den normale måte (A5-A7). Reflektoren oppnår så den opprinnelige tjeners svar på fordringen som den inspiserer for å bestemme om den fordrede ressurs er et HTML-dokument, dvs. hvorvidt den fordrede ressurs er en som selv inneholder ressursidentifiserere.

B5. Dersom ressursen er et HTML-dokument, vil reflektoren så skrive på ny HTML-dokumentet ved å modifisere ressursidentifiserere (URL'er) innenfor seg, slik som beskrevet nedenfor. Ressursen, eventuelt som modifisert ved omskriving, blir så returnert i et svar til den fordrende klient 106.

Dersom den fordrende klient er en forsterker, kan reflektoren midlertidig sette ut av funksjon eventuelle hurtigbuffer-kontrollmodifiserere som den opprinnelige tjener knyttet til svaret. Disse hurtigbuffer-kontrollmodifiserere som er satt ut av funksjon blir senere satt i funksjon igjen når innholdet betjenes fra forsterkeren. Denne mekanisme gjør det mulig for den opprinnelige tjener å hindre ressurser fra å bli hurtigbufferbehandlet på normale stedfortrederhurtigbuffere, uten å på-virke oppførselen av hurtigbufferen på forsterkeren.

B6. Når fordringen reflekteres eller håndteres lokalt, blir detaljer om transaksjonen,

slik som den eksisterende tid, adressen for fordreren, nevnte URL som fordres, og typen av generert respons, skrevet ved hjelp av reflektoren til en lokal loggfil.

Ved å anvende en regelbasis (B2), er det mulig selektivt å reflektere ressurser. Det finnes et antall av grunner til at visse bestemte ressurser ikke kan effektivt gjentas (forster-kes) (og bør derfor ikke reflekteres), eksempelvis

ressursen er sammensatt unikt for hver fordring;

ressursen baserer seg på såkalt "cookie" (gjennomsøkere vil ikke sende

"cookies" til forsterkere med forskjellige domenenavn);

ressursen er faktisk et program (slik som et Java-tilleggsprogram (applet)) som vil kjøre på klienten og som ønsker å koble seg til en tjeneste (Java krever at tje-nesten kjøres på den samme maskin som tilveiebrakte tilleggsprogrammet).

I tillegg, kan reflektoren 108 konfigureres slik at fordringer fra visse nettverksadresser (f.eks. fordringer fra klienter på det samme lokalnett som selve reflektoren) aldri reflekteres. Videre kan reflektoren velge ikke å reflektere fordringer på grunn av at reflektoren overskrider sin forpliktede aggregatinformasjonstakt, slik som beskrevet nedenfor.

En fordring som reflekteres blir automatisk speilet på forsterkeren når forsterkeren mottar og behandler fordringen.

Kombinasjonen av refleksjonsprosessen som er beskrevet her og hurtigbufferprosessen som er beskrevet nedenfor skaper effektivt et system der forsterkbare (gjentagbare) ressurser migreres til og speiles på den valgte reflektor, mens ikke-forsterkbare (ikke-gjentagbare) ressurser ikke speiles.

Plassering av den opprinnelige tjeners navn i det reflekterte URL er generelt en god strategi, men det kan anses uønsket av estetiske eller (i tilfellet av f.eks. "cookies") visse tekniske årsaker.

Det er mulig å unngå behovet for å anbringe både forsterkerens navn og tjenerens navn i nevnte URL. I stedet kan en "familie" av navn skapes for en gitt opprinnelig tjener, idet hvert navn identifiserer en av forsterkerne som anvendes av den tjeneren.

Dersom eksempelvis www.example.com er den opprinnelige tjener, kan navn for tre forsterkere skapes:

wrl .example.com

wr2.example.com

wr3.example.com

Navnet "wrl.example.com" ville være et alias for forsterker 1, som også kan være kjent ved andre navn slik som "wrl.anotherExample.com" og "wrl.example.edu".

Dersom forsterkeren kan bestemme ved hjelp av hvilket navn den ble adressert, kan den anvende den informasjon (sammen med en tabell som assosierer forsterkeraliasnavnet med opprinnelig tjenernavn) for å bestemme hvilken opprinnelig tjener som adresseres. Dersom eksempelvis forsterker 1 adresseres som wrl.example.com, er den opprinnelige tjener så "www.example.com". Dersom den adresseres som

"wrl .anotherExample.com", er den opprinnelige tjener "www.anotherExample.com".

Forsterkeren kan anvende to mekanismer for å bestemme ved hvilket alias den adresseres: 1. Hvert alias kan assosieres med en forskjellig IP-adresse. Dessverre, skalerer denne løsning ikke godt, idet IP-adresser i øyeblikket er sjeldne, og antallet av IP-adresser som fordres vokser som produktet av opprinnelige tjenere og forsterkere. 2. Forsterkeren kan forsøke å bestemme aliasnavnet anvendt ved å inspisere "host:" (vert) merket i HTTP-overskriften av fordringen. Dessverre, vil visse gamle gjennomsøkere som fortsatt er i bruk ikke feste "host:"-merket til en fordring. Reflektorer ville trenge å identifisere slike gjennomsøkere (gjennomsøkeridenti-teten er en del av hver fordring) og unngå denne form for refleksjon.

Når en gjennomsøker mottar en OMDIRIGER-reaksjon (REDIRECT-response) (slik som frembragt i B3), utsteder den på ny en fordring for ressursen ved å anvende den nye ressursidentifisereren (URL) (A1-A5). På grunn av at den nye identifisereren refererer til en forsterker i stedet for den opprinnelige tjener, sender gjennomsøkeren nå en fordring for ressursen til forsterkeren som behandler en fordring som følger, med henvisning til figur 5: Cl. Først analyserer forsterkeren fordringen for å bestemme nettverkadressen for den fordrende klient og banen for den fordrede ressurs. Innbefattet i banen er en opprinnelig tjeners navn (som beskrevet ovenfor med henvisning til B3).

C2. Forsterkeren anvender en intern tabell for å verifisere at den opprinnelige tjener tilhører en kjent "abonnent". En abonnent er en enhet (f.eks. et selskap) som publiserer ressurser (f.eks. filer) via en eller flere opprinnelige tjenere. Når enhe-ten abonnerer, tillates den å anvende forsterkernettverket. Abonnenttabellene som er beskrevet nedenfor innbefatter informasjonen som anvendes for å knytte reflektorer til abonnenter.

Dersom fordringen ikke er for en ressurs fra en kjent abonnent, blir fordringen avvist. For å avvise en fordring, returnerer forsterkeren et svar som indikerer at den fordrede ressurs ikke eksisterer.

C3. Forsterkeren bestemmer så hvorvidt den fordrede ressurs blir hurtigbufret lokalt.

Dersom den fordrede ressurs er i forsterkerens hurtige buffer, blir den hentet. På den annen side, dersom en gyldig kopi av den fordrede ressurs ikke er i forsterkerens hurtigbuffer, modifiserer forsterkeren det innkommende URL, idet det skapes en fordring som den avgir direkte til den opprinnelige reflektor som behandler den (som i B1-B6). Fordi denne fordring til den opprinnelig reflektor er fra en forsterker, går reflektoren alltid tilbake til den fordrede ressurs i stedet for å reflektere fordringen. (Det minnes om at reflektorer alltid håndterer fordringer fra forsterkere lokalt). Dersom forsterkeren oppnådde ressursen fra den opprinnelige tjener, vil forsterkeren så hurtigbufferbehandle ressursen lokalt.

Dersom en ressurs ikke hurtigbuffres lokalt, kan hurtigbufferen spørre sine 'Tdkke-hurtigbuffere" for å se om en disse inneholder ressursen, før eller på samme tid som ressursen fordres fra reflektoren/den opprinnelige tjener. Dersom en kikkehurtigbuffer reagerer positivt innenfor en begrenset tidsperiode (fortrinnsvis en liten brøkdel av et sekund) vil ressursen bli hentet fra kikkehurtigbufferen.

C4. Forsterkeren konstruerer så et svar som innbefatter den fordrede ressurs (som ble hentet fra hurtigbufferen eller fra den opprinnelige tjener) og sender det svaret til den fordrende klient.

C5. Detaljer om transaksjonen, slik som den tilhørende reflektor, det eksisterende tidspunkt, adressen for fordreren, nevnte URL som fordres, og typen av generert respons, skrives til en lokal loggfil på forsterkeren.

Bemerk at den nedre rad på figur 2 refererer til en opprinnelig tjener, eller en reflektor, eller en forsterker, avhengig av hva nevnte URL i trinn Al identifiserer.

Dersom reflektoren 108 bestemmer at den vil reflektere en fordring, må den velge den

; beste forsterkeren for å håndtere den fordringen (som vist til i trinn B3-1). Dette valg ut-føres av den beste forsterkervelger (BRS = Best Repeater Selector) mekanisme som er beskrevet her.

Målet med nevnte BRS er å velge, hurtig og heuristisk, en passende forsterker for en gitt i klient gitt kun nettverkadressen for klienten. En passende forsterker er en som ikke er for tungt belastet og som ikke er for langt fra klienten i form av et visst mål for nett-verksdistanse. Mekanismen som anvendes her baserer seg på bestemte, kompakte, forutberegnede data for å foreta en hurtig beslutning. Andre dynamiske løsninger kan også

anvendes for å velge en passende forsterker.

5

Nevnte BRS baserer seg på tre forutberegnede tabeller, nemlig gruppereduksjonstable-len (Group Reduction Table), forbindelseskostnadstabellen (Link Cost Table) og belastningstabellen (Load Table). Disse tre tabeller (beskrevet nedenfor) beregnes ved frakoblet tilstand og nedlastes til hver reflektor ved sin kontakt i forsterkernettverket.

Gruppereduksjonstabellen plasserer hver nettverkadresse i en gruppe, med det mål at adresser i en gruppe deler relative kostnader, slik at de vil ha den samme beste forsterker under varierende forhold (dvs. nevnte BRS er invariant over elementene i gruppen).

s Forbindelseskostnadstabellen er en todimensjonal matrise som angir eksisterende kostnad mellom hver forsterker og hver gruppe. I utgangspunkt er forbindelseskostnaden mellom en forsterker og en gruppe definert som den "normaliserte forbindelseskostnad" mellom forsterkeren og gruppen, som definert nedenfor. Over tid, vil tabellene bli oppdatert med målinger som mer nøyaktig gjengir den relative kostnad for å sende en fil

o mellom forsterkeren og et element i gruppen. Formatet av forbindelseskostnadstabellen er <Group JDxGroup IDxlink cost>, der gruppe ID'er er gitt som AS-numre.

Belastningstabellen er en endimensjonal tabell som identifiserer den eksisterende belastning på hver forsterker. Fordi forsterkere kan ha forskjellige kapasiteter, er belastningen s en verdi som representerer evnen for å en gitt forsterker til å godta ytterligere arbeid. Hver forsterker sender sin eksisterende belastning til en sentral hovedforsterker med re- gelmessige intervaller, fortrinnsvis minst ca. én gang pr. minutt. Hovedforsterkeren utsender belastningstabellen til hver reflekter i nettverket, via kontaktforsterkeren.

En reflektor er gitt innføringer i belastningstabellen kun for forsterkere som den er til-delt å anvende. Tildelingen av forsterkere til reflektorer utføres sentralt ved hjelp av en forsterkernettverkoperatør hos hovedforsterkeren. Denne tildeling gjør det mulig å modifisere tjenestenivået for en gitt reflektor. Eksempelvis kan en meget aktiv reflektor bruke mange forsterkere, mens en relativt inaktiv reflektor kan anvende få forsterkere.

Tabeller kan også konfigureres til å gi selektiv forsterkertj eneste til abonnenter på andre måter, eksempelvis for deres klienter i bestemte geografiske områder, slik som Europa eller Asia.

I de i øyeblikket fortrukne utførelsesformer blir forsterkerbelastning målt i to dimensjoner, nemlig

1. fordringer mottatt av forsterkeren pr. tidsintervall ( RRPT), og

2. byter sendt av forsterkeren pr. tidsintervall ( BSPT).

For hver av disse dimensjoner blir en maksimum kapasitetsinnstilling satt. Den maksimale kapasitet indikerer punktet hvor forsterkeren anses å være fullstendig belastet. En høyere RRPT-kapasitet indikerer generelt en hurtigere prosessor, mens en høyere BSPT-kapasitet generelt indikerer en bredere nettverk "rørledning". Denne form for be-lastningsmåling antar at en gitt tjener dediseres til forsterkningsoppgaven.

Hver forsterker beregner regelmessig sin eksisterende RRPT og BSPT, ved å akkumu-lere antallet av fordringer som mottas og byter som sendes over et kort tidsintervall. Disse målinger anvendes for å bestemme forsterkerens belastning i hver av disse dimensjoner. Hvis en forsterkers belastning overskrider dens konfigurerte kapasitet, blir en al-arrnmelding sendt til forsterkerens nettverkadmimstrator.

De to eksisterende belastningskomponenter kombineres til en enkelt verdi som indikerer den totale eksisterende belastning. Tilsvarende, blir to maksimale kapasitetskomponen-ter kombinert til en enkelt verdi som indikerer den totale maksimale kapasitet. Komponentene kombineres som følger:

Faktoren B, en verdi mellom 0 og 1, tillater de relative vekter av RRPT og BSPT å bli justert, hvilket begunstiger betraktninger av enten behandling av effekt eller båndbredde.

De totale eksisterende belastnings- og totale maksimumkapasitetsverdier blir periodisk sendt fra hver forsterker til hovedforsterkeren, hvor de aggregeres i belastningstabellen, en tabell som oppsummerer den totale belastning for samtlige forsterkere. Endringer i belastningstabellen fordeles automatisk til hver reflektor.

Selv om den foretrukne utførelsesform anvender et todimensjonalt mål for forsterkerbelastning, kan et hvilket som helst annet mål for belastning anvendes.

Nevnte BRS beregner kostnaden for å betjene en gitt klient fra hver kvalifiserte forsterker. Kostnaden beregnes ved å kombinere den tilgjengelige kapasitet hos kandidatfor-sterkeren med kostnaden for forbindelsen mellom den forsterkeren og klienten. Forbindelseskostnaden beregnes ved ganske enkelt å se etter i forbindelseskostnadstabellen.

Kostnaden bestemmes ved å anvende den følgende formel:

I denne formel er e et meget lite tall (epsilon) og K er en avstemningsfaktor som i ut-gangspunktet settes til 0,5. Denne formel bevirker kostnaden til en gitt forsterker å bli økt, med en takt definert ved K, dersom dens kapasitet faller under en konfigurerbar terskel.

Gitt kostnaden for hver kandidatforsterker, velger nevnte BRS samtlige forsterkere innenfor en deltafaktor for det beste treff. Fra dette sett, blir resultatet valgt vilkårlig.

Deltafaktoren hindrer nevnte BRS fra gjentatt å velge en enkelt forsterker når treff er tilsvarende hverandre. Dette kreves generelt på grunn av at tilgjengelig informasjon om belastning og forbindelseskostnader mister nøyaktighet over tid. Denne faktor er av-stembar.

Nevnte BRS opererer som følger, med henvisning til figur 6:

Gitt en klients nettverkadresse og de tre tabellene beskrevet ovenfor:

El. Bestemme hvilken gruppe klienten er i ved å anvende gruppereduksjonstabellen.

E2. For hver forsterker i forbindelseskostnadstabellen og belastningstabellen å bestemme den forsterkerens kombinerte kostnad som følger:

E2a. Bestemme maksimum og eksisterende belastning på forsterkeren

(ved å anvende belastningstabellen).

E2b. Bestemme forbindelseskostnaden mellom forsterkeren og klientens

gruppe (ved å anvende forbindelseskostnadstabellen).

E2c. Bestemme den kombinerte kostnad som beskrevet ovenfor.

E3. Velge et lite sett av forsterkere med den laveste kostnaden.

E4. Velge et vilkårlig element fra settet.

Fortrinnsvis blir resultatene fra nevnte BRS-behandling opprettholdt i en lokal hurtigbuffer på reflektoren 108. Dersom således den beste forsterker nylig er blitt bestemt for en gitt klient (dvs. for en gitt nettverkadresse), kan den beste forsterkeren benyttes på ny hurtig uten å måtte bestemmes på ny. Ettersom beregningen som er beskrevet ovenfor er basert på statisk, forutberegnede tabeller, vil det, dersom tabellen ikke er blitt endret ikke være noe behov for å bestemme på ny den beste forsterkeren.

Gruppereduksjonstabellen og forbindelseskostnadstabellen som anvendes i BRS-behandling skapes og blir regelmessig oppdatert ved hjelp av en uavhengig prosedyre som er referert til her som NetMap. Nevnte NetMap- proseåyre kjøres ved å utføre flere faser (beskrevet nedenfor) etter behov.

Uttrykket Gruppe anvendes her for å referere til en IP "adressegruppe".

Uttrykket forsterkergruppe (Repeater Group) refererer til en gruppe som inneholder IP-adressen for en forsterker.

Uttrykket forbindelseskostnad (link cost) refererer til en statisk bestemt kostnad for å sende data mellom to grupper. I en i øyeblikket foretrukket implementering er dette mi-nimum av summene av kostnader for forbindelsene langs hver bane mellom disse. For-bindelseskostnadene som er av primær betydning her er forbindelseskostnader mellom en gruppe og en forsterkergruppe.

Uttrykket relativ forbindelseskostnad (relative link cost) refererer til forbindelseskost-nadene i forhold til andre forbindelseskostnader for den samme gruppen som beregnes ved å subtrahere minimumsforbindelseskostnaden fra en gruppe til en hvilken som helst forsterkergruppe fra hver av dens forbindelseskostnader til en forsterkergruppe.

Uttrykket kostnadssett (cost set) refererer til et sett av grupper som er ekvivalente med hensyn til beste forsterkervalg. Dette betyr, gitt den tilgjengelige informasjon, at samme forsterker ville bli valgt for hvilken som helst av disse.

Nevnte AføMjp-prosedyre behandler først innmatede filer for å skape en intern database som er benevnt grupperegister (Group Registry). Disse innmatede filer beskriver grupper, IP-adressene innenfor gruppene, og forbindelser mellom grupper, og, som et utvalg av kilder, innbefattende offentlig tilgjengelig Internet-rutingsregister (IRR) databaser, BGP-rutingstabeller, og undersøkelsestjenester som er plassert på forskjellige punkter rundt nevnte Internet og bruker offentlig tilgjengelig verktøy (slik som "traceroute") for å ta prøver av databaner. Så snart denne behandling er fullstendig, inneholder grupperegisteret vesentlig informasjon som anvendes for ytterligere behandling, nemlig (1) identiteten for hver gruppe, (2) settet av IP-adresser i en gitt gruppe, (3) nærværet av forbindelser mellom grupper som indikerer baner over hvilke informasjon kan vandre og (4)

kostnaden for å sende data over en gitt forbindelse.

De følgende prosesser blir så utført på grupperegisterfilen.

Nevnte iVefMap-prosedyre beregner en "forbindelseskostnad" for overføring av data mellom hver forsterkergruppe og hver gruppe i grupperegisteret. Den totale forbindelseskostnad defineres som minimumskostnaden for en hvilken som helst bane mellom de to gruppene, der kostnaden for en bane er lik summen av kostnadene for de individuelle forbindelsene i banen. Forbindelseskostnadsalgoritmen som er gitt nedenfor"er i alt vesentlig den samme algoritmen nr. 562 fra ACM journal Transactions on Mathematical Software: "Shortest Path From a Specific Node to All Other Nodes in a Network" av U. Pape, ACM TOM6 (1980), s. 450-455, htto:// www. netlib. org/ toms/ 562.

Ved denne behandling, refererer uttrykket forsterkergruppe til en gruppe som innehol-

der IP-adressen for en forsterker. En gruppe er en nabo for en annen gruppe, dersom grupperegisteret indikerer at det er en forbindelse mellom de to gruppene.

For hvert måls forsterkergruppe T:

Initialiser forbindelseskostnaden mellom T og seg selv til null.

Initialiser forbindelseskostnaden mellom T og hver andre gruppe til uendelig.

Skap en liste L som vil inneholde grupper som er i lik avstand fra målets forsterkergruppe T.

Initialiser listen L til å inneholde akkurat selve målets forsterkergruppe T.

Mens listen L ikke er tom:

Skap en tom liste L' av naboer av elementer på listen L.

For hver gruppe G i listen L:

For hver gruppe N som er en nabo av G:

La kostnad referere til summen av forbindelseskostnad mellom T og G, og forbindelseskostnad mellom G og N. Kostnaden mellom T og G ble bestemt i den foregående passering av algoritmen; forbindelseskostnaden mellom G og N er fra grupperegisteret.

Dersom kostnaden er mindre enn forbindelseskostnaden mellom T og N:

Sett forbindelseskostnaden mellom T og N

til kostnad.

Tilføy N til L' dersom den ikke allerede er

på den.

Sett L til L\

Et kostnadssett er et sett av grupper som er ekvivalente med hensyn til beste forsterkervalg (Best Repeater Selection). Dette betyr, gitt den tilgjengelige informasjon at den samme forsterker ville bli valgt for hvilken som helst av disse.

"Kostnadsprofilen" for en gruppe G defineres her som settet av kostnader mellom G og hver forsterker. To kostnadsprofiler sies å være ekvivalente dersom verdien i en profil avviker fra de tilsvarende verdier i den andre profilen med en konstant størrelse.

Så snart en klientgruppe er kjent, vil den beste forsterkervalgalgoritmen basere seg på kostnadsprofilen for informasjon om gruppen. Dersom to kostnadsprofiler er ekvivalente, ville BRS-algoritmen velge den samme forsterker gitt den ene eller andre profil.

Et kostnadssett er så et sett av grupper som har ekvivalente kostnadsprofiler.

Effelctiviteten av denne fremgangsmåte kan sees eksempelvis i tilfellet der samtlige baner til en forsterker fra en viss gruppe A passerer gjennom en viss andre gruppe B. De to gruppene har ekvivalente kostnadsprofiler (og er derfor i det samme kostnadssett) ettersom hvilken som helst forsterker som er best for gruppe A også vil være best for gruppe B, uansett hvilken bane som tas mellom de to gruppene.

Ved å normalisere kostnadsprofiler, kan ekvivalente kostnadsprofiler gjøres identiske. En normalisert kostnadsprofil er en kostnadsprofil i hvilken minimumkostnaden har verdien null. En normalisert kostnadsprofil beregnes ved å finne minimumskostnaden i profilen og subtrahere den verdien fra hver kostnad i profilen.

Kostnadssett blir så beregnet ved å anvende den følgende algoritme:

For hver gruppe G:

Beregn den normaliserte kostnadsprofil for G

Se etter et kostnadssett med den samme normaliserte kostnadsprofil.

Dersom et slikt sett finnes, tilføy G til det eksisterende kostnadssett;

ellers, skap et nytt kostnadssett med den beregnede, normaliserte kostnadsprofil som inneholder kun G.

Algoritmen for å finne kostnadssett anvender en nøkkeltabell for å redusere den tid som er nødvendig for å bestemme hvorvidt det ønskede kostnadssett allerede eksisterer. Nøkkeltabellen anvender en nøkkelverdi som beregnes fra kostnadsprofilen av G.

Hvert kostnadssett blir så nummerert med et unikt kostnadssettindeksnummer. Kost-nadssettene blir så anvendt på en likefrem måte for å generere forbindelseskostnadstabellen, hvilken gir kostnaden fra hvert kostnadssett til hver forsterker.

Som beskrevet nedenfor, vil gruppereduksjonstabellen kartlegge IP-adresse til et av disse kostnadssett.

IP-kartet er en sortert liste over regisfreringer som kartlegger IP-adresseområder til for-bindelseskostnadstabellnøkler. Formatet av IP-kartet er: <base IP address><max IP addressxLink Cost Table key>

der IP-adresser er i øyeblikket representert ved 32-bit heltall. Innføringene sorteres ved å la basisadresse gå ned og ved å la maksimurnsadresse gå opp blant like basisadresser, og ved å la forbindelseskostnadstabellnøkkelen gå opp blant like basisadresser og maksimumsadresser. Bemerk at områder kan overlappe.

Nevnte NetMap (nettkart) prosedyre genererer et mellomliggende IP-kart som inneholder et kart mellom IP-adresseområder og kostmdssettnummere som følger:

* For hvert kostnadssett S:

For hver gruppe G i S:

For hvert IP-adresseområde i G:

■ Tilføy en trippel (lav adresse, høy adresse, kosmadssettnummer av S) til IP-kartet.

IP-kartfilen blir så sortert ved å la basisadressen synke og ved å la maksimumsadressen stige blant like basisadresser, og ved å la kostnadssetmummeret stige blant like basisadresser og maksimumsadresser. Sorteringsrekkefølgen for basisadressen og maksimumsadressen minimaliserer tiden for å bygge opp gruppereduksjonstabellen og frembringer de riktige resultater for overlappende innføringer.

Til sist skaper nevnte AferMap-prosedyre gruppereduksjonstabellen ved å behandle det sorterte IP-kartet. Gruppereduksjonstabellen kartlegger IP-adresser (angitt ved områder) inn i kostnadssettnummerne. Spesiell behandling av IP-kartfilen kreves for å detektere overlappende adresseområder, og for å sammenføye hosliggende adresseområder for å mirumalisere størrelsen av gruppereduksjonstabellen.

En ordnet liste over adresseområdesegmenter opprettholdes, idet hvert segment består av en basisadresse B og et kostnadssettnummer N, sortert ved hjelp av basisadressen B.

(Den maksimale adressen for et segment er basisadressen for det neste segmentet minus en).

Den følgende algoritme anvendes:

Initialiser listen med elementer [-uendelig, NOGROUP], [+uendelig, NOGROUP].

For hver innføring i IP-kartet, på sortert måte, bestående av (b, m, s),

• Innfør (b, m, s) i listen (bemerk at IP-kartinnføringen er av formen (lav adresse, høy adresse, kosmadssettnurnmer av S))

For hvert reservert LAN-adresseområde (b, m):

Innfør (b, m, LOKAL) i listen.

For hver forsterker på adresse a:

Innfør (a, a, FORSTERKER) i listen.

For hvert segment S i den ordnede liste:

I'La S gå sammen med de følgende segmenter med det samme kostnadssett

■ Skap en gmppereduksjonstabellinnføring med basisadressen fra basisadressen av S,

maksimumadresse = neste segments basis -1,

gruppe ID = kostnadssettnummer av S.

Et reservert LAN-adresseområde er et adresseområde reservert for bruk av LAN'er som ikke bør fremkomme som en global Internet-adresse. LOKAL er en spesiell kostnadssettindeks som er forskjellig fra alle andre, som indikerer at området passer til en klient som aldri bør reflekteres. FORSTERKER er en spesiell kostnadssettindeks som er forskjellig fra alle andre, som indikerer at adresseområdet passer til en forsterker. NOGROUP er en spesiell kosmadssettindeks som er forskjellig fra alle andre og angir at dette området av adresser ikke har noen kjent kartlegging.

Gitt (B, M, N), insett en innføring i den beordrede adresselisten som følger: Finn det siste segmentet (AB, AN) for hvilket AB er mindre enn eller lik B. Dersom AB er mindre enn B, innfør et nytt segment (B, N) etter (AB, AN).

Finn det siste segmentet (YB, YN) for hvilket YB er mindre enn eller lik M. Erstatt med (XB, N) et hvilket som helst segment (XB, NOGROUP) for hvilket XB er større enn B og mindre enn YB.

Hvis YN ikke er N, og enten YN er NOGROUP eller YB er mindre enn eller lik

B,

La (ZB, ZN) være segmentet som følger (YB, YN).

Dersom M+l er mindre enn ZB, innfør et nytt segment (M+l, YN)

før (ZB, ZN).

Erstatt (YB, YN) med (YB, N).

Som forklart ovenfor med henvisning til figur 3 (B5), når en reflektor eller forsterker betjener en ressurs som selv innbefatter ressursidentifiserere (f.eks. en HTML-ressurs), modifiseres den ressursen (omskrives) for å pre-reflektere ressursidentifiseren (URL'er) av repeterbare ressurser som fremkommer i ressursen. Omskrivning sikrer at når en gjennomsøker ber om repeterbare ressurser identifisert ved den fordrede ressurs, far den disse fra en forsterker uten å gå tilbake til den opprinnelige tjener, men når den fordrer ikke-repeterbare ressurser identifisert ved den fordrede ressurs, vil den gå direkte til den opprinnelige tjener. Uten denne optimalisering, ville gjennomsøkeren enten foreta alle fordringer på den opprinnelige tjener (økende trafikk på den opprinnelige tjener og som nødvendiggjør langt flere omdirigeringer fra den opprinnelige tjener), eller den ville forta alle fordringer på forsterkeren (hvilket bevirker forsterkeren til redundant å fordre og kopiere ressurser som ikke kunne hurtigbufres, hvilket øker det overskytende som betjener slike ressurser).

Omskrivning krever at en forsterker er blitt valgt (som beskrevet ovenfor med henvisning til beste forsterkervelger). Omskrivning anvender et såkalt basisdirektiv (BASE directive). Basisdirektivet lar nevnte HTML identifisere en forskjellig basistjener. (Basisadressen er normalt adressen for HTML-ressursen).

Omskrivning utføres som følger:

Fl. Et basisdirektiv tilføyes ved begynnelsen av HTML-ressursen, eller modifiseres der det er nødvendig. Normalt vil en gjennomsøker fortolke relative URL'er til å være relative til den gjeldende basisadresse, nemlig nevnte URL for HTML-ressursen (side) der de påtreffes. Basisadressen som tilføyes angår ressursen på reflektoren som opprinnelig betjente resursen. Dette betyr at ubehandlede, relative URL'er (slik som de som genereres av Javasaipt™-programmer) vil bli fortol-ket som relative til reflektoren. Uten denne basisadresse, ville gjennomsøkere kombinere relative adresser med forsterkernavn for å skape URL<*>er som ikke var i den form som kreves av forsterkere (som beskrevet ovenfor i trinn Dl).

F2. Omskriveren identifiserer direktiver, slik som innleirede bilder og ankere, hvilke inneholder URL'er. Dersom omskriveren kjører i en reflektor, må den analysere HTML-filen for å identifisere disse direktiver.

Dersom den kjører i en forsterker, må omskriveren ha tilgang til forutberegnet informasjon som indentifiserer stedet for hver URL (anbragt i HTML-filen i trinn F4).

F3. For hver URL-som påtreffes i ressursen som skal skrives på ny, må omskriveren bestemme hvorvidt nevnte URL er gjentagbar (slik som i trinnene B1-B2). Dersom nevnte URL ikke er gjentagbar, blir den ikke modifisert. På den annen side, dersom nevnte URL er gjentagbar, modifiseres den for å referere til den valgte forsterker.

F4. Etter at samtlige URL' er er blitt identifisert og modifisert, dersom ressursen leveres til en forsterker, blir en tabell tilknyttet ved begynnelsen av ressursen som identifiserer stedet og innholdet av hver URL som påtreffes i ressursen. (Dette trinn er en optimaKsering som eliminerer behovet for å analysere HTML-ressurser på forsterkeren).

F5. Så snart alle endringer er blitt identifisert, blir en ny lengde beregnet for ressursen (side). Lengden innføres i HTTP-toppteksten forut for å betjene ressursen.

En utvidelse av HTML, kjent som XML, er i øyeblikket under utvikling. Prosessen med å omskrive URL'er vil være tilsvarende for XML, med visse forskjeller i mekanismen som analyserer ressursen og identifiserer innleirede URL'er.

Oppfinnelsen gjør det mulig å reflektere referanser til ressurser som betjenes av protokoller som er andre enn HTTP, eksempelvis filoverføringsprotokollen (FTP = File Transfer Protocol) og audio/video-strømningsprotokoller. Imidlertid, gir mange protokoller ikke evnen til å omdirigere fordringer. Det er imidlertid mulig å omdirigere referanser før fordringer faktisk foretas ved å omskrive URL'er som er innleiret i HTML-si-der. De følgende modifikasjoner til de ovenstående algoritmer anvendes for å under-støtte den mulighet.

IF4, omskriver omskriveren URL'er for tjenere dersom disse tjenere fremtrer i en konfigurerbar tabell over samvirkende opprinnelige tjenere eller såkalt ko-tjenere. Reflek-toroperatøren kan definere denne tabell til å innbefatte FTP-tjenere og andre tjenere. Et omskrevet URL som refererer til en ikke-HTPP-ressurs har formen:

http:// repeater>/ <origin server>@proxy=scheme> [ : <type>] @/ resource

der <scheme> er et støttet protokollnavn, slik som "ftp". Dette URL-format er et alter-nativ til den fonn som er vist i B3.

IC3, ser forsterkeren etter en protokoll som er innleiret i den ankommende fordring. Dersom en protokoll er tilstede og den fordrede ressurs ikke allerede er hurtigbufret, anvender forsterkeren den valgte protokoll i stedet for den gjeldende HTTP-protokoll for å fordre ressursen når den betjener den og å lagre den i hurtigbufferen.

I tillegg til den behandling som er beskrevet ovenfor, krever forsterkernettverket forskjellige mekanismer for systemkonfigurering og nettverkadministrering. Visse av disse mekanismer er beskrevet her.

Reflektorer tillater sine operatører å synkronisere forsterkerhurtigbuffere ved å utføre publiseringsoperasjoner. Behandlingen av å holde forsterkerhurtigbuffere synkronisert er beskrevet nedenfor. Publisering indikerer at en ressurs eller samling av ressurser er blitt endrete.

Forsterkere og reflektorer deltar i forskjellige typer av loggbehandling. Resultatet av logger samlet på forsterkerne blir samlet og sammenføyet med logger samlet på reflektorene, slik som beskrevet ovenfor.

Når en ny abonnent tilføyes nettverket, blir informasjon om abonnenten innført i en abonnenttabell hos hovedforsterkeren og forplantet til samtlige forsterkere i nettverket. Denne informasjon innbefatter den forpliktede aggregatinformasjonstakt (CAIR = CommittedAggregate Information Rate) for tjenere som tilhører abonnenten, og en liste over forsterkere som kan anvendes av tjenere som tilhører abonnenten.

Når en ny reflektor tilføyes nettverket, ganske enkelt kobler seg til og annonserer seg til en kontaktforsterker, fortrinnsvis ved å anvende et sikkert kryptert sertifikat som innbefatter forsterkerens abonnentidentifiserere.

Kontaktforsterkeren bestemmer hvorvidt reflektornettverkets adresse tillates for denne abonnent Dersom det er slik, godtar kontaktforsterkeren forbindelsen og oppdaterer reflektoren med alle nødvendige tabeller (ved å anvende versjonsnummere for å bestemme hvilke tabeller som er utdatert).

Reflektoren behandler fordringer under denne tid, men blir ikke "klargjort" (tillatt å reflektere fordringer) inntil samtlige av dens tabeller er eksisterende.

Forsterkerhurtigbuffere er koherent i det henseende at når en endring til en ressurs identifiseres av en reflektor, blir alle forsterkerhurtigbuffere underrettet, og godtar endringen i en enkelt transaksjon.

Kun identifisereren av den endrede ressurs (og ikke hele ressursen) sendes til forsterkerne. Identifisereren anvendes til effektivt å invalidere den tilsvarende hurtigbufrede ressurs hos forsterkeren. Denne prosess er langt mer effektiv enn å kringkaste innholdet av den endrede ressurs til hver forsterker.

En forsterker vil laste den nylig modifiserte ressursen neste gang den fordres.

En ressursendring identifiseres på reflektoren enten manuelt av operatøren, eller gjennom et skript når filer er installert på tjeneren, eller automatisk gjennom en endringsde-teksjonsmekanisme (f.eks. en separat prosess som kontrollerer regelmessig med hensyn til endringer).

En ressursendring bevirker reflektoren til å sende en "ugyldiggjør" melding til sin kontaktforsterker, som sender meldingen videre til hovedforsterkeren. Ugyldiggjørmeldin-gen inneholder en liste over ressursidentifiserere (eller regulære uttrykk som identifiserer mønstere over ressursidentifiserere) som er blitt endret. (Regulære uttrykk anvendes for å ugyldiggjøre en katalog eller hele tjeneren). Forsterkernettverket anvendes som en to-faseforpliktelsesprosess for å sikre at alle forsterkere korrekt ugyldiggjør en gitt ressurs.

Ugyldiggjøringsprosessen virker som følger:

Hoveddelen utsender en "fase 1" ugyldiggjøringsfordring til alle forsterkere og som indikerer ressursene og regulære uttrykk som beskriver sett av ressurser som skal ugyldig-gjøres.

Når hver forsterker mottar fase 1-meldingen, plasserer den først ressursidentifiserere eller regulære uttrykk i en liste over ressursidentifiserere i avhengighet av ugyldiggjøring.

En hvilken som helst ressurs som fordres (i C3) som er i den avventende ugyldiggjø-ringsliste kan ikke betjenes fra hurtigbufferen. Dette hindrer hurtigbufferen fra å fordre ressursen fra en kikkehurtigbuffer som muligens ikke har mottatt en ugyldiggjørings-melding. Skulle den fordre en ressurs på denne måte, kan den omplassere den nylige ugyldiggjorte ressurs ved hjelp av samme, nå forslitte data.

Forsterkeren sammenligner så ressursidentifisereren i hver ressurs i dens hurtigbuffer mot ressursidentifisererne og regulære uttrykk i listen.

Hver tilpasning ugyldiggjøres ved å markere den forslitt og eventuelt å fjerne den fra hurtigbufferen. Dette betyr at en fremtidig fordring for ressursen vil bevirke den til å hente en ny kopi av ressursen fra reflektoren.

Når forsterkeren har fullført denne ugyldiggjøring, returnerer den en erkjennelse til hovedenheten. Hovedenheten venter inntil alle forsterkere har erkjent ugyldiggjøringsford-ringen.

Dersom en forsterker ikke klarer å erkjenne innenfor en gitt periode, frakobles den fra hovedforsterkeren. Når den kobles til på ny, vil den bli fortalt å rense hele sin hurtigbuffer, hvilket vil eliminere eventuelt ensartethetsproblem. (For å unngå rensing av hele hurtigbufferen, bør hovedenheten holde en log over alle ugyldiggjøringer som er utført, sortert ved dato, og rense kun filer som er ugyldiggjort siden den siste gang den gjen-oppkoblende forsterker på vellykket måte fullførte en ugyldiggjøring. I det øyeblikket foretrukne utførelsesformer gjøres dette ikke, ettersom det antas at forsterkere sjelden vil bli frakoblet).

Når alle forsterkere har erkjent ugyldiggjøring (eller er blitt tidsutkoblet) utsender forsterkeren en "fase 2" ugyldighetsfordring til samtlige forsterkere. Dette bevirker forsterkerne til å fjerne de tilsvarende ressursidentifiserere og regulære uttrykk fra listen over ressursidentifiserere som venter på ugyldiggjøring.

I en annen utførelsesform vil ugyldiggjøi-ingsfordringen bli utvidet for å tillate en "tje-nerfremskyndelse" ("server push"). Ved slike fordringer, etter at fase 2 av ugyldiggjø-ringsprosessen er blitt fullført, vil forsterkeren som mottar ugyldiggjøringsfordringen umiddelbart be om en ny kopi av den ugyldiggjorte ressurs for å plassere den i sin hurtigbuffer.

Nett-tjener (web server) aktivitetslogger er fundamentale for å overvåke aktiviteten på et nettsted (web site). Denne oppfinnelse skaper "sanmienføyde logger" (merged logs) som kombinerer aktiviteten på reflektorene med aktiviteten på forsterkere, slik at en enkelt aktivitetslogg fremkommer på den opprinnelige tjener og viser samtlige nettres-sursfordringer (Web resource requests) som er foretatt på vegne av det stedet ved hvilken som helst forsterker.

Denne sammenføyde logg kan behandles ved hjelp av vanlige behandlingsverktøy, som om den var blitt generert lokalt.

På en periodisk basis, samler hovedforsterkeren (eller dens delegat) logger fra hver forsterker. Loggene som samles blir sammenføyer, sortert ved reflektoridentifiserer og tidsstempel og lagret i en datert fil på en per-reflektorbasis. Den sammenføyde logg for en gitt reflektor representerer aktiviteten for samtlige forsterkere på vegne av den reflektoren. På en periodisk basis, slik som konfigurert av reflektoroperatøren, kontakter en reflektor hovedforsterkeren for å be om dens sammenføyde logger. Den nedlaster disse og sarnmenføyer dem med sine lokalt opprettholdte logger, idet sortering skjer ved hjelp av tidsstempel. Resultatet er en sammenføyet logg som representerer all aktivitet på vegne av forsterkere og den gitte reflektor.

Aktivitetslogger blir eventuelt utvidet med informasjon som er viktig for forsterkernettverket, dersom reflektoren konfigureres til å gjøre dette ved hjelp av reflektoroperatø-ren. I særdeleshet indikerer en "utvidet statuskode" informasjon tan hver fordring, slik som:

1. fordring ble levert av en reflektor lokalt,

2. fordring ble reflektert til en forsterker,<*>

3. fordring ble levert av en reflektor til en forsterker,<*>

4. fordring for ikke-repeterbar ressurs ble levert av forsterker,<*>

5. fordring ble levert av en forsterker fra hurtigbufferen,

6. fordring ble levert av en forsterker etter fylling av hurtigbuffer,

7. fordring i påvente av ugyldiggjøring ble levert av en forsterker.

(Aktivitetene som er markert med "<*>" representerer mellomliggende tilstander i en fordring og vil normalt ikke fremtre i en endelig aktivitetslogg).

I tillegg inneholder aktivitetslogger en varighet, og utvidede presisjonsitdsstempler. Va-righeten gjør det mulig å analysere den tid som kreves for å betjene en ressurs, båndbredden som anvendes, antallet av fordringer som håndteres parallelt ved et gitt tids punkt og annen ganske nyttig informasjon. Det utvidede presisjonstidsstempel gjør det mulig nøyaktig å sammenføye aktivitetslogger.

Forsterkere anvender nettverktidsprotokollen (NTP = Network Time Protocol) for å opprettholde synkroniserte klokker. Reflektorer kan enten anvende NTP eller beregne en tidsreferanse for å tilveiebringe grovt nøyaktige tidsstempler i forhold til deres kontaktforsterker.

Forsterkernettverket overvaker og begrenser aggregattakten ved hvilken data leveres på vegne av en gitt abonnent av alle forsterkere. Denne mekanisme tilveiebringer de følg-ende fordeler: 1. gir et middel for å prise forsterkertj eneste;

2. tilveiebringer et middel for estimere og reservere kapasitet på forsterkere,

3. tilveiebringer et middel for å hindre klienter på et travelt sted fra å begrense tilgang til andre steder.

For hver abonnent blir en "terskelaggregatinformasjonstakt" (TAIR = threshold aggregate information rate) konfigurert og opprettholdt på hovedforsterkeren. Denne terskel er ikke nødvendigvis den forpliktede takt, men kan være et multiplum av forplik-tet takt, basert på en prismgspolitikk.

Hver forsterker måler infonnasjonstaktkomponenten fra hver reflektor for hvilken den leverer ressurser, periodisk (typisk ca. en gang pr. minutt), ved å registrere antallet av byter som sendes på vegne av den reflektoren hver gang en fordring leveres. Tabellen som derved skapes sendes til hovedforsterkeren en gang pr. periode. Hovedforsterkeren kombinerer tabellene fra hver forsterker, summerer den målte informasjonen fra hver reflektor over alle forsterkere som betjener eller leverer ressurser for den reflektoren, for å bestemme den "målte aggregatinformasjonstakt" (MAIR = measured aggregate information rate) for hver reflektor.

Dersom nevnte MAIR for en gitt reflektor er større en nevnte TAIR for den reflektoren, sendes MAIR ved hjelp av hovedenheten til alle forsterkere og til den respektive reflektor.

Når en reflektor mottar en fordring bestemmer den hvorvidt den mest nylige beregnede MAIR er større enn dens TAIR. Dersom dette er tilfellet, beslutter reflektoren sannsyn lighetsmessig hvorvidt refleksjonen skal undertrykkes, ved å betjene fordringen lokalt (i B2). Sannsynligheten for å undertrykke refleksjonen øker som en eksponentsialfunksjon av forskjellen mellom nevnte MAIR og nevnte CAIR.

Betjening av en fordring lokalt under en topp-periode kan belaste den lokale opprinnelige tjener, men det hindrer denne abonnent fra å ta mer enn allokert båndbredde fra det delte forsterkernettverket.

Når en forsterker mottar en fordring for en gitt abonnent (i C2), bestemmer den hvorvidt abonnenten kjører nær sin terskelaggregatinformasjonstak. Dersom dette er tilfellet, beslutter den sannsynlighetsmessig hvorvidt dens belastning skal reduseres ved å omdirigere fordringen tilbake til reflektoren. Sannsynligheten øker eksponentielt ettersom reflektorens aggregatinformasj onstakt nærmer seg sin grense.

Dersom en fordring reflekteres tilbake til en reflektor, kan en spesiell tegnstreng knyttes til ressursidentifisereren, slik at den mottagende reflektor ikke vil forsøke å reflektere den på ny. I det eksisterende system har denne streng formen

"src = overbelastning''.

Reflektoren tester for denne streng i B2.

Mekanismen for å begrense aggregatinformasj onstakten som er beskrevet ovenfor er temmelig grov. Den begrenser ved nivået av omganger med klienter (ettersom så snart en klient er blitt reflektert til en gitt forsterker, har omskrivningsprosessen tendens til å få klienten til å komme tilbake til den forsterkeren) og, i beste fall, individuelle fordringer for ressurser. En mer finkornet mekanisme for å håndheve TAIR grenser innenfor forsterkere virker ved å redusere båndbreddeforbruket hos en travel abonnent når andre abonnenter konkurrerer med hensyn til båndbredde.

Den finkornede mekanismen er en form for data "taktforming". Det utvider mekanismen som kopierer ressursdata til en forbindelse når et svar sendes til en klient. Når en utgangskanal etableres ved tidspunktet som en fordring mottas, identifiserer forsterkeren hvilken abonnent kanalen opererer for, i C2, og registrerere abonnenten i et datafelt knyttet til kanalen. Hver gang en "skrive"-operasjon er i ferd med å bli gjort til kanalen, vil den målte utgangsstrøm (Metered Output Stream) først inspisere de eksisterende verdier av MAIR og TAIR, beregnet ovenfor, for den gitte abonnent. Dersom nevnte MAIR er større enn nevnte TAIR, vil mekanismen så ta pause kortvarig før den utfører skriveoperasjonen. Pausens lengde er proporsjonal med størrelsen av det som nevnte MAIR overskrider nevnte TAIR. Pausen sikrer at oppgaver med å sende andre ressurser til andre klienter, kanskje på vegne av andre abonnenter, vil ha en mulighet til å sende sine data.

Forsterkernettverket er i stand til å gjenvinne når en forsterker eller nettverkforbindelse svikter.

En forsterker kan ikke operere så fremt den ikke er koblet til hovedforsterkeren. Hovedforsterkeren utveksler kritisk informasjon med andre forsterkere, innbefattende innfor-masjon om forsterkerbelastning, aggregatinformasjonstakt, abonnenter og forbindelseskostnad.

Dersom en hovedenhet svikter, sikrer en "rekkefølge"-prosess at en annen forsterker vil overta rollen som hovedenhet, og nettverket som et hele vil forbli operativt. Dersom en hovedenhet svikter, eller en forbindelse til en hovedenhet svikter gjennom et nettverks-problem, vil en hvilken som helst forsterker som forsøker å kommunisere med hovedenheten detektere svikten, enten via en indikasjon fra nevnte TCP/IP, eller ved tidsut-kobling fra en regulær "hjerteslag" melding som den sender til hovedenheten.

Når en hvilken som helst forsterker frakobles fra sin hovedenhet, vil den umiddelbart forsøke å gjenoppkoble til en rekke av potensielle hovedenheter basert på en konfigurerbar fil som er benevnt som dens "rekkefølgeliste".

Forsterkeren forsøker hvert system på listen i rekkefølge inntil den på vellykket måte får kobling til en hovedenhet. Dersom den under denne prosess kommer til sitt eget navn, tar den rollen av hovedenheten, og godtar forbindelser fra andre forsterkere. Dersom en forsterker .som ikke er på toppen av listen blir hovedenheten, kalles denne "midlertidig hovedenhet" (temporary master).

En nettverkoppdeling kan bevirke to grupper av forsterkere hver til å velge en hovedenhet. Når oppdelingen korrigeres, er det nødvendig at den mer seniorbaserte hovedenheten overtar nettverket. Når derfor en forsterker er en midlertidig hovedenhet forsøker den regelmessig å koble opp på ny til en hvilken som helst hovedenhet over seg i rekke-følgelisten. Dersom den klarer dette, vil den umiddelbart frakoble fra samtlige av forsterkerne som er koblet til den. Når de forsøker på ny sine rekkefølgelister, vil de koble til den mer seniorbaserte hovedforsterker.

For å hindre tap av data, vil en midlertidig hovedenhet ikke godta konfigurasjonsendrin-ger og behandler ikke loggfiler. For å påta seg disse oppgaver, må den informeres at den

er primær hovedenhet ved manuell modifisering av dens rekkefølgeliste. Hver forsterker i laster på ny regelmessig sin rekkefølgeliste for å bestemme hvorvidt den bør endre sin ide om hvem som er hovedenheten.

Dersom en forsterker frakobles hovedenheten, må den synkronisere på ny sin hurtigbuffer når den kobler seg til hovedenheten. Hovedenheten kan opprettholde en liste over

) nylige hurtigbufferugyldiggjøringer og sende til forsterkeren eventuelle ugyldiggjørin-ger som den ikke var i stand til å behandle mens den var frakoblet. Dersom denne liste ikke er tilgjengelig av en eller annen grunn (eksempelvis på grunn av at reflektoren er blitt frakoblet for lenge), må reflektoren ugyldiggjøre sin fullstendige hurtigbuffer.

En reflektor tillates ikke å reflektere fordringer såfremt den ikke er koblet til en forsterker. Reflektoren baserer seg på sin kontaktforsterker med hensyn til kritisk informasjon, slik som belastning og forbindelseskostnadstabeller, og eksisterende aggregatinformasjonstakt. En reflektor som ikke er koblet til en forsterker kan fortsette å motta fordringer og håndtere disse lokalt.

Dersom en reflektor mister sin forbindelse med en forsterker, på grunn av en forsterker-svikt eller en nettverksdriftsstans, fortsetter den å operere mens den forsøker å koble seg til en forsterker.

i Hver gang en reflektor forsøker å koble seg til en forsterker anvender den DNS for å

identifisere et sett av kandidatforsterkere gitt et domenenavn som representerer forsterkernettverket. Reflektoren forsøker hver forsterker i dette sett inntil den gjør en vellykket kontakt. Inntil en vellykket kontakt gjøres, leverer reflektoren samtlige fordringer

lokalt. Når en reflektor kobles til en forsterker, kan forsterkeren fortelle den om å fo-

) rsøke å kontakte en forskjellig forsterker, idet dette tillater forsterkernettverket å sikre at ingen individuelle forsterkere har for mange kontakter.

Når kontakt dannes tilveiebringer reflektoren versjonsnummeret for hver av dens tabeller til sin kontaktforsterker. Kontaktforsterkeren beslutter så hvilke tabeller som bør5oppdateres og sender passende oppdateringer til reflektoren. Så snart alle tabeller er blitt oppdatert, underretter forsterkeren reflektoren at den kan nå starte å reflektere fordringer.

Forsterkere blir intensjonsmessig utformet slik at en hvilken som helst stedfortredende hurtigbuffer kan anvendes som en komponent innenfor disse. Dette er mulig fordi forsterkeren mottar HTTP-fordringer og omdanner disse til en form som gjenkjennes av stedfortrederhurtigbufferen.

På den annen side, er flere modifikasjoner på vanlig stedfortrederhurtigbuffer blitt gjort og kan gjøres som optimaliseringer. Dette innbefatter i særdeleshet evnen til på hen-siktsmessig måte å ugyldiggjøre en ressurs, evnen til å støtte hurtigbufferkvoter, og evnen til å unngå å lage en ekstra kopi av hver ressurs når den går fra stedfortrederhurtigbufferen gjennom forsterkeren til fordreren.

I en foretrukket utførelsesform anvendes en stedfortrederhurtigbuffer til å implementere C3. Stedfortrederhurtigbufferen er dedikert til bruk kun av en eller flere forsterkere. Hver forsterker som krever en ressurs fra stedfortrederhurtigbufferen konstruerer en stedfortrederfordring fra den innadgående ressursfordring. En normal HTTP GET-fordring til en tjener inneholder kun banenavndelen av nevnte URL, planen og tjenernavnet er implisitt. (I en HTTP GET-fordring til en forsterker, innbefatter banenavndelen av nevnte URL navnet på den opprinnelige tjener på vegne av hvilken fordringen gjøres, som beskrevet ovenfor). Imidlertid, tar et stedfortredermiddel GET-fordring et fullstendig URL. Derfor må forsterkeren konstruere en stedfortrederfordring som inneholder nevnte hele URL fra banedelen av nevnte URL som den mottar. I særdeleshet, dersom den innkommende fordring har formen:

GET/ <origin server>/ <path>,

vil forsterkeren konstruere en stedfortrederfordring ha formen:

GET http:// <origin server>/ <path>,

og dersom den innkommende fordring har formen:

GET<origin server>@proxy=<scheme>:<type>@/ <path>

vil forsterkeren konstruere en stedfortrederfordring av formen:

GET<scheme>:// <origin server>/ <path>.

HTTP-svar iniieholder direktiver som er benevnt hurtigbufferstyrmgsdkektiver, hvilke anvendes til å indikere til en hurtigbuffer hvorvidt den tilknyttede ressurs kan hurtigbufres, og dersom dette er tilfellet, når det bør utløpe. En nettsted (Web site) administrator konfigurerer nettstedet for å tilknytte passende direktiver. Ofte vil administratoren ikke vite hvor lenge en side vil være fersk, og må definere en kort utløpstid for å hindre hurtigbuffere fra å levere forslitt data. I mange tilfeller vil en nettstedoperatør indikere en kort utløpstid kun for å motta fordringer (eller treff) som ellers ville bli maskert ved nærværet av en hurtigbuffer. Dette er kjent innenfor industrien som "hurtigbuffersprengning". Selv om visse hurtigbufferoperatører kan anse hurtigbuffersprengning å være uhøflig, kan annonsører som baserer seg på den informasjon anse det som viktig.

Når en ressurs lages i en forsterker, kan dens hurtigbufferdirektiver ignoreres av forsterkeren, på grunn av at forsterkeren mottar eksplisitt ugyldiggjøringshendelser for å bestemme når en ressurs er forslitt. Når en stedfortrederhurtigbuffer anvendes som hurtigbufferen på forsterkeren, kan de tilhørende hurtigbufferdirektiver midlertidig settes ut av funksjon. Imidlertid må de settes i funksjon på ny når ressursen betjenes fra hurtigbufferen til en klient, for å tillate hurtigbufferstyringspolitikken (innbefattende eventuell hurtigbuffersprengning) å finne sted.

Den foreliggende oppfinnelse inneholder mekanismer for å hindre stedfortrederhurtigbufferen innenfor en forsterker fra å honorere hurtigbufferkontrolldirektiver, mens det tillates at direktivene kan leveres fra forsterkeren.

Når en reflektor leverer en ressurs til en forsterker i B4, erstatter den samtlige hurtigbufferdirektiver med modifiserte direktiver som ignoreres av forsterkerens stedfortrederhurtigbuffer. Den gjør dette ved å gi en distinktiv streng prefiks, slik som "wr-" til begynnelsen av HTTP-merket. Således blir "utløper" "wr-utløper" og'Tiurtigbufferkon-troll" blir "wr-hurtigbufferkontroll". Dette hindrer selve stedfortrederhurtigbufferen fra å honorere direktivene. Når en forsterker betjener en ressurs i C4, og den fordrende klient ikke er noen annen forsterker, søker den etter HTTP-merker som begynner med "wr-" og fjerner nevnte "wr-". Dette tillater klientene å hente ressursen for å honorere direktivene.

Det finnes flere tilfeller der en ressurs kan hurtigbufres så lenge som den opprinnelige tjener konsulteres hver gang den betjenes. I et tilfelle, er fordringen for ressursen knyttet til en såkalt "cookie". Den opprinnelige tjener må presenteres med nevnte cookie for å registrere fordringen og bestemme hvorvidt den hurtigbufrede ressurs kan leveres eller ikke. I et annet tilfelle, blir fordringen for ressursen knyttet til en autentiseringstopptekst (som identifiserer fordreren med en brukeridentitet og passord). Hver ny fordring for ressursen må testes på den opprinnelige tjener for å sikre at fordreren er autorisert til å aksessere kilden.

Nevnte HTTP 1.1.-spesifikasjon definerer en svaroverskrift benevnt "må-revalidere" tillater en opprinnelig tjener å instruere et stedfortrederhurtigbuffer for å "re-validere" en ressurs hver gang en fordring mottas. Normalt blir denne mekanisme anvendt til å bestemme hvorvidt ressursen er fortsatt fersk. Ved den foreliggende oppfinnelse gjør nevnte "må-revalidere" det mulig å be en opprinnelig tjener om å validere en fordring som ellers leveres fra en forsterker.

Reflektorens regelbasis inneholder informasjon som bestemmer hvilke ressurser som kan gjentas, men må gyldiggjøres på ny hver gang de leveres. For hver slik ressurs, i B4, knytter reflektoren til seg en må-revalidere topptekst. Hver gang en fordring kommer til en forsterker for en hurtigbufret ressurs markert med en må-revalidere topptekst, blir fordringen videreformidlet til reflektoren for validering forut for betjening av den fordrede ressurs.

Hurtigbufferkomponenten i en forsterker deles blant de abonnenter som reflekterer klienter til den forsterkeren. For å tillate abonnenter rimelig tilgang til lagermuligheter, kan hurtigbufferen utvides til å støtte kvoter.

Normalt kan en stedfortrederhurtigbuffer konfigureres med en plateplassterskel T. Når mer enn T byter lagres i hurtigbufferen, forsøker hurtigbufferen å finne ressurser for å eliminere.

Typisk anvender en hurtigbuffer den minst-nylig-anvendte (LRU = least-recently-used) algoritme for å bestemme hvilke ressurser som skal elimineres. Mer sofistikerte hurtigbuffere anvender andre algoritmer. En hurtigbuffer kan også støtte flere terskelverdier, eksempelvis en nedre terskel som, når den nås, bevirker en bakgrunnsprosess med lav prioritet til å fjerne enheter fra hurtigbufferen, og en høyere terskel som, når den nås, hindrer ressurser fra å bli hurtigbufret inntil tilstrekkelig fri plateplass er blitt krevet på ny.

Dersom to abonnenter A og B deler en hurtigbuffer, og flere ressurser av en abonnent A aksesseres under en tidsperiode enn ressurser av abonnent B, så vil færre av B's ressurser være i hurtigbufferen når nye fordringer ankommer. Det er mulig at, på grunn av oppførselen av A, B's ressurser aldri vil bli hurtigbufret når de fordres. Ved den foreliggende oppfinnelse er denne oppførsel uønsket. For å møte dette problem, utvider oppfinnelsen hurtigbufferen på en forsterker til å støtte hurtigbufferkvoter.

Hurtigbufferen registrerer mengden av plass som anvendes av hver abonnent i Ds, og støtter en konfigurerbar terskel Tsfor hver abonnent.

Når en ressurs tilføyes hurtigbufferen (ved C3), blir verdien Ds oppdatert for abonnenten som tilveiebringer ressursen. Dersom Ds er større enn Ts, forsøker hurtigbufferen å finne ressurser for å eliminere blant de ressurser som er tilknyttet abonnent S. Hurtigbufferen blir effektivt oppdelt i separate områder for hver abonnent.

Den opprinnelige terskelen T er fortsatt understøttet. Dersom summen av reserverte segmenter for hver abonnent er mindre enn den totale plass som er reservert i hver hurtigbuffer, er det resterende området "felles" og utsettes for konkurranse blant abonnenter.

Bemerk at denne mekanisme kan implementeres ved å modifisere den eksisterende stedfortrederhurtigbuffer som omtalt ovenfor, eller den kan også implementeres uten å modifisere den stedfortredende hurtigbuffer, dersom stedfortrederhurh^bufferen i det minste gjøl- det mulig for et eksternt program å oppnå en liste over ressurser i hurtigbufferen, og å fjerne en gitt ressurs fra hurtigbufferen.

Når en forsterker mottar en fordring for en ressurs, kan dens stedfortrederhurtigbuffer konfigureres til å bestemme hvorvidt en kikkehurtigbuffer inneholder den fordrede ressurs. Dersom dette er tilfellet, vil den stedfortredende hurtigbuffer oppnå ressursen fra kikkehurtigbufferen, hvilket kan være hurtigere enn å oppnå den fra den opprinnelige tjener (reflektoren). En konsekvens av dette er imidlertid at omskrevne HTML-ressurser som hentes fra kikkehurtigbufferen vil identifisere den feilaktige forsterker. Således, for å tillate samvirkende stedforhederhurtigbuffere, blir ressurser fortrinnsvis omskrevet på forsterkeren.

Når en ressurs skrives på ny for en forsterker, blir et spesielt merke plassert ved begynnelsen av ressursen. Når det konstrueres et svar, inspiserer forsterkeren merket for å bestemme hvorvidt ressursen indikerer at ytterligere omskriving er nødvendig. Dersom dette er tilfellet, modifiserer forsterkeren ressursen ved å erstatte henvisninger til den gamle forsterkeren med henvisninger til den nye forsterkeren.

Det er kun nødvendig å utføre denne omskrivning når en ressurs leveres til stedfortrederhurtigbufferen på en annen forsterker.

Av og til, konstruerer en opprinnelig tjener en tilpasset ressurs for hver fordring (eksempelvis når det innsettes en annonse basert på historien av den fordrende klient). I et slikt tilfelle må ressursen leveres eller betjenes lokalt i stedet for å bh gjentatt. Generelt, inneholder en tilpasset ressurs, sammen med den tilpassende informasjon, tekst og referanser til andre, gjentagbare ressurser.

Prosessen som sammenstiller en "side" fra en tekstressurs og eventuelt en eller flere bil-deressurser utføres av nettgjennomsøkeren, dirigert av nevnte HTML. Imidlertid er det ikke mulig ved å anvende HTML å bevirke en gjennomsøker til å sammenstille en side ved å anvende tekst eller direktiver fra en separat ressurs. Derfor, vil tilpassede ressurser ofte nødvendigvis inneholde store mengder av statisk tekst som ellers ville være repeterbare.

For å løse den potensielle ineffektivitet, anerkjenner forsterkere et spesielt direktiv som er benevnt et "forsterkerside innbefatter". Dette direktiv gjør det mulig for forsterkeren å sammenstille en tilpasset ressurs, ved å anvende en kombinasjon av repeterbare og lokale ressurser. På denne måte kan den statiske teksten gjøres repeterbar, og kun det spesielle direktivet trenger å bli levert lokalt av reflektoren.

Eksempelvis kan en ressurs X bestå av tilpassede direktiver som velger et annonserende banner, fulgt av en stor tekstartikkel. For å gjøre denne ressurs repeterbar, må nettsted-adrmnistratoren bryte ut en andre ressurs, Y, for å velge nevnte banner. Ressurs X modifiseres ved å inneholde et forsterkersideinkluderende direktiv som identifiserer ressurs Y sammen med artikkelen. Ressurs Y skapes og inneholder kun de tilpassede (custom) direktiver som velger et annonsebanner. Ressurs X er nå repeterbar, og kun ressurs Y, som er relativt liten, er ikke repeterbar.

Når en forsterker konstruerer et svar, bestemmer den hvorvidt ressursen som leveres er en HTML-ressurs, og dersom dette er tilfellet, avsøker den med hensyn til forsterker-sideinnbefattende direktiver. Hvert slikt direktiv innbefatter et URL, hvilken forsterker løser og erstatter i stedet for direktivet. Hele ressursen må sammenstilles før den leve res, for å bestemme den endelige størrelse, idet størrelsen innbefattes i en svartopptekst foran ressursen.

Således er en fremgangsmåte og anordning for dynamisk å gjengi valgte ressurser i datamaskinnettverk tilveiebragt. En fagmann vil forstå at den foreliggende oppfinnelse kan utøves ved hjelp av andre enn de beskrevne utførelsesformer, hvilket er gitt i illu-strasjons hensikt og ikke begrensende, og den foreliggende oppfinnelse er begrenset kun av de etterfølgende patentkrav.

Claims (24)

1. Fremgangsmåte, i et datamaskinnettverk som omfatter et nettverk av forsterkertj enere (104) for å reprodusere minst noen ressurser lagret i minst én opprinnelsestjener (102), idet nevnte forsterkertj enere er tilpasset til å levere innhold til minst én klient (106),karakterisert vedat fremgangsmåten omfatter trinnene: a) å motta, på en programvaremodul, en fordring fra en klient om en ressurs fra en opprinnelig tjener, idet programvaremodulen velger en forsterkertjener i nettverket av forsterkere (104) til å levere ressursen til klienten, idet valget anvender kostnad innbefattende belastning eller forventet kostnad for transmisjon eller forventet transmisjonshastighet, og å bevirke klienten (106) til å fordre ressursen fra den valgte forsterkertjener (104) ved å anvende en ressursidentifiserer mottatt fra programvaremodulen, idet ressursidentifisereren utpeker den valgte forsterkertjener, b) som reaksjon på at den valgte forsterkertjener (104) anmodes om å levere ressursen til klienten (106), å bestemme ved den valgte forsterkertjener (104), hvorvidt den krevde ressurs er tilgjengelig på den valgte forsterkertjener (104), c) når det bestemmes at den krevde ressurs ikke er tilgjengelig på den valgte forsterkertjener (104), å oppnå den krevde ressurs fra den opprinnelige tjener (102) eller fra en annen forsterkertjener (104), og d) å tilveiebringe ressursen til klienten (106) fra den valgte forsterkertjener (104).

2. Fremgangsmåte som angitt i krav 1,karakterisert vedat programvaremodulen kan betjenes på en nettverkadresse som er forskjellig fra den for den opprinnelige tjener.

3. Fremgangsmåte som angitt i krav 1 eller 2,karakterisertv e d at nevnte trinn a) for å bevirke utføres ved hjelp av midler som er operativt forbundet med den minst ene opprinnelige tjener (102).

4. Fremgangsmåte som angitt i et hvilket som helst av kravene 1-3,karakterisert vedat en klient (106) kan fordre en ressurs ved å anvende minst en første ressursidentifiserer, og at nevnte trinn a) returnerer en andre ressursiden tifiserer som er distinkt fra nevnte første ressursidentifiserer og som er tilhørende den valgte forsterkertjener i nettverket av forsterkertj enere.

5. Fremgangsmåte som angitt i krav 4,karakterisert vedat den andre ressursidentifisereren er modifikasjon av den første ressursidentifisereren.

6. Fremgangsmåte som angitt i krav 4 eller 5,karakterisertved at den første ressursidentifisereren omfatter et vertsnavn.

7. Fremgangsmåte som angitt i et hvilket som helst av kravene 4-6,karakterisert vedat den andre ressursidentifisereren omfatter en inter-nettprotokoll- (IP) adresse eller et vertsnavn som er tilhørende en forsterkertjener i nettverket av forsterkertjenere.

8. Fremgangsmåte som angitt i et hvilket som helst av kravene 4 - 7,karakterisert vedat den første ressursidenitfisereren er tilhørende et sted for ressursen.

9. Fremgangsmåte som angitt i et hvilket som helst av kravene 1-8,karakterisert vedat nevnte bevkkningsdel i trinn a) forsyner klienten med en modifisert ressursidentifiserer som utpeker en valgt forsterker i forsterkertj enernettverket.

10. Fremgangsmåte som angitt i et hvilket som helst av kravene 1-9,karakterisert vedat trinnet som er relatert til å velge foretar et valg basert i det minste delvis på en nettverkadresse som er tilhørende klienten.

11. Fremgangsmåte som angitt i et hvilket som helst av kravene 1 - 10,karakterisert vedat trinnet som er relatert til å velge foretar et valg basert i det minste delvis på en belastning av minst noen av forsterkertj enerne.

12. Fremgangsmåte som angitt i et hvilket som helst av kravene 1-11,karakterisert vedat trinnet som er relatert til å velge foretar et valg basert på minst delvis en kostnad eller hastighet for transmisjon mellom minst noen av forsterkertjenerne og klienten.

13. Fremgangsmåte som angitt i et hvilket som helst av kravene 4-12,karakterisert vedat nettverket er del av internett, og at den første ressursidentifisereren er en uniform ressurslokaliserer (URL) for å utpeke ressurser på internett.

14. Fremgangsmåte som angitt i et hvilket som helst av kravene 4-13,karakterisert vedat identifisererne er uniforme ressurslokaliserere (URL).

15. Fremgangsmåte som angitt i et hvilket som helst av kravene 4-14,karakterisert vedat ressursidentifisererne omfatter navn som skal løses av en domenenavntjeneste (DNS) eller IP-adresser.

16. Fremgangsmåte som angitt i krav 15,karakterisertved at navnene er vertsnavn eller domenenavn.

17. Fremgangsmåte som angitt i et hvilket som helst av kravene 4-16,karakterisert vedat den første ressursidentifisereren er innbefattet i en annen ressurs som tidligere er fordret av og levert til klienten.

18. Fremgangsmåte som angitt i et hvilket som helst av kravene 4-17,karakterisert vedat stedet som er angitt av den første ressursidentifisereren er en opprinnelig tjener.

19. Fremgangsmåte som angitt i et hvilket som helst av kravene 4-18,karakterisert vedat stedet som er angitt av nevnte første ressursidentifiserer er distinkt fra nettverket av forsterkertj enere.

20. Fremgangsmåte som angitt i et hvilket som helst av kravene 1 - 19,karakterisert vedat den fordrede ressurs er et innleiret bilde.

21. Fremgangsmåte som angitt i et hvilket som helst av kravene 1-20,karakterisert vedat den fordrete ressurs selv inneholder ressursidentifiserere, og at fremgangsmåten dessuten omfatter å skrive på ny den fordrede ressurs for å erstatte minst noen av ressursidentifisererne som befinner seg deri med modifiserte ressursidentifiserere som utpeker en valgt forsterkertjener i forsterkertj enernettverket.

22. Fremgangsmåte som angitt i krav 21,karakterisertved at de modifiserte ressursidentifisererne utpeker den valgte forsterker i forsterkertj enernettverket i stedet for en opprinnelig tjener.

23. Fremgangsmåte som angitt i et hvilket som helst av kravene 1-22,karakterisert vedat ressursene velges fra gruppen bestående av: statisk og dynamisk videoinnhold, audioinnhold, tekst, bttdeinnhold, nettsider, html-filer, xml-filer, filer i et formatteringsspråk, dokumenter, hypertekstdokumenter, datafiler og innleirede ressurser.

24. Datamaskinnettverk omfattende et nettverk av forsterkertj enere (104) for å reprodusere minst noen ressurser lagret i minst én opprinnelig tjener (102), idet nevnte tjenere er tilpasset til å levere innhold til minst én klient (106),karakterisert vedat datamaskinnettverket omfatter midler for å utføre fremgangsmåten som angitt i et hvilket som helst av kravene 1 - 23. °