NO319874B1 - Fremgangsmate og apparat i et kommunikasjonsnett - Google Patents

Description

Oppfinnelsens område

Den foreliggende oppfinnelse vedrører kommunikasjonsnett og spesielt sanntidskommunikasjon mellom flere brukere av en applikasjon i et slikt nett.

Beskrivelse av nærliggende litteratur

Flerbrukerkommunikasjonsapplikasjoner blir for tiden utviklet for eksempel for flerbrukerspill. Slike spill kan spilles av et antall brukere koblet til den samme LAN eller til og med til forskjellige deler av et større nett, slik som Internett. For slike applikasjoner blir tre hovedsynkroni-seringsmodeller benyttet: klient-tjener-synkronisering, punkt-til-punkt-synkronisering eller kringkastingssynkronisering. Noen flerbrukerspill på Internett i dag involverer opptil 100 000 spillere, der flere tusen kan spille samtidig. Alle synkroniseringsfremgangsmåter som benyttes i dag, forårsaker relativt lange forsinkelser. Derfor er flerbrukerspill som spilles over Internett i dag, spill som ikke er hastighetskritiske. For eksempel kan ikke raske "ac-tion" -spill, slik som bilspill eller kampspill, hvor brukeren må reagere på det som skjer innen brøkdeler av et sekund, spilles med akseptabel kvalitet ved å benytte noen av s t andard synkroni s e r ing s f remgang småtene.

Innringningsnett bruker typisk klient-tjener-synkronisering. I dette tilfellet mottar en tjener data fra alle spillerne. Den må finne ut hva slags informasjon hver spiller trenger, og sende dette. Den sentrale tjener er en åpenbar flaskehals i systemet. Sentrale klient-tjener-spill kan støtte 2-250 spillere. Det høye antallet refererer til tjenere hvor oppdateringsraten er så lav som 2 Hz. Den sentrale tjener bidrar til ventetid både på grunn av økt transportavstand og på grunn av prosessering og fordelings-forsinkelse i tjeneren. Anta for eksempel en situasjon hvor klientene er på den amerikanske vestkyst mens tjeneren er på den amerikanske østkyst. Omkring 80 ms med transportven-tetid og i det minste 10 ms med prosesseringsventetid er forårsaket av klient-tjener-operasjonsmodusen. Derfor er ikke klient-tjener-synkronisering brukbart for sanntidsapp-likasjoner med et stort antall spillere hvor forsinkelsen er kritisk.

Punkt-til-punkt-synkronisering betyr at alle klienter sender applikasjonsdata direkte til alle andre klienter. Denne modellen benyttes ofte i spill som spilles over det offent-lige Internett. Spillutviklere tilveiebringer en gratis applikasjonslobbytjener hvor spillere møtes for å sette opp spill og for å ta del i pågående spill. Idet et spill er startet, spilles det i punkt-til-punkt-modusen uten å benytte noen ressurser fra spillutviklerens lokasjon.

Punkt-til-punkt-synkronisering har åpenbare skalerbarhets-problemer siden nettlasten er proporsjonal med kvadratet av antall spillere, klientaksessbåndbredden og CPU-effekts-kravene er proporsjonale med antall spillere. Nyttelasten i hver pakke er 10-40 bytes, hvilket betyr at protokollkost-nadene vanligvis utgjør mer enn 50 %. Små spillpakker gir en større protokollkostnad. Med hode-kompresjonsmetoder kan imidlertid denne kostnaden reduseres betydelig. Punkt-til-punkt-spill over Internett lider av uforutsigbare forsinkelser og mange kollapser på grunn av tap av synkronisering.

Følgelig er punkt-til-punkt-synkronisering også best tilpasset små nett, mer kommunikasjon over relativt korte dis-tanser og mellom et begrenset antall brukere.

Kringkastingssynkronisering kan benyttes av et begrenset antall spillere på et LAN-nettverk, men er ikke brukbart for større nett.

På grunn av restriksjonene som er satt av synkroniserings-metodene, er ikke multideltakerkommunikasjon med gode sann-tidskarakteristikker mulig med dagens teknologi. Med multi-east (kringkasting av data til flere brukere) kan informasjonen som må transmitteres i nettet reduseres betydelig, gjennom at informasjon bare trenger å transmitteres én gang til hver multicasttjener, i stedet for én gang for hver bruker. Hver multicasttjener kopierer så informasjonen og transmitterer den til brukerne den er koblet til. En selek-sjon av informasjon hver bruker trenger å motta kan også gjennomføres. Dette kan redusere trafikken både mellom tjenere og mellom hver tjener og dens brukere. En slik løsning til bruk i spill er forklart i US 5,841,980.

I systemet i US 5,841,980 har hver bruker bare informasjon vedrørende parten i spillet som er relevant for brukeren i den aktuelle situasjon, for eksempel informasjon om det geografiske området han befinner seg i. Hvis omstendighete-ne endres, for eksempel hvis brukeren forflytter seg til et annet rom, vil informasjon som er viktig for de nye omgi-velsene ikke være tilgjengelig for brukeren.

Formålet med oppfinnelsen

Det er et formål ved oppfinnelsen å forbedre sanntidsutfø-relsen i kommunikasjonsnett, spesielt for samvirkende kommunikasjon mellom et stort antall deltakere.

Oppsummering av oppfinnelsen

Dette formål oppnås i henhold til oppfinnelsen med en tjener enhet til bruk i kommunikasjonsnett, nevnte tjenerenhet består av mottakingsmiddel for å motta informasjon fra i det minste én første klientenhet, nevnte informasjon består idet minste av én del av tilstandsinformasjonen om en distribuert interaktiv applikasjon, nevnte tjenerenhet karakteriseres ved at den omfatter: - tilstandsinformasjonslagringsmiddel for lagring av applikasjonstilstandsinformasjon som er med i informasjonen mottatt gjennom mottakingsmiddelet fra i det minste én av nevnte første og andre klientenhet,

første transmisjonsmiddel for å videresende tilstandsinformasj onen mottatt fra nevnte i det minste første klientenhet til i det minste én annen node i nettet, - andre transmisjonsmiddel for å transmittere i det minste en del av informasjonen lagret i nevnte tilstandsinformasj onslagringsmiddel til nevnte i det minste én klientenhet.

Dette gjør det mulig å holde hele tilstanden av applikasjonen i én eller flere enheter i nettet, noe som fjerner behovet for at hver klient skal lagre hele tilstanden, for derved å redusere behovet for minnekapasitet i hver klient og også båndbredden som er nødvendig for kommunikasjon mellom hver klient. Hvis hver del av tilstanden til applikasjonen er lagret i mer enn én nettnode eller klient, oppnås en backup-mulighet.

Formålet oppnås også i henhold til oppfinnelsen gjennom en klientenhet til bruk i en terminal i et kommunikasjonsnett som består av en applikasjonsprogramvare for en distribuert interaktiv applikasjonsklientenhet som karakteriseres ved at den består av: - i det minste ett inngangsmiddel for å lese et inngangssignal fra nevnte terminal, nevnte inngangssignal består i det minste av applikasjonstilstandsinformasjon for den distribuerte interaktive applikasjon, - transmisjonsmiddel for å transmittere applikasjonstilstandsinformasjon til en applikasjonsaksesstjener, - mottakingsmiddel for å motta i det minste applikasjonstilstandsinformasjon for den distribuerte interaktive applikasjon fra nevnte applikasjonsaksesstjener ,

- middel for å vise nevnte tilstandsinformasjon.

Apparatet i henhold til oppfinnelsen er spesielt nyttig for distribuerte interaktive applikasjoner, spesielt de som involverer sanntidskommunikasj on.

Mottakingsmiddelet til nevnte tjenermiddel er fortrinnsvis tilpasset til: - å motta subskripsjonsinformasjon fra i det minste første klient, nevnte subskripsjonsinformasjon identifiserer objekter til den distribuerte interaktive applikasjon om hvilken nevnte første klient ønsker å motta informasjon, - å transmittere informasjon til nevnte i det minste én klientenhet avhengig av subskripsjonsinformasjon mottatt fra nevnte klientenhet, - nevnte tjenerenhet omfatter videre i det minste én klientsubskripsjonsliste for å lagre nevnte subskripsj onsinformasjon.

Følgelig består nevnte klientenhet ytterligere av middel for å sette subskripsjonsinformasjon for å spesifisere i det minste ett objekt til den distribuerte interaktive applikasjon fra hvilken tilgjengelig informasjon skal mottas, og middel for å transmittere nevnte subskripsjonsinformasjon til nevnte applikasjonsaksesstjener.

Dette reduserer mengden informasjon som må transmitteres til hver bruker, noe som dermed reduserer transmisjonsforsinkelsen og også hjelper hver bruker til å analysere informasjon, siden bare den viktigste informasjonen den bestemte bruker vises for denne brukeren. Hver klient er i stand til å bestemme selv hva som er viktig.

I en foretrukket utførelse er mottakingsmiddelet tilpasset til å motta hasteinformasjon vedrørende nevnte første klient fra i det minste en andre klient. Hasteinformasjonen kan transmitteres til den første klienten, eller applikasj onstilstandsinf ormas j onen vedrørende nevnte andre klient kan sendes videre til i det minste nevnte første klient avhengig av nevnte hasteinformasjon. Hasteinformasjonen kan også benyttes til å indikere at den bestemte applikasjons-tilstandsinf ormas jon skal videresendes til nevnte første klient. Hasteinformasjonen kan benyttes til å endre en kli-entsubskripsjon.

I nevnte foretrukne utførelse omfatter klientenheten videre middel for å sette hastedata for å spesifisere i det minste én annen klient som skal motta tilstandsinformasjon fra klienten så snart som mulig.

Transmisjonsmidlet for klientenheten for å transmittere applikasjonstilstandsinformasjon kan med fordel være tilpasset til å ordne informasjon i objektinformasjonspakker, hvor hver pakke er relatert til en objektsammensatt del av applikasjonen, før pakkene transmitteres til tjenerenheten, og nevnte mottakingsmiddel er tilpasset til å trekke ut informasjon fra pakkene mottatt fra tjenerenheten.

Applikasjonsaksesstjenersystemet er uavhengig av applikasjonen og kan derfor støtte en stor variasjon av forskjellige applikasjoner.

Applikasjonsaksesstjenerenhetene som jobber sammen, kan jobbe over ett nettverk som fortrinnsvis tilbyr reservert eller administrert transmisjonskapasitet. Det samlede bånd-breddekravet for en applikasjon kan estimeres av nettadmi-nistrasjonssysternet og tilstrekkelig nettressurser kan al-lokeres til det reserverte nett som kobles til applikasjonsaksesstjenerenhetene. Nye applikasjoner er bare lovlig hvis ressurser er tilgjengelig. Nettadministrasjonen styrer også gjensending og duplikasjonspolitikken til applikasj onsaksesst jenerenhetene. Multicasting og ressursreserva-sjonsprotokoller kan benyttes på den samlede strøm mellom applikasjonsaksesstjenerenhetene. Fordelen med dette systemet er at ressursreservasjonen på spillernivået ikke er nødvendig. Applikasjonsklientene kan vanligvis håndtere tilfeldig mistede pakker hvis den generelle statistiske ut-førelsen er god. Å bruke applikasjonsaksesstjeneren i henhold til oppfinnelsen betyr at en spillklient aldri vil miste synkroniseringen permanent siden applikasjonsaksesstjenerenhetene alltid opprettholder spilltUstanden.

Andre fordelaktige trekk ved foreliggende oppfinnelse vil fremgå av de selvstendige og uselvstendige kravene.

Kort beskrivelse av tegningene

Apparatet og fremgangsmåten i henhold til oppfinnelsen vil bli beskrevet i nærmere detalj i det følgende, med henvis-ning til de vedlagte tegninger, hvor: Figur 1 illustrerer en utførelse av et nett i henhold til opp f inne1sen, Figur 2 illustrerer en applikasjonsaksesstjener i henhold til en første utførelse av oppfinnelsen. Figur 3 viser en utførelse av en applikasjonstilstandsliste i henhold til oppfinnelsen, Figur 4 viser en applikasjonsklient i henhold til en utfø-relse av oppfinnelsen, Figur 5 illustrerer kommunikasjonsstakkene som benyttes i henhold til en utførelse av oppfinnelsen. Figur 6 viser en andre utførelse av applikasjonsaksesstjeneren i henhold til oppfinnelsen, Figur 7 viser en applikasjonsruter benyttet i den andre ut-førelsen av applikasjonsaksesstjeneren, Figur 8 er en skjematisk representasjon av en hierarkisk struktur av applikasjonsaksesstjenerne som benyttes i en utførelse av oppfinnelsen.

Detaljert beskrivelse av utførelser

Figur 1 viser en utførelse av et kommunikasjonsnett i henhold til oppfinnelsen. I henhold til oppfinnelsen består nettet i det minste av én applikasjonsaksesstjener. I figur 1 er en første 1, en andre 3 og en tredje 5 applikasjonsaksesstjener vist, koblet til hverandre gjennom et nett 7, for eksempel et reservert telekommunikasjonsnett. Dette kan også være en hvilken som helst annen nettype, men nett der det er mulig å reservere nettressurser, slik som Internett, kan imidlertid tilveiebringe en lavere kvalitet hvis den er tungt lastet. Et antall klienter 11, 12, 13, 14, 15 er også koblet til nettet 7. En klient kan tilkobles passende applikasj onsaksesst jener 1, 3 eller 5 på en hvilken som helst måte som er kjent på fagområdet, noe som vil bli diskutert i nærmere detalj nedenfor.

Klienter kan kommunisere med hverandre gjennom applikasjonsaksesstjeneren for å kjøre en distribuert interaktiv applikasjon hvor et stort antall deltakere påvirker og bidrar til applikasjonens tilstand, for eksempel et sanntids multibrukerspill. Mellom hver klient og applikasjonsaksesstjeneren til hvilken den er koblet, vil det vanligvis være en lav kapasitetsforbindelse, slik som en modemforbindelse. Mellom to applikasjonsaksesstjenere vil imidlertid høye og variable nettverkskapasiteter være tilgjengelig. Applikasjonsaksesstjeneren i henhold til oppfinnelsen er derfor tilpasset til å håndtere informasjonen om tilstanden til applikasjonen på en slik måte at de reduserer informasjons-mengden transmittert til hver klient med å transmittere til hver klient bare informasjon som er mest relevant for denne klienten. Mellom applikasjonsaksesstjenerne vil transmi-sjonskapasiteten normalt ikke være et problem, og derfor kan mer informasjon transmitteres mellom applikasjonsak-sesst jenerne. En eller flere applikasjonslobbytjenere 21 som er kjent i faglitteraturen, kan også være tilstede i nett. Disse tjenerne består typisk av funksjoner som gjør det mulig for klientene å registrere seg for en bestemt tjenestetype, håndtere faktureringsfunksjoner, etc.

I henhold til oppfinnelsen finnes programvaren som kreves for applikasjonen i klienten 11, 12, 13, 14, 15. For å bruke kommunikasjonsfunksjonen i henhold til oppfinnelsen må brukeren derfor sørge for at han har applikasjonsprogramvaren som er nødvendig. Applikasjonsprogramvaren kan skaffes på en hvilken som helst måte som er kjent på fagområdet, for eksempel nedlastet fra Internett eller installert fra en CD-ROM. Hvis applikasjonen påkrever det må han også registrere seg i applikasjonslobbytjeneren. Applikasjonslob-bytj eneren 21 vil typisk tilveiebringe en adresse, som vanligvis er en IP-adresse og et portnummer til en eller flere applikasjonsaksesstjenere 1, 3, 5, men denne adressen kan også skaffes på en hvilken som helst annen måte.

Brukeren kobles til en applikasjonsaksesstjener på en måte som er vanlig på fagområdet, normalt ved å legge inn IP-adressen til applikasjonsaksesstjeneren eller en pool med applikasjonsaksesstjenere. Flere algoritmer eksisterer for å velge den som passer best av et antall noder i nettet identifisert med samme adresse. Applikasjonsaksesstjeneren mottar informasjon fra brukeren og begynner å transmittere informasjon til brukeren, noe som vil bli beskrevet i nærmere detalj i det følgende. I lokasjonen for at klienten logger seg inn i applikasjonsaksesstjener, kan applikasj onslobbytj eneren også transmittere klientnettverksadres-sene til applikasjonsaksesstjenerne.

Applikasjonen antas å bestå av et sett objekter som styres av deltakerne. Et objekt er en entitet i applikasjonen som styres av en person eller som genereres i en klient og ikke kan regenereres lokalt i hver applikasjonsklient, for eksempel styrt av en tilfeldighetsgenerator eller andre uforutsigbare beregningsprosesser. Applikasjonsobjekter kan være ting som deltakerne intuitivt vil gjenkjenne som objekter, eller spillfigurer, men de kan også være bakgrunns-datastrukturer slik som omgivelsesvariable som styres av spillerne. Et applikasjonsobjekt styres av en eller flere spillere. Hvert objekt har typisk et sett med egenskaper og attributter som kan forandres mens applikasjonen går. I et spill kan disse egenskapene være en karakters styrke og andre kapabiliteter, eller maksimumshastigheten til en bil, og attributtene kan for eksempel være objekter som er samlet av karakteren.

Informasjonen mottatt fra brukeren vil normalt bestå av tre forskjellige informasjonstyper i tillegg til signalerings-kostnaden: tilstandsinformasjon, subskripsjonsinformasjon, styredata og hasteinformasjon. Tilstandsinformasjonen er informasjon om objektet eller objektene som styres av brukeren, som skal distribueres til andre brukere av applikasjonen. Subskripsjonsinformasjonen lister opp klientens egenskaper vedrørende forskjellige applikasjonsobjekter tilveiebrakt av applikasjonsaksesstjenerne. For eksempel skal informasjon vedrørende en bestemt objektgruppe mottas idet den blir tilgjengelig, eller så ofte som mulig, mens informasjon fra andre objektgrupper haster det ikke så mye med. Forskjellige prioritetsnivåer kan være satt, for eksempel i form av akseptable forsinkelser eller prioriteter i tilfelle tap av båndbredde. Hasteinformasjonen generert av en klient kan benyttes til å overstyre eller endre subskripsjonene til en annen klient slik at en annen klient vil motta informasjon om objekter som ikke er med i dens subskripsjon, eller for å sørge for at klienten ikke mottar en bestemt informasjon. Alle tre informasjonstyper vil diskuteres i nærmere detalj nedenfor.

Som et eksempel, vil applikasjonen til et sanntidsspill som spilles av et stort antall brukere bli beskrevet. Slike spill spilles i dag med et begrenset antall spillere lokalisert relativt nær hverandre, for eksempel i et LAN-nett. I et WAN-nett kan et spill i fremtiden involvere flere tusen spillere, typisk distribuert over et stort spillfelt, eller over et virtuelt geografisk område. Med dagens teknologi er dette ikke mulig med en aksepterbar kvalitet som diskutert ovenfor.

Hver spiller affekteres umiddelbart bare ved ting som skjer i nærheten av ham i det virtuelle spillområde. Jo lengre vekk en annen spiller er, jo mindre viktig vil endringene for denne spilleren være. For eksempel kan en spiller være involvert i en kamp med en første fiendtlig spiller, mens en vennlig spiller kan komme til unnsetning, mens en andre fiendtlig spiller kan prøve å stoppe den vennlige spilleren. Samtidig vil andre spillere gjøre ting som kan være interessante senere, men for tiden er spillerens hovedbe-kymring å overleve kampen. Derfor må bevegelsene til den første fiendtlige spiller vises umiddelbart. Bevegelsene til den vennlige spiller og den andre fiendtlige spiller bør også gis en høy prioritet, mens ting som skjer langt unna skal gis en lav prioritet.

I eksemplet som er diskutert ovenfor vil konfigurasjonen til spillerne åpenbart endre seg slik at annen tidsinforma-sjon fra andre spillere vil ha den høyeste prioritet, vanligvis spilleren som er lokalisert nærmest brukeren på git-te tidspunkt.

Applikasjonsaksesstjeneren håndterer kommunikasjon med applikasj onsklienter. Den mottar informasjon om klientens handlinger som affekterer applikasjonstilstanden og annen informasjon. Den transmitterer også applikasjonstilstands-inf ormas jon fra andre deltakere til deltakere i henhold til deres subskripsjoner. Hver applikasjonsklient setter subskripsjoner i forhold til hvilken applikasjonsinformasjon som skal mottas, og transmitterer informasjon om disse subskripsjonene til applikasjonsaksesstjeneren. Applikasjonsaksesstjeneren lagrer og oppdaterer en liste over klientenes subskripsjoner som betjenes av applikasjonsaksesstjeneren. Subskripsjonene til enhver klient benyttes for å bestemme hvilke data som skal sendes til denne klienten. En klient kan også sette subskripsjoner for en annen klient. I operasjonsmodus kan en masterklient for eksempel sette subskripsjonene til alle andre klienter.

Applikasjonsaksesstjeneren til hvilken en klient er koblet, er denne klientens lokale applikasjonsaksesstjener, og klienten refereres til som en lokal klient til denne applikasj onsaksesstj ener.

Applikasjonsaksesstjeneren inneholder også en klientautori-tetsliste. Hver klient har retten til å endre tilstanden til ett eller flere spillobjekter. Klientautoritetslisten har en inngang for hver klient hvor identifikatorene til objektene som styres av klienten er lagret. Applikasjonsak-sesst jeneren sjekker autoriteten hver gang den mottar ob-jekttilstandsinformasjon fra en klient. Spilltilstanden vil bli oppdatert bare hvis en identifikator funnet i informa-sjonspakken matcher et av numrene i inngangen for klienten i autorisasjonslisten, ellers ignoreres informasjonen. Ob-jekttilstandsinformasjonen som kommer fra andre applikasj onsaksesst jenerenheter, verifiseres ikke siden applikasjonsaksesstjeneren som sender informasjonen allerede er sjekket for sin autoritet.

Hver applikasjonsaksesstjener kommuniserer også med andre applikasjonsaksesstjenerenheter, sender applikasjonstil-standsinf ormas jon og eventuelt oppsamlede subskripsjoner til dem og mottar den samme informasjonstypen fra dem. Vanligvis er informasjonen som skal transmitteres til andre applikasjonsaksesstjenere pakket i henhold til en passende protokoll og transmittert uten å bli prioritert eller sor-tert på noen måte. Det vil selvfølgelig være mulig å velge informasjonen som skal transmitteres til hver applikasjons-aksesst jener avhengig av brukerens subskripsjoner i sine lokale klienter. Oppsamlede subskripsjoner er summen av alle applikasjonsobjektforespørsler fra klienter som hører til en gitt applikasjonsaksesstjener. For eksempel kan applikasj onsaksesst jeneren bruke multicasting til andre appli-kasjonsaksesst jenerenheter . Dette sikrer at hver applikasj onsaksesstjenerenhet mottar all nødvendig oppdatering og at spilltilstanden distribueres effektivt over applikasj onsaksesstjenerenhetene.

Hastedata settes av en klient hvis dataene er viktig for en annen klient uten at denne klienten er klar over dette og derfor ikke kan sette sine egne subskripsjoner. Hastestatu-sen defineres derfor av klienten som sender og kan være forskjellig for forskjellige mottakingsklienter. Applikasjonsaksesstjeneren varsler den mottagende klient hvis hastedata venter. Hasteinformasjon kan også benyttes til å forhindre videresending av en bestemt informasjon til en eller flere klienter.

Hver applikasjonsaksesstjener lagrer og oppdaterer også en fullstendig eller delvis kopi av applikasjonstilstanden. Dem imellom må applikasjonsaksesstjenerenhetene som er tildelt en kommunikasjonssesjon, lagre den fullstendige applikasj onstilstand. I det enkleste tilfellet lagrer hver app-likasjonsaksesst jener den fullstendige applikasjonstil-stand , men det er også mulig å splitte informasjonen mellom applikasjonsaksesstjenerne, med eller uten overlappende informasjon. Slike løsninger krever spesiell programvare for å håndtere distribusjonen av passende data til hver appli-kasjonsaksesst jener .

Applikasjonsaksesstjeneren kommuniserer med applikasjonslobbytjeneren for å sette opp applikasjonen, legger til og fjerner deltakere når applikasjonen er i gang, og håndterer nettverksfeil og andre feil.

Figur 2 viser en applikasjonsaksesstjener 50 i henhold til en utførelse av oppfinnelsen med dens funksjonelle entite-ter. Applikasjonsaksesstjeneren kan være implementert i ma-skinvare eller programvare. I forbindelse med figur 2 er bare en generell beskrivelse gitt. Passende formater og protokoller vil bli diskutert senere.

Applikasjonsaksesstjeneren mottar data fra hver klient i nettet og fra andre enheter, slik som andre applikasjonsak-sesst jenere, gjennom inngangsbufferne 51. Det er én inngangsbuffer for hver klient, fjerntliggende applikasjonsaksesstjener og applikasjonslobbytjener, selv om bare én inn-gangsbuf fer er vist i figur 2. Handlingene til hver lokale deltaker sendes som nyttedata i applikasjonsobjektpakkene som ankommer inngangsbufferen til applikasjonsaksesstjeneren tilknyttet denne klienten. Disse applikasjonsobjektpakkene oppdaterer applikasjonsobjektene som styres av deltakeren. Applikasjonsobjektpakkene skrives inn i applika-sjons tilstandsdataposten ved å bruke et sett med innset-tingsregler.

Data mottatt fra klientene kan inneholde tre typer data: data om tilstanden til applikasjonen (tilstandsdata), data om klientens subskripsjoner (prioritetsdata) og annen sty-ringsinformasjon, slik som forespørsler for tidsreferanser, status for andre klienter og annen informasjon fra systemet. Tilstandsdatåene passerer gjennom et applikasjons-ob jektpakkerør 53 til en applikasjonstilstandliste 55. Applikasj onstilstandslisten 55 inneholder alle tilstandsdatae-ne for alle relevante objekter som vil bli beskrevet i nærmere detalj i det følgende. Applikasjonstilstandslisten inneholder også hastedata som beskrevet ovenfor. Grupper av klienter kan være definert, nevnte gruppe består for eksempel av deltakerne i en arbeidsgruppe eller, i spilltilfel-let, på samme lag. I dette tilfellet kan subskripsjoner og/eller hastedata også være spesifisert for brukergrupper, og ikke bare for individuelle brukere.

Styredata, spesielt data som ikke trenger å bli behandlet i sann tid, slik som informasjon om tillagte eller fjernede applikasjonsobjekter, videresendes fra inngangsbufferen 51 til applikasjonsaksesstjenerkontrollenheten 57. I en maskinvareimplementasjon kan styreenheten 57 være en mikro-prosessor. Styredataene som behandles av styreenheten kan for eksempel være relatert til opprettelse og destruksjon av spillere og objekter, og til spill og objektgrupper.

Subskripsjonene passerer gjennom en protokollmeldingspassa-sje for applikasjonsprioritetskontroll 59 til en klientprioritetsliste (CPL - Client Priority List) 61 som inneholder subskripsjonene til hver klient som støttes av applika-sjons tjeneren. Subskripsjonene kan være oppdatert av klientene og av applikasjonsaksesstjenerstyreenheten. Styreenheten kan for eksempel bestemme at subskripsjonene til en klient skal oppdateres som respons på en hastemelding mottatt fra en annen klient.

Flere forskjellige prioriteringsstrategier kan benyttes av applikasjonsklientene ved å bruke applikasjonsaksesstjenersystemet. En enkel fremgangsmåte er at applikasjonsklientene kjenner en nummerert liste over objekter til CPL 61. I dette tilfellet kan objekter som ikke befinner seg på listen oppdateres, for eksempel i en "round-robin"-modus når alle objektene på listen har blitt oppdatert. Hvis alle objektene i listen har blitt oppdatert kan de gjenværende objekter oppdateres, for eksempel i en "round-robin"-modus. Subskripsjonene til en bestemt klient består av en liste over alle objekter for hvilke en subskripsjon har blitt satt av denne klienten. I tillegg inneholder listen lagret i applikasjonsaksesstjeneren fortrinnsvis et flagg for hvert objekt som indikerer om ny informasjon for objektet er mottatt. Flagget benyttes for å bestemme om informasjon om et bestemt objekt må sendes til klienten eller ikke. Når informasjon har blitt sendt til klienten resettes flagget. Når en ny oppdatering for et objekt mottas av applikasjons-aksesst jeneren settes flagget igjen.

Klientsubskripsjonene kan også bli definert med et tidsintervall tilknyttet hvert objekt. Klienten kan da sende en serie med forespørsler, for eksempel på dette formatet: <object number>, <object priority>, «cobject update time in-terval>, <flags>. En enklere liste kan ganske enkelt ha formatet <object number>, <object priority>. Applikasjons-aksesst jeneren vil forsøke å sende oppdateringer til klienten slik at hvert objekt oppdateres i det minste én gang i løpet av hvert tidsintervall med prioriteten gitt i henhold til <object priority>-feltet i forespørselen. Et uendelig-symbol kan benyttes slik at noen objekter ikke oppdateres i det hele tatt. Et spesielt "send bare nye fullstendige objekt tilstander" -flagg kan settes. Denne muligheten brukes når klienten ønsker å motta oppdateringer for objektet med lange intervaller (flere sekunder). Det vil være bortkastet å sende stadige oppdateringer hvis den ønskede tidsoppløs-ningen er større enn tilstandsoppfriskningsintervallet.

Et utgangsrør 63 mottar subskripsjonsinformasjon fra klientprioritetslisten 61 og bruker denne informasjonen til å søke gjennom applikasjonstilstandslisten 55 for informasjon som skal transmitteres til den aktuelle klient, ved å bruke en passende algoritme som diskutert ovenfor. Den valgte tilstandsinformasjon passerer fra applikasjonstilstandslisten 55 igjennom utgangsrøret 63 til en utgangsbuffer 65 og fra utgangsbufferen til klienten. Styreenheten 57 sender styremeldinger til klientene og de fjerntliggende tjenerne, for eksempel for å synkronisere klokkene eller å skaffe tilveie forsinkelsesestimater til klienten.

Selv om applikasjonsaksesstjeneren vist i figur 2 bare har en av hver enhetstype, inneholder applikasjonsaksesstjeneren fortrinnsvis en inngangsbuffer 51, et applikasjons-objektpakkeinngangsrør 53, et prioritetsmeldingsrør 55, og et utgangsprosesseringsrør 63 og en utgangsbuffer 65 for hver klient og for hver av de andre tjenerne, etc. i nettet med hvilke applikasjonsaksesstjeneren utveksler informasjon. Alternativt kan en gruppe klienter eller tjenere dele en inngangsbuffer 51, et applikasjonsobjektpakkeinngangsrør 53, et prioritetsmeldingsrør 55, og et utgangsprosesse-ringsrør 63 og en utgangsbuffer 65. Applikasjonsaksesstjeneren består også av en klientprioritetsliste 61 for hver klient, tjener, etc.

Dataene mottatt fra andre applikasjonsaksesstjenere består av objekttilstandsdata fra andre klienter. Den kan også bestå av prioritetsinformasjon fra disse klienter, som fortrinnsvis er samlet på en slik måte at hvert objekt opptrer på prioritetslisten kun én gang. I dette tilfellet vil informasjonen være pakket slik at det er en prioritetsliste for hver applikasjonsaksesstjener, det betyr at hver appli-kasjonsaksesst jener behandles som en klient. Informasjonen mottatt fra en annen applikasjonsaksesstjener behandles på samme måte som informasjonen mottatt fra en klient, bort-sett fra at inngangs- og utgangsbufferne 51, 65 også må gjennomføre en bestemt protokollhåndtering som vil bli diskutert nedenfor. Alternativt vil ingen subskripsjonsinfor-mas jon mottas fra andre applikasjonsaksesstjenere slik at all tilstandsinformasjon vil bli transmittert til disse applikasj onsaksesstjenerne.

Applikasjonsaksesstjeneren kan eventuelt også handtere "fair play"-moduser hvor alle spillerne oppdateres samtidig (se nedenfor).

Som nevnt ovenfor, kan én eller flere applikasjonslobbytjenere (21 i figur 1) av en type som er kjent på fagområdet, presenteres i nettet. Applikasjonslobbytjenere er ansvarlig for å oppdatere konfigurasjonsdatåene i løpet av spillet, og skaffe applikasjonsaksesstjeneren data slik som: • IP-adresser eller andre nettverksadresser til nye app-likasjonsaksesst jenerenheter som tar del i spillet • Oppdaterte lister av nettverksadresser som identifiserer deltakere som betjenes av applikasjonsaksesstjeneren. Dette gjør det mulig at nye deltakere kan ta del i en pågående applikasjon. • Oppdaterte lister over nummererte spillobjekter. For hvert objekt spesifiseres det hvilken applikasjonsak-sesst jener som er ansvarlig for å lagre tilstanden hvis tilstanden distribueres mellom applikasjonsak-sesst jenerne . Det kan også spesifiseres hvem som er autorisert til å oppdatere tilstanden. Dette gjør det mulig med opprettelse, destruksjon og endring av sty-ringen av spillobjektene. Klientene kan også opprette og ødelegge spillobjekter. • En ny fullstendig eller delvis spilltilstand. Dette gjør det mulig med gjenopprettelse etter en pause eller en feil i spillet når applikasjonsaksesstjenersystemet har mistet spilltilstanden. Figur 3 viBer et eksempel på en applikasjonstilstandsliste som benyttes i applikasjonsaksesstjeneren i henhold til oppfinnelsen: Tilstanden til hvert applikasjonsobjekt er lagret i applikasj onstilstandslisten som et sett med nummererte applikasj onsobjekttilstander A0S1-A0S4. Hver applikasjonsobjekttilstand består av serier med applikasjonsobjektpakker, henholdsvis A0P11-A0P13, AOP21-AOP24, A0P31 og AOP41-AOP42. En objektpakke er en beholder for objektdata. Alle data som sendes fra en applikasjon til en fjerntliggende klient eller tjener, pakkes inn i en applikasjonsobjektpakke slik at den kan behandles av applikasjonsaksesstjenersystemet.

Informasjonen som mottas av en applikasjonsaksesstjener fra alle andre applikasjonsaksesstjenere til hvilke den er koblet, benyttes for å oppdatere applikasjonsobjektinformasjo-nen i applikasjonstilstandslisten. Det er fortrinnsvis to typer applikasjonsobjektpakker: 1) en referanseapplikasjonsobjektpakke som består av alle aktuelle data om ett objekt, og 2) en flerpakke som bare består av informasjon om hva som har endret seg siden tidspunktet som er gitt av tidsstempelet til APO-en som tilleggspakken refererer til. Den første AOP i en AOS må være en referansepakke som kan etterfølges av et sett med tilleggspakker, eller av en referansepakke. Noen spill vil bare generere referansepakker.

Applikasjonstilstandslisten inneholder også en liste over applikasjonsobjektpakker som må leveres til andre applika-sjonsaksesst jenerenheter. Dette kan gjøres ved å bruke en datastruktur new_client_data som kan implementeres som en matrise new_client_data (i,k) hvor hvert element er et flagg. Parameteren i er et klientnummer og parameteren k er et applikasjonsaksesstjenernummer. Flagget settes hvis applikasj onsob jektpakken skal leveres til den eksterne applikasj onsaksesstj eneren.

Som et eksempel på hvordan applikasjonsobjekttilstander kan brukes for å beskrive applikasjonsobjekter, viser figur 3 en applikasjonsobjekttilstand A0S1. Dette objektet kan beskrive posisjonen til et kjøretøy i et bilspill. Posisjonen til kjøretøyet (xl, yl) sendes først som spillnyttelast i en referanseapplikasjonsobjektpakke A0P11 ved spilltidspunkt ti. For å spare båndbredde transporteres den relative endring i posisjonen (Ax2, Ay2) ved spilltidspunkt t2 som en tilleggsapplikasjonsobjektpakke A0P12. Tilleggsapplika-sjonsobjektpakken AOP12 peker til referanseapplikasjonsobjektpakken A0P11 som en referanse. Ved spilltidspunkt t3 sendes en ny tilleggsposisjon (Ax3, Ay3) i en tredje applikasj onsob jektpakke AOP13. Den tredje applikasjonsobjektpakke AOP13 har den andre applikasjonsobjektpakke A0P12 som referanse. Etter å ha mottatt alle tre applikasjonsobjektpakkene A0P11, A0P12, A0P13, kan klienten beregne posisjonen til kjøretøyet ved tidspunkt t3 i henhold til (xl+Ax2+Ax3, yl+Ay2+Ay3).

Når en ny referanseapplikasjonsobjektpakke mottas for et bestemt objekt kan applikasjonstilstandslisten slette alle tidligere pakker som hører til objektet, og kun lagre den nye referansepakken. Legg merke til at syntaksen og seman-tikken til spillnyttelasten bare kan forstås av spillapplikasjonen som er i gang på klientterminalen. Applikasjonen skal sende referansepakker ofte for å unngå lange avbrudd forårsaket av tapte data.

En alternativ måte å kode applikasjonen på vil være å la den tredje applikasjonsobjektpakken AOP13 ved tidspunkt t3 bruke referanseapplikasjonsobjektpakken A0P11 som referanse, og bare fastsette endringen av posisjonen, 5x,5y relativt til (xl, yl). Dette vil spare applikasjonsaksesstje-nerminnet siden den andre applikasjonsobjektpakken AOP12 ved tidspunktet t2 kan være slettet idet den tredje applikasj onsob jektpakken A0P13 ankommer. Klienten vil nå beregne posisjonen for kjøretøyet ved tidspunkt t3 i henhold til (xl+5x3, yl+8y3). Applikasjonsaksesstjeneren bruker informasjonen i applikasjonsobjektpakkehodet for å bestemme om en tidligere applikasjonsobjektpakke er utgått og kan slettes. I figur 3 består AOS 2 av fire applikasjonsobjektpakker AOP21, AOP22, AOP23 og AOP24, hvor den første, A0P21, er en referansepakke og de tre påfølgende applikasjonsobjektpakker AI022, AOP23, og AOP24 er tilleggspakker. Den siste tilleggspakken har tidsstempel t8. AOS 2 beskriver derfor tilstanden til objekt 2 frem til spilletidspunkt t8. AOS 3 i figur 3 består bare av én referanseapplikasjonsobjektpakke A0P31 som er tilstrekkelig for å beskrive objektet.

Før det tillates at en ny klient tilsluttes til applikasjonen kan applikasjonsaksesstjeneren i henhold til en foretrukket utførelse, estimere det økte båndbreddebehovet og sikre at denne båndbredden er tilgjengelig i nettet. Fremgangsmåter for å gjøre dette er velkjent innen fagområdet. Hvis ingen kapasitetsproblemer forutses, vil dette trinnet ikke være nødvendig.

Figur 4 viser en utførelse av en datamaskin på hvilken en klient i henhold til oppfinnelsen kjører. Datamaskinen består av en prosesseringsenhet 101 der programmer kjøres, for eksempel et applikasjonsprogram 103 i henhold til oppfinnelsen. Prosesseringsenheten kommuniserer også med en applikasjonsaksesstjener (ikke vist) og eventuelt andre enheter i nettverket ved hjelp av kommunikasjonsprogramvaren 105. Applikasjonsprogrammet 103 kommuniserer med kommunikasjonsprogramvaren 105 gjennom et nettapplikasjonsgrense-snitt 107. Nettapplikasjonsgrensesnittet har funksjoner for å sende og motta applikasjonsdata fra applikasjonsprogrammet .

Datamaskinen består også av en skjerm 109 for å vise data om applikasjonen, for eksempel en oversikt av delen av spillet som er av umiddelbar interesse for deltakeren. For å legge inn data i applikasjonen, kan datamaskinen for eksempel ha et tastatur 111, en mus 113 og/eller en joystick 115 koblet til seg, ved hjelp av hvilken et objekt i spillet kan flyttes på, eller andre typer endringer kan entres.

Klientapplikasjonen 103 mottar nevnte inngangsdata, prosesserer det og viser resultatet av det på skjermen 109, og/eller ved hjelp av for eksempel høyttalere og/eller hap-tiske visningsmidler. Den sender også applikasjonstil-standsdata basert på nevnte inngangsdata til nettapplikasjonsgrensesnittet 107, fra hvilket den videresendes til applikasjonsaksesstjeneren.

Gjennom kommunikasjonsprogramvaren 105 og nettapplikasjonsgrensesnittet 107 mottar applikasjonene 103 også applikasj onstilstandsinf ormas jon vedrørende andre objekter fra spillakstjeneren prosesserer det og viser resultatet på skjermen 105.

I denne utførelsen består nettapplikasjonsgrensesnittet 107 av to deler: et applikasjonsprogrammeringsgrensesnitt 107A og et applikasjonsaksessgrensesnitt (AAI) 107B. Løsningen ble valgt for å gjøre det mulig med bruk av en standard programmodul, slik som Microsoft DirectPlay, for å implementere nettet AAI 107B som diskutert nedenfor.

Applikasjonsaksessgrensesnittet (AAI) 107B er en programva-remodul i klientterminalen. Det er en mellomliggende modul gjennom nettverksgrensesnittet og nettet API 107A. Applikasj onsaksessgrensesnittet 107B mottar og terminerer applikasj onsob jektpakkene og styremeldingene, og fjerner applikasj onsob jektpakkehodene før applikasjonsobjektpakkenyttelas-ten blir sendt til nettapplikasjonsgrensesnittet 107. Den oversetter også styremeldingene og sender dem til API 107A eller behandler dem direkte. AAI 107B håndterer funksjoner som kreves for av kommunikasjon med applikasjonsaksesstjeneren skal fungere, men dette er ikke implementert i kli-entapplikasjonsprogrammet. Derfor er det ikke sikkert det er nødvendig for klienter som har blitt utviklet for bruk med en applikasjonsaksesstjener i henhold til oppfinnelsen. For eksempel kan AAI håndtere klokken som plasserer tids-stemplene på applikasjonsobjektpakkene hvis klienten ikke har funksjoner for dette.

I oppstrømsretningen mottar AAI 107B meldinger og objekter fra AAI 107B meldinger og objekter fra API 107B. Data ved-rørende applikasjonsobjektene fra klienten transformeres til applikasjonsobjektpakkeformatet. Applikasjonsobjektpakkene transmitteres over kommunikasjonslinken til applikasj onsaksesstjeneren.

AAI 107B genererer også oppstrømsapplikasjonskontrollproto-kollmeldinger, nærmere bestemt protokollsubskripsjonsmel-dinger for applikasjonskontroll. Informasjonen som er nød-vendig for å sette opp subskripsjoner og andre applikasj onskontrollprotokollmeldinger må trekkes ut fra applikasjonen via nett-API-en, og fra hastelistemeldingene (urgen-cy list messages) i applikasjonsaksesstjeneren.

En fysisk klient, for eksempel en spillekonsoll, kan være engasjert i flere spill eller huse flere spillere i samme spill. Hver fysiske applikasjonsklient kan kjøre flere logiske applikasjonsklienter hvor en logisk applikasjonsklient korresponderer med et tilfelle av en applikasjon koblet til et tilfelle av applikasjonsaksessgrensesnitt. Applikasj onsklient ene i dette dokument tilsvarer en logisk applikasj onsklient. En nettverksadresse som peker til en logisk applikasjonsklient, kan bestå av IP-adressen til den fysiske klient kombinert med portnummeret til applikasjonsaksessgrensesnittet .

Den beste utførelsen oppnås hvis applikasjonsaksesstjener-systernet tas i betraktning når applikasjonsprogrammet ut-vikles. Funksjoner for å bestemme subskripsjoner som indikerer den foretrukne rekkefølge av mottatt data, kan inklu-deres i applikasjonsprogrammet. Meldingene kan dirigeres direkte til en medspiller med høy viktighet hvis det er åpenbart ut fra situasjonen i spillet at den mottagende spiller ikke kan forutse den høye prioriteten til meldingen. Ta for eksempel i betraktning en situasjon i et spill hvor spiller 1 lister seg inn på spiller 2. Spiller 2 blir plutselig angrepet av spiller 1 uten å ha fått noen advar-sel. Spiller 2 er ikke i stand til å sette den korrekte prioriteten for meldinger fra spiller 1, men spiller 1 kan sende en høy viktighetsmelding til spiller 2.

For å utvikle nett-API-en, kan for eksempel Microsoft DirectPlay API benyttes. AAI-en er da nødvendig for å forma-tere utgangsdataene slik som ACP og APO, og kan skrives som en DirectPlay tjenestetilbyder. Ved å benytte Microsoft DirectPlay API er det minimum to forskjellige måter å trekke ut subskripsjoner på. Legg merke til at subskripsjonen skal vise prioriteten til den lokale deltaker for å motta oppdateringer om nummererte applikasjonsobjekter. Applikasjons-ob jektene i dette dokumentet er de samme som "spillere" i DirectPlay-notasjonen siden DirectPlay-"spillere" er applikasj onsentiteter som kan sende og motta meldinger. En DirectPlay- "spiller" kan styres av en person eller den kan være et autonomt spilleobjekt.

I den første fremgangsmåten benyttes informasjon fra Di-rectPlays mottaksmetode. Ved å sette DPRECEIVE_FROMPLAYER-flagget og spesifisere lpidFrom parameteren riktig, kan fremgangsmåten skaffe den første meldingen fra "spilleren" som identifiseres av lpidFrom parameteren. Denne informasjonen kan benyttes av applikasjonsaksessgrensesnittet for å lage subskripsjonen. Hvis ingen melding fra den identifiserte "spiller" var tilgjengelig i DirectPlay-meldingskøen, vil det være rimelig å legge det identifiserte applikasj onsob jekt på toppen av prioritetslisten.

I den andre fremgangsmåten benyttes DirectPlay Send-metoden, i hvilken idTo parameteren identifiserer "spilleren" eller spillergruppen som skal motta meldingene. Det er rimelig å anta at "spillerne" som mottar meldinger ofte er tilknyttet applikasjonsobjekter der den lokale spiller for tiden samvirker. AAI-en kan derfor slutte seg til "spillere" identifisert av idTo-parameteren.

Figur 5 viser et eksempel på kommunikasjonsstakkene som kan benyttes i henhold til oppfinnelsen. En kommunikasjonsstakk benyttes for kommunikasjonen mellom en klient slik som den som er vist i figur 4, og en applikasjonsaksesstjener. Klienten og applikasjonsaksesstjeneren består i all hovedsak

av den samme stakktypen. I klienten kommuniserer det øverste laget i stakken med et applikasjonsaksessgrensesnittlag 10 i figur 4, og i applikasjonsaksesstjeneren kommuniserer stakken med en applikasjonsaksesstjenerprogramvare som også er vist. Figur 5 viser også en kommunikasjonsstakk til bruk mellom en applikasjonsaksesstjener og en annen enhet i nettet. Denne andre enhet kan for eksempel være en annen applikasj onsaksesst jener, eller en applikasjonslobbytjener. Kommunikasjonsstakkene som benyttes er tilpasset OSI-modellene.

Klientkommunikasjonsstakken kommuniserer med applikasjons-programmeringsgrensesnittet 107 i klienten. Det øverste nivået i stakken er ACP/AOP-laget 109. Dette nivået håndteres av applikasjonsaksessgrensesnittet 107 i figur 4.

Fra ACP/AOP-laget 109 leveres ACP/AOP-pakker som inneholder informasjon slik som applikasjonsobjektdata eller subskrip-sjonsinf ormas jon til et linklag 111. Linkprotokollen kan for eksempel være PPP. I den motsatte retning fjerner ACP/AOP-laget 109 hodeinformasjonen fra informasjonspakkene mottatt fra applikasjonsaksesstjeneren og videresender applikasj onstilstandsinformasjonen til klientapplikasjonen. ACP-pakkene kan termineres i AAI. Subskripsjonen i seg selv kan håndteres av selve klienten, hvis den innehar funksjoner for å håndtere subskripsjonen.

Det laveste laget er et kanallag 113 som består av kanalko-ding og den aktuelle fysiske forbindelse.

Applikasjonsaksesstjeneren består i hovedsak av samme type stakk for kommunikasjon med klienten: et kanallag 113' korresponderer med kanallaget til klienten. Kanallaget 113' er koblet til AOP/ACP-lag 109' gjennom et linklag 111'.

Et AOP/ACO-lag 109' i applikasjonsaksesstjeneren kommuniserer direkte med en applikasjonsaksesstjenerprogramvare 115 som er tilpasset til å håndtere AOP- og ACP-informasjon.

Applikasjonsaksesstjeneren kan være bygget med grensesnitt til mange forskjellige klientlinkprotokoller. Ideelt sett skal en applikasjonsaksesstjener være i stand til å håndtere en hvilken som helst linkprotokoll, inkludert UDP, TCP og RTP. RTP er en protokoll utviklet spesielt for transmisjon av tale- og videodata.

Linkprotokollen bør være designet slik at protokollkostna-den på linken fra applikasjonsaksesstjeneren til klienten holdes lav. Dette kan for eksempel gjøres ved å benytte en passende linkprotokoll hvor IP/UDP/RTP ikke benyttes, eller mer effektiv IP/UDP/RTP-hodekompresjon. Linklaget bør videre minimalisere forsinkelsen og tilveiebringe informasjon til applikasjonsaksesstjeneren på linkens vilkår. Slik informasjon kan inneholde forventet båndbredde, bit-feilrate og linkforsinkelse.

En passende transportprotokoll, her kalt applikasjonstransportprotokollen, ATP bør brukes på linken, men applikasj onsobjektpakkene og applikasjonsstyrepakkemeldingene kan også sendes direkte via linkprotokollen.

For kommunikasjon mellom to og flere applikasjonsaksesstjenere, sendes en strøm av IP-pakker fra utgangsbufferen 65 til en lokal applikasjonsaksesstjener (se figur 2) til en eller flere fjerntliggende applikasjonsaksesstjenerenheter som tar del i den pågående applikasjon. Hver IP-pakke består av en TCP eller UDP-pakke og TCP eller UDP-nyttelasten i applikasjonstransportprotokollen (ATP) pakken.

Det øverste protokollag i kommunikasjonsstakken for kommunikasjon mellom to applikasjonsaksesstjenere er et AOP/ACP-lag 117 som er lik med det som benyttes i klientkommunikasjonsstakken. En applikasjonsobjektpakke kan være ganske liten, det vil si cirka 40 bytes eller mindre. For å gjøre kommunikasjonen mellom to applikasjonsaksesstjenere mer effektiv, samles derfor flere applikasjonsobjektpakker derfor i et applikasjonstransportprotokoll- (ATP) lag 119. Det neste laget er et TCP eller UDP-lag 121, og det laveste lag er et IP-lag 123, hvor begge 121, 123 er velkjent i fagområdet. Fra iP-laget transmitteres informasjonspakker til fjerntliggende applikasjonsaksesstjenerenheter. Utgangsbuf-ferenheten 165 i (figur 2) inneholder et sett med sorte-ringsbuffere for å samle applikasjonsobjektpakker som vil være ATP-nyttelast. Strukturen til disse bufferne er avhengig av distribusjonsstrategien. Det kan være en sorteringsbuffer for hver fjerntliggende applikasjonsaksesstjener .

En applikasjonsobjektpakke kan inneholde et felt som lister klientene som skal få oppdatering. Feltet oversettes til en liste over applikasjonsaksesstjenerenheter som skal motta applikasjonsobjektpakken. Applikasjonsaksesstjeneren inneholder en tabell som knytter klientnummeret til applika-sjonsaksesst jenernummeret. Dette betyr at alle relevante applikasjonsaksesstjenerenheter eventuelt vil få oppdatering. Applikasjonsaksesstjenerenhetene vil så sende applikasj onsob jektpakkene til deres lokale klienter. En enkel alternativ operasjonsmodus er at alle applikasjonsaksesstjenerenhetene mottar all applikasjonsdata.

Den lokale applikasjonsaksesstjener identifiserer applikasj onsob jektpakkene som må sendes til de fjerntliggende klienter via de fjerntliggende applikasjonsaksesstjenerenhetene. Applikasjonstilstandsmottakeren til den lokale applikasj onsaksesst jener blir derfor skannet og applikasjonsobjektpakkene med new_client_dataflagg-settet er funnet. Et applikasjonspakkehode består av et mottakergruppefelt som lister opp en eller flere klientadresser til hvilke applikasj onsobjektpakkene skal sendes. Dette mottaksgruppefeltet undersøkes. Klientadressene oversettes til fjerntliggende applikasjonsaksesstjeneradresser og kopier av applikasjonsobjektpakken settes inn i sorteringsbufferne som korresponderer med mottaksapplikasjonsaksesstjenerenhetene. Mottaksgruppefeltet modifiseres for hver applikasjonsobjektpakke-kopi slik at bare mottaksklientene som hører til den mottagende applikasjonsaksesstjener eller gruppe med applika-sjonsaksesst j enere gjenstår. New_client_data-flagget resettes.

Applikasjonsobjektpakkene inneholder nyttelast fra spillapplikasjonen. Applikasjonsaksesstjenersystemet kan ikke lese det interne nyttelastformatet til spillene. Slike meldinger blir derfor pakket i en applikasjonsobjektpakke (AOP). Hodet til en AOP kan leses av applikasjonsaksesstjenersystemet. Den benyttes for å vedhefte informasjon som er nødvendig for den betimelige leveransen av spi Unytt elas - ten.

I utførelsen som diskuteres her, benyttes tre ikke-standardiserte protokoller i tillegg til standard Inter-nettprotokoller slik som IP, TCP, UDP og RTP: • Applikasjonsobjektpakke (AOP) er en beholder for spilldata. All data som sendes fra en spillapplikasjon til en fjerntliggende spi11ekiient eller tjener, pakkes inn i en AOP slik at den kan håndteres av applika-sjonsaksesst jener systemet . • Applikasjonskontrollprotokoll (ACP) benyttes for å sende kontroilmeldinger. Kontrollmeldinger sendes mellom applikasjonsaksesstjenerenhetene, klientene og applikasjonslobbytjenerne. • Applikasjonstransportprotokoll (ATP) benyttes for å sende oppsamlede spilldata mellom applikasjonsaksesstjenerenhetene og eventuelt også mellom applikasjons-aksesst jenerne og klientene.

Applikasjonsobjektpakkene inneholder meldinger fra spillapplikasjonen. Applikasjonsaksesstjenersystemet kan ikke lese det interne meldingsformatet til spillene. Slike meldinger pakkes derfor inn i en applikasjonsobjektpakke (AOP). Hodet til en AOP kan leses av applikasjonsaksesstjenersystemet. Det benyttes for å legge ved informasjon som er nødvendig for den betimelige leveranse av spillnyttelasten.

Applikasjonsmeldinger kan i sin helhet definere tilstanden til et applikasjonsobjekt eller de kan alternativt beskrive applikasjonsobjektet relativt til en referansestatus. AOP-ene er derfor av to typer: Referansepakker (BP) og tilleggspakke (IP - Incremental Packet).

En applikasjonsobjektpakke består av et hode fulgt av spillspesifikk nyttelast: hodefelt som kan benyttes i AOP-en innbefatter:

1) applikasjonsobjektnummer,

2) tidsstempel som viser spillets tidspunkt når AOP-en ble generert, 3) valgbart pakkenummer. Kombinert med objektnummer og tidsstempel utgjør det en unik identifikator for pakken. Pakkenumrene benyttes bare hvis flere AOP-er som hører til samme spillobjekt har samme tidsstempel, 4) hvis for eksempel tale- og videoinformasjon kan transmitteres, kan et flagg som viser om pakken inneholder denne type informasjon være inkludert. 5) et flagg som viser om AOP-en er en referansepakke eller en tilleggspakke, 6) hvis AOP-en er en tilleggspakke, en peker til referanse-AOP-en. Denne pekeren kan bestå av tidsstempelet og pakkenummeret til referanse-AOP-en. Referanse-AOP-en kan være enten en basis-AOP eller en tilleggs-AOP. 7) en liste som beskriver klientene som skal motta meldingene. Dette kan gjøres ved å liste opp klientene eller bruke en forhåndsdefinert klientgruppe. Det nor-male er at alle klienter mottar dataene. Et hastefelt er tilknyttet hver mottagende klient eller klientgruppe. Dette feltet benyttes for å varsle mottakeren om meldingen er viktig. Tre hastebit vil være tilstrekkelig.

Flagg som kan være satt i hastefeltet er:

Forbudt: AOP-en skal ikke distribueres til klienten

eller klientgruppen

Fair_Play: benytt "fair play"-modus (se nedenfor) Very_Urgent: overskriver klientprioriteter

Urgent: klient vil bli varslet

Normal: levert i henhold til klientprioritetene Not_Urgent: levert på best mulig måte

Et enkelt format kan være:

<number of entries> <client lxurgency for client lxclient 2><urgency for client 2>„„.

Senere enheter i listen overskriver tidligere enheter. Feltet:

2, all Forbidden, client_3 Urgent

kan for eksempel bety at alle klienter forbys å motta AOP-en med unntak av klient nummer 3 som vil få AOP-en i hastemodus. 8) Nyttelastens størrelse.

Applikasjonskontrollprotokollen (ACP) benyttes for å sende kontroilmeldinger mellom spillklienter, applikasjonsaksesstjenerenheter og applikasjonslobbytjeneren (ALS). En oversikt over ACP er gitt her. Hver ACP-pakke består av et hode og en meldingskropp.

En ACP-melding kan inneholde de følgende felt:

1) ACP-meldingstype

2) Tidsstempel som viser tidspunktet i spillet når meldingen ble generert

3) Meldingens størrelse

4) Meldingskropp

Legg merke til at kilden til meldingen identifiseres av høyere protokollnivåer. I det følgende vil meldingene som kan transmitteres ved å benytte ACP skisseres. ACP-meldingene fra klient til applikasjonsaksesstjeneren kan innbefatte det følgende: • Terminer klient. Applikasjonsaksesstjeneradministra-sjonssystemet fjerner klienten fra alle lister og varsler applikasjonslobbytjeneren (ALS). Klienten er ansvarlig for å varsle ALS-en hvis den forlater spillet. ALS-en er ansvarlig for å avslutte kontakten med den terminerte klient for eksempel ved å sende slutt-poengene og varsle andre spillere.

• Subskripsj oner.

• Legg til spillobjekt. Et nytt spillobjektnummer genereres av applikasjonsaksesstjeneren, og et applika-sjonsaksesst jenerminne tildeles for å motta objekttil-standsinformasjon fra klienten • Fjern spillobjekt. Objektet fjernes fra applikasjons-aksesst j enerminnet etter at alle klienter og fjerntliggende applikasjonsaksesstjenerenheter som er listet opp for å motta oppdateringer, har mottatt den siste oppdatering. • Send estimerte forsinkelser for objekter. Forespørse-len inkluderer en liste over objektnummeret. Applikasjonsaksesstjeneren responderer ved å sende de estimerte ende-til-ende-forsinkelsene for objektene. Klientapplikasjonen bruker estimatene for å skjule forsinkelser. • Definer objektgruppe. Objektgruppene er nyttig for å gi korte navn på lange lister av objektnumre som ellers ville ha blitt sendt til klientlinken. DirectPlay håndterer hierarkiske "spille"-grupper slik at spill-API-en vil være i stand til å tilveiebringe gode gruppedefinisjoner. Applikasjonsaksesstjeneren lager objektgruppeinformasjon og behandler en objektgruppe

som et alias for en objektliste. Meldingen kan ha føl-gende format: message type = define object group;> «cobject group namexlist of objects> • Definer klientgruppe. Klientgruppene er nyttige for å sette korte navn på lange lister med klientnumre som ellers ville blitt sendt over klientlinken i AOP-feltet. Applikasjonsaksesstjeneren lager klientgruppe-informasjon og behandler en klientgruppe som et alias for en klientliste. Meldingen kan ha følgende format: message type = define client group <client group namexlist of clients> • Send tidsreferanse. Denne meldingen benyttes for å laste ned referansetidspunkt fra applikasjonsaksesstjeneren.

ACP-meldingene fra applikasjonsaksesstjeneren til klienten inkluderer det følgende: • Hasteliste. Denne meldingen benyttes for å varsle klienten hvis viktige uleste AOP-er venter. Applikasjons-aksesst jeneren skanner alle uleste AOP-er som har den aktuelle klient på AOP-ens mottaksliste. Hastelisten kan ha følgende format: <urgency class lxlist of object numbersxurgency class 2><list of object numbers> og så videre. • Forsinkelsesestimat. Denne består av et sett med enheter i henhold til: <game object numberxupstream latencyxupstream latency variancexdownstream latencyxdownstream latency variance>

Et "vet ikke"-symbol kan brukes for et hvilket som helst felt unntagen det første.

• Bekreft objektgruppenummer. Applikasjonsaksesstjeneren har mottatt en "definer objekt gruppe"-melding fra en klient. Den bekrefter at et globalt objektgruppenummer har blitt tildelt. Neldingskroppen vil innbefatte: <global object group numberxclient's object group name>

En enkel fremgangsmåte for å tildele objektnumre vil være: anta at totalt N applikasjonsaksesstjenerenheter er aktive. Nummerer alle aktive applikasjonsaksesstjenerenheter. Hvis applikasjonsaksesstjenernummer k fo-respørres et nytt objektnummer tildeler den det laveste ledige objektnummer fra serien {k, N+k, 2N+k,

3N+k,...}

• Bekreft klientgruppenummer. Applikasjonsaksesstjeneren har mottatt en "definer klientgruppemelding" fra en klient. Den bekrefter at et globalt klientgruppenummer har blitt tildelt. Meldingskroppen vil innbefatte: <global client group numberxclients client group name>

Den samme algoritmen som benyttes for å tildele globale objektgruppenavn kan benyttes for å tildele klient-gruppenavn. • Klokkesynkronisering. Applikasjonsaksesstjeneren sender en tidsdifferanse i henhold til: <client time>=<time>+<client link latency>

Klienten har en algoritme for å tilpasse den lokale klokken i henhold til en serie med mottatte klokkesyn-kroniseringsmeldinger.

ACP-meldinger fra en applikasjonsaksesstjener til en annen innbefatter: Oppsamlede subskripsjoner. Oppsamlede prioritetslister som viser objektene som klientene hører til og avsen-derapplikasjonsaksesstjeneren må se, det vil si objektene for hvilke informasjon skal sendes til avsender-applikasjonsaksesstjeneren. Listen har samme format som en enkel klientprioriteringsliste. Den er bygd opp ved å legge til alle gyldige lokale klientprioritets-lister og ved å fjerne duplikater. • Send forespørsel på nytt. Denne meldingen har samme format som en enkel prioritetsliste og tolkes som en forespørsel for å sende tilstanden til de opplistede objekter på nytt. • Definer objektgruppe. Objektgruppedefinisjoner kan distribueres mellom applikasjonsaksesstjenere. Ved å bruke globale navn for lange lister med objektnumre hjelper dette i å redusere trafikken. • Definer klientgruppe. Klientgruppedefinisjoner kan distribueres mellom applikasjonsaksesstjenere.

ACP-meldingene fra en applikasjonsaksesstjener til en applikasj onslobbytj ener innbefatter: • Klient har blitt terminert. Denne meldingen sendes når en klient frivillig har blitt frakoblet spillet. • Klientpause. Applikasjonsaksesstjeneren kan sende en melding til ALS-en hvis en klient har vært stille i lang tid eller hvis linken til klienten er lukket. ALS-en avgjør de videre handlinger slik som å fjerne klienten fra spillet.

En ALS kan fungere som en klient. ALS-en kan for eksempel kontrollere spillobjekter som inneholder poengene i spillet. En port i ALS-en er så koblet til AAS-en som en klient som bruker en "link"-protokoll slik som TCP/IP. ALS-en kan derfor bruke de samme meldingene som en klient. Andre ALS til AAS-meldinger er listet opp her:

Applikasjonsoppsettinformasjon, inkludert

• Nettverksadresse inkludert portnummer som identifiserer ALS-en.

• En URL som unikt identifiserer spillet.

• IP-adresser for andre applikasjonsaksesstjenerenheter som tar del i spillet. • En liste over nettverksadresser inkludert applikasj onsportnummeret som identifiserer klientene. • Alternativt en liste over nummererte spillobjekter. For hvert objekt er det spesifisert hvilken applika-sjonsaksesst jener som er ansvarlig for å lagre tilstanden. Det kan også være spesifisert hvem som er autorisert til å oppdatere tilstanden. • Eventuelt en initiell spilltilstand som skal lagres. • Valgfri data som spesifiserer kontrollstrategier slik som pauser. • Ti11egging av applikasjonsaksesstjener. Nettverksadresse, nummer og klientliste til den nye applikasjons-aksesst jeneren spesifiseres. • Fjerning av applikasjonsaksesstjener. Nummeret til applikasjonsaksesstjeneren som skal fjernes spesifiseres. • Ti11egging av klient. Dette innbefatter nettverksadressen til den nye klienten, eventuelt den initielle tilstand til de nye spillobjektene som kontrolleres av den nye klienten. • Fjerning av klient. Applikasjonsaksesstjenersystemet fjerner klienten fra spillet. Modifisering av klientstatus. Denne melding endrer klientenes autoritet for å kontrollere spillobjekter eller tilknytter klienten til en annen applikasjonsak-sesst jener. Formatet kan være: «sclient numberxapplication access tjener num-berxobject numbers>

hvor objektnumrene indikerer spillobjektene som kontrolleres av klienten.

Applikasjonstransportprotokollen (ATP) benyttes for å transportere applikasjonsobjektpakker (AOP) og applikasj onskontrollprotokoll (ACP) meldinger. ATP-en har en serie med AOP-er og ACP-meldinger i nyttelasten og benyttes ho-vedsakelig for å sende oppsamlede data mellom applikasjons-aksesst jenerenhetene. Applikasjonsaksesstjenerenhetene vil typisk kommunisere ved å bruke protokollstakken (IP/UDP/ATP). ATP er således på samme logiske nivå som RTP-protokollen.

ATP-hodet inneholder:

• en URL som identifiserer spillet,

• tidligste AOP- eller ACP-tidsstempel,

• seneste AOP- eller ACP-tidsstempel,

• antall AOP-er og ACP-meldinger.

ATP benyttes normalt bare for kommunikasjon mellom applika-sjonsaksesst j enere, som vist. Hvis båndbredden til forbin-delsen mellom en klient og en applikasjonstjener er tilstrekkelig høy, kan den også benyttes for disse forbindelser .

Konvensjonelle protokoller slik som TCP/IP og/eller UDP/IP, benyttes for kommunikasjon med applikasjonslobbytjeneren og andre applikasjonsaksesstjenerenheter. TCP/IP-en bør benyttes for å sette opp spillet og UDP/IP bør brukes for å sende sanntid spilldata av følgende grunner: TCP-gjensending og omstokking er for langsom og kompleks for spillapplikasjonen. TCP-omstokkingen kan forsinke leveransen av den siste oppdateringen og derved levere for gamle data. Gjensending av data som ikke lenger er nødvendig, er åpenbart bortkastet. Applikasjonsaksesstjenerenhetene kjenner til de eksakte prioriteter og kan forespørre gjensending fra flere kilder om nødvendig.

RTP kan benyttes for å sende tidsstempler, men RTP er laget for lyd- og videostrømmer og er ikke veldig godt egnet for spillstrømmer. RTP kan imidlertid benyttes for å bære tale-og videostrømmer som er tilknyttet spill.

En "fair play-modus" kan også implementeres i systemet. I denne modusen synkroniserer applikasjonsaksesstjenerenhetene leveransen av kritisk applikasjonsinformasjon slik at disse oppdateringer mottas av alle aktuelle klienter samtidig. Denne modus kan benyttes i konkurranser.

Applikasjonslobbytjeneren bestemmer, mens en applikasjon settes opp, om "fair play-modus" er tilgjengelig. Hvis "fair play-modusen" er tillatt, bestemmer den sendende klient for hver transmitterte AOP om "fair play"-leveranse skal benyttes. Dette gjøres for å sette Fair_Play-flagget i hastefeltet i AOP-en. Applikasjonsaksesstjenersystemet er nå ansvarlig for å levere AOP-en "samtidig" til alle klienter. Dette kravet overstyrer alle andre klientprioriteter.

En mulig teknisk løsning for dette er "bøttesynkronise-rings"-metoden (bucket synchronization). Applikasjonsak-sesst jenerenhetene enes om å oppdatere klientene med en fast absolutt forsinkelse. Oppdateringer som ankommer tidligere må vente i den forhåndsbestemte tidsluken. Denne metoden har ulempen med at den øker den generelle forsinkelsen i systemet. "Fair play"-modusen kan alternativt håndteres av spillapplikasjonen. I denne modusen benytter klientapplikasjonen den avtalte forsinkelse til å motta spilldata ved å benytte tidsstempelet til hvert spillobjekt for å beregne hvor mye pakken skal forsinkes for å oppnå den avtalte absolutte forsinkelse.

Figur 6 viser en annen utførelse av en applikasjonsaksesstjener 150 i henhold til oppfinnelsen. Der dette ikke pre-siseres er utførelsen lik med den som er diskutert ovenfor. I denne utførelsen er kommunikasjonsfunksjonene til applikasj onsaksesst jeneren delt mellom en eller flere applikasj onsrutere 152 og en applikasjonstjener 154. Applikasjonstjeneren 154 består av en applikasjonstilstandsliste 155 og en klientprioritetsliste 161 som beskrevet i forbindelse med figur 1. Applikasjonsruteren 152 kommuniserer med en

eller flere klienter 170 gjennom klientens applikasjonsprogrammeringsgrensesnitt API 172 som vil bli diskutert i nærmere detalj nedenfor. Hver applikasjonsaksesstjener 150 består av en applikasjonstjener 154 som betjener en eller

flere applikasjonsrutere 152. Applikasjonsruteren 152 kommuniserer også med andre noder i nettet, slik som applikasj onsrutere i andre applikasjonsaksesstjenere (ikke vist). Applikasjonstjeneren 154 og applikasjonsruteren 152 er fortrinnsvis implementert som separate maskinvareenheter for å optimalisere hver av dem i forhold til deres bestemte funksjoner. Alternativt kan de ha hver sine separate pro-sessorressurser. Nærmere bestemt må applikasjonsruteren kjøre uten avbrudd siden avbrudd vil påvirke sanntidsutfø-relsen til klientapplikasjonene negativt.

Som før er applikasjonsaksesstjeneren til hvilken en klient er koblet denne klientens lokale applikasjonsaksesstjener, og klienten er en lokal klient til den applikasjonsaksesstjeneren. På samme måte er applikasjonstjeneren og applikasj onsruteren som betjener klienten, klientens lokale applikasjonstjener og applikasjonsruter.

Applikasjonstjeneren mottar ATP-pakker som består av basisobjekter (se nedenfor) og kontrollmeldinger fra klientene gjennom applikasjonsruteren. Før et basisobjekt prosesseres for eksempel ved å legge den inn i applikasjonstilstandsda-tabasen, sjekker applikasjonstjeneren at den sendende klient har lov til å oppdatere objektet. Hvis klienten ikke er autorisert til å oppdatere objektet, avvises objektet og den sendende klient kan motta en feilmelding. Før en kontrollmelding prosesseres sjekker applikasjonstjeneren at den sendende klient har lov til å forespørre den indikerte operasjon, og hvis ikke, avvises kontroilmeldingen og en feilmelding sendes eventuelt tilbake til den sendende klient. Anta for eksempel et tilfelle når den sendende klient fore-spør at en objektgruppe skal slettes. Denne gruppen kan ha blitt opprettet av innholdstjeneren, som har en spesiell klient som er ansvarlig for å administrere spilltilstanden og å kommunisere med applikasjonsaksesstjeneren over en standard klient-API. Innholdstjeneren har lastet opp autorisasjonsregler til spillaksestjeneren som forbyr klienter å slette objektgrupper. I dette tilfellet vil applikasjonstjeneren avvise kontrollmeldingen som forespør slettingen av kontrollgruppene.

Denne autorisasjonssjekken gjennomføres ved å benytte ta-beller med autoriseringsregler som viser hva slags operasjoner som klienten har lov til å gjennomføre. Autorisa-sjonstabellene settes opp av klientene eller av kontrollen-hetene ved å benytte initialiseringsfiler.

En klient kan, hvis den er autorisert til det, forespørre opprettelsen av en objektgruppe. En klient kan også legge til medlemmer, fjerne medlemmer og slette objektgruppen. Medlemmer av objektgruppen er objekter og objektgrupper. En forespørsel for en av disse operasjonene for objektgrupper sendes av klienten som en kontroilmelding som kringkastes av applikasjonsruterne til alle applikasjonstjenerne som tar del i sesjonen. Objektgruppen identifiseres av en identifikator som har det samme format som en objektidentifikator. Hver applikasjonstjener inneholder en objektgruppeda-tabase 162 som for hver applikasjonssesjon lagrer objektgruppene som har blitt opprettet i løpet av sesjonen. Ob-jektgruppedatabasen 162 lagrer i det minste de følgende felt for hver objektgruppe: 1) objektgruppeidentifikatoren 2) en liste over medlemmene av objektgruppen 3) en liste over foreldrene til objektgruppen. En forelder til en objektgruppe A er en objektgruppe som har objektgruppe A som et medlem. Objektdatabasen er organisert som objektdatabasen i den foregående utførelsen, men for hvert objekt er det en liste over objektgrupper som er foreldre til objektet .

Objekter mottatt fra klienter og fra andre applikasjons-aksesst j enere som skal utgjøre en del av applikasjonstilstanden videresendes fra applikasjonsruteren 152 til applikasj onst jeneren 154, og lagres i applikasjonstilstandslisten 155. Subskripsjonsinformasjon mottatt fra klienter og andre applikasjonsaksesstjenere videresendes til applika-sjons tjenere 154 og lagres i klientprioritetslisten 161.

En administrator 174 kontrollerer funksjonen til en eller flere applikasjonsaksesstjenerne 150, og hver består av en eller flere applikasjonsrutere 152 og en applikasjonstjener 154, fortrinnsvis gjennom en forbindelse til applikasjonsruteren 152. Lokasjonsadministratoren kan også benytte standardprotokollen SNMP (Simple Network Management Proto-col) for å kontrollere lokasjonen.

En lokasjon består derfor av en lokasjonsadministrator og et antall applikasjonsaksesstjenere 150 kontrollert av lo-kas jonsadministratoren 174. Hovedoppgaven til lokasjonsadministratoren 174 er koblingsadministrasjon, klientforbin-delser, ressursadministrasjon, konfigurasjon av applikasj onst j enere og rutere, adgangskontroll, autentisering av klienter, tidssynkronisering for en lokasjon, nettadminist-rasjon og tilsyn av last og status for applikasjonstjenere og applikasjonsrutere.

Lokasjonsadministratoren mottar eventuelt applikasjonstransportprotokoll- (ATP) pakker som inneholder kontrollmeldinger fra klienter. Det bør legges merke til at ATP-en i denne utførelsen er forskjellig fra ATP-en beskrevet i forbindelse med den foregående utførelse og vil bli beskrevet nedenfor. Før en kontrollmelding prosesseres sjekker SM-en at den sendende klient har lov til å forespørre den indikerte operasjon, og hvis ikke avvises kontroiImeldingen og den sendende klient mottar eventuelt en feilmelding. Denne autorisasjonssjekken gjennomføres ved å benytte ta-beller med autorisasjonsregler som viser hva slags operasjoner klienten har lov til å gjennomføre. Autoriseringsta-bellene settes opp av klientene eller en lobbyaksestjener 178 ved å benytte initialiseringsfiler.

En eller flere lobbyaksestjenere 178 er tilveiebrakt for forbindelse til applikasjonslobbytjeneren 176, og en eller flere lobbyaksestjenere 178. Applikasjonslobbytjeneren er diskutert i forbindelse med figur 2. Lobbyaksestjeneren og tjeneren 178 er koblet til lokasjonsadministratoren 174. Lobbyaksestjeneren håndterer spillsesjonsforespørsler fra lobbytjenerne og arrangerer og administrerer spillsesjoner. Dette innbefatter registrering og autentisering av lobbytjenere, samt kontoføring. Den inneholder også informasjon om spill og lobbytjenere i en database. En sentral kontrollenhet (ikke vist) kan benyttes for å holde tilsyn med og vedlikeholde applikasjonskommunikasjonssysternet.

Et applikasjonskommunikasjonssystem består av en eller flere sammenkoblede lokasjoner og lobbyaksestjenere. En sentral kontrollenhet (ikke vist) kan benyttes for å holde tilsyn med og drifte applikasjonskommunikasjonssysternet.

Lobbyaksestjeneren 178 kan bestå av eller være koblet til en database 180 som inneholder informasjon om applikasjons-lobbyt jenerne som er til stede i nettet, slik som hvilke applikasjonslobbytjenere eller tjenere som har lov til å legge til klienter til et spesielt spill eller en spesielt applikasjonsaksesstjener. Applikasjonslobbytjeneren 176 kan inneholde, eller være koblet til, en database 182 som inneholder klientdata, så som autorisasjonsprofiler for hver klient.

Kommunikasjonen mellom lokasjonsadministratoren og applikasj onst jeneren eller tjenere denne kontrollerer inkluderer å legge til og fjerne sesjoner, og å legge til og fjerne klienter fra sesjoner. Kommunikasjonen mellom lokasjonsadministratoren og applikasjonsruteren eller rutere inkluderer det samme som ovenfor så vel som login-adgang for klienter. Feilmeldinger sendes også fra applikasjonstjeneren eller applikasjonsruteren til lokasjonsadministratoren.

Den lokale applikasjonsruter 152 kan fortrinnsvis håndtere både strømobjekter og basisobjekter mottatt fra klientene, andre applikasjonsrutere eller andre enheter i nettet. Klienter sender én kopi av hver oppdatering av et basisobjekt til den lokale applikasjonsaksesstjener. Objektet inneholder for eksempel statusen til spillerens avtar. Basisobjektet sendes videre til alle relevante applikasjonstjenere i sesjonen. Basisobjekter mottatt av en applikasjonsruter fra klienter eller andre applikasjonsaksesstjenere lagres i applikasjonstilstandslisten til den tilknyttede applikasj onst jener. Spillere som ønsker å motta strømobjekter, ut-lokasjoner en subskripsjon til den lokale applikasjonstjener. Applikasjonstjeneren sender en serie med oppdateringer av objektet fra den lokale applikasjonstilstandslisten i henhold til parameterne i subskripsjonen. Strømobjekter lagres ikke i applikasjonstjeneren. Basisobjekter og strøm-objekter vil bli diskutert i nærmere detalj i det følgende. En applikasjonsruter mottar applikasjonstransportprotokoll-(ATP) pakker fra klientene, den lokale applikasjonstjener, fra andre applikasjonsrutere og eventuelt fra den lokale lokasjonsadministrator. ATP-pakkene transporteres gjennom andre nettverksprotokoller, slik som DDP/lP. Andre applikasj onsrutere er enten fjerntliggende (hører til en fjerntliggende applikasjonsaksesstjener) eller lokale (hører til den samme applikasjonsaksesstjener som applikasjonsruteren) . De mottatte ATP-pakker er av tre forskjellige typer: basisobjekter og strømobjekter i applikasjonsobjektpakker (AOP), kontrolldata i applikasjonskontrollpakker (ACP), og klientmeldinger i klientmeldingspakker (CMP). ATP-pakkene ble enten slettet eller rutet ved hjelp av unicast eller multicast til mottagende klienter, applikasjonsrutere, den lokale applikasjonstjener eller til den lokale lokasjonsadministrator. De forskjellige rutingstilfellene er vist i tabellen. Kontrollpakkene som er administrert til den mottagende applikasjonsruter, termineres og rutes ikke.

En rutingstabell for en applikasjonsruter er vist i tabellen nedenfor:

Strømobjekter er ikke lagret i applikasjonstjeneren. Klienter bruker dem typisk for å sende posisjonen til bevegelige objekter i den virtuelle verden. De kan transporteres svært raskt gjennom nettet. Bare den siste versjonen av et strøm-obj ekt antas å bety noe for den mottagende klient. Håndte-ring av strømobjekter er typisk upålitelig, da de kan for-kastes med hensikt av applikasjonsruterne for flytkontroll. Alle strømobjekter mottatt av en applikasjonsruter sendes videre til alle lokale klienter som skal motta strømobjek-tet eller til en strømobjektgruppe som består av strømob-jekter. Applikasjonsruteren 152 inneholder også prioritets-eller subskripsjonsinformasjon for strømobjekter, siden disse objektene ikke håndteres av applikasjonstjeneren, som vil bli beskrevet nedenfor.

En klient som ønsker å ta del i en applikasjonssesjon, for eksempel en bestemt pågående flerspillsesjon, kobler seg typisk over Internett til en applikasjonslobbytjener 176. Applikasjonslobbytjeneren tilveiebringer informasjon om pågående applikasjonssesjoner og tillater vanligvis klienter å opprette nye sesjoner og invitere andre klienter om å være med. En klient kan sende en forespørsel til applika-sjonslobbyt jeneren 176 for å opprette, slette, tiltre eller forlate applikasjonssesjonen. Hvis applikasjonslobbytjeneren aksepterer en hvilken som helst sesjonskontrollfore-spørsel, vil den videresende forespørselen til en lobbyak-sest jener 178. Hvis opprettelsen av en sesjon forespørres, vil lobbyaksestjeneren 178 respondere ved å utstede en applikasjonssesjonsidentifikator. For forespørsler slik som en forespørsel for å slette en sesjon eller legge til eller fjerne en klient, vil applikasjonslobbytjeneren 176 inneholde applikasjonssesjonsidentifikatoren i forespørselen som sendes til lobbyaksestjeneren 178. Lobbyaksestjeneren 178 responderer ved å undersøke om ressurser er tilgjengelig i applikasjonsaksesstjenersystemet som er tilpasset den forespurte operasjon. Hvis ressurser er tilgjengelig, vil lobbyaksestjeneren 178 utføre den forespurte operasjon.

Hvis opprettelsen av en sesjon forespørres vil lobbyaksestjeneren 178 velge et sett med lokasjoner som vil betjene sesjonen og sende kontrollmeldinger med sesjonsidentifikatoren til de relevante lokasjonsadministratorene 174 som forespør at sesjonen initieres på passende applikasjonsak-sesst jenere 150.

Hvis sletting av en sesjon forespørres, vil lobbyaksestjeneren 178 sende kontrollmeldinger som inneholder sesjons-identif ikatoren til lokasjonsadministratorene 174 til loka-sjonene som kjører sesjonen som forespør at sesjonen slettes.

Hvis en tiltredelse av en klient forespørres, vil applika-sjonslobbyt jeneren 176 inneholde i det minste nettverksadressen til klienten 170, sesjonsidentifikatoren og eventuelt en lokasjonsidentifikator i kontroilmeldingen til lob-byaksest jener 178. Nettverksadressen kan for eksempel være IP-adressen og portnummeret til klientapplikasjonsproses-sen. Lobbyaksestjeneren 178 velger en passende lokasjon og sender en kontrollmelding til lokasjonsadministratoren 174 til lokasjonen som forespør klientens 170 tiltredelse til spillsesjonen. Kontrollmeldinger inneholder i det minste nettverksadressen til klienten 170 og sesjonsidentifikatoren til lokasjonsadministrator 174 til denne lokasjonen. Lokasjonsadministratoren velger en passende applikasjonsak-sesst jener og en passende applikasjonsaksessruter innenfor den enheten som skal være ansvarlig for å betjene klienten, og sender en kontrollmelding til klienten 170 som inviterer klienten å tiltrede spillet. Nettverksadressen til applikasjonsruteren som vil betjene klienten og et passord er inkludert i meldingen. Klienten 170 kontakter den relevante applikasjonsaksesstjener 150 inkludert passordet i kontrollmeldingen. Applikasjonsaksesstjeneren 150 inneholder klienten 170 i den lokale klientdatabase og klienten kan fortsette å sende og motta spilldata.

Alternativt kan lokasjonsadministratoren 174 sende nettverksadressen til applikasjonsrutere 152 som vil betjene klienten 170 til lobbyaksestjener 178, og lobbyaksestjeneren 178 vil videresende nettverksadressen og et passord til applikasjonslobbytjeneren 150. Applikasjonslobbytjeneren 176 vil videresende nettverksadressen og et passord til den forespørrende klient 170 som kobles til den relevante applikasj onsaksesst jener som beskrevet ovenfor.

Selv om ingen buffere, programvareprosesser etc. er vist i figur 6, vil det være å foretrekke for fagfolk på området at det kan være ønskelig å implementere applikasjonsaksesstjeneren i henhold til oppfinnelsen.

Klientene 170, applikasjonsaksesstjenerne 150 og lokasjonsadministratorene 174 kommuniserer ved å benytte applikasj onstransportprotokollen (ATP). ATP-pakker bæres typisk i nyttelasten i UDP-pakkene som diskutert i den foregående utførelse. ATP-en som benyttes i denne utførelsen, vil bli beskrevet i det følgende. Applikasjonstransportprotokollen inneholder to protokollnivåer 1) blandings-ATP-pakke 2) regulær ATP-pakke.

En blandings-ATP-pakke består av et kildehode og flere regulære ATP-pakker. Kildehodet består av følgende felt:

1) applikasjonssesjonsidentifikator

2) klientidentifikator som indikerer den sendende klient 3) valgbare felt som benyttes av protokollen for garan-tert transmisjon inkludert kvitteringsfelt og pakketellere.

En regulær ATP-pakke (heretter også kalt "ATP-pakke") består av et ATP-hode, et valgbart ATP-hode, et valgbart ATP-målhode og en ATP-innholdspakke.

ATP-hodet kan inneholde følgende felt:

1. En type felt som er et sett med flagg som indikerer type innholdspakke og tilstedeværelsen av valgbare felt i innholdspakken. Innholdspakketypene er kontrollmelding, klientmelding, basisobjekt eller strømob-jekt. Den påtenkte mottaker av en melding kan være indikert av typefeltet. 2. Et flagg som indikerer om ATP-pakken er sendt i en på-litelig eller upålitelig modus.

3. Et flagg som indikerer om et målhode er til stede.

4. Et sett med flagg som indikerer tilstedeværelsen og innholdet av det valgbare ATP-hodet. 5. Et felt som indikerer størrelsen av innholdspakken.

Det valgbare ATP-hodet består av følgende valgbare felt:

1. sesjonsidentifikator,

2. klientidentifikator,

3. objektidentifikator.

Det valgbare ATP-hodet benyttes for å identifisere innholdspakken. Applikasjonsnyttelasten som er tilknyttet et basisobjekt, kan for eksempel være sendt i innholdspakken. Det valgbare ATP-hodet benyttes for å identifisere basisobjektet ved å benytte det relative adresseringssystemet som er beskrevet nedenfor.

ATP-målhodet TH benyttes for direkte adressering av ATP-pakker. ATP-adressen til mottakeren indikeres i ATP-målhodet. Den første posisjonen i TH er en byte som angir størrelsen av TH. TH består av en rekke med dynamiske adressefelter som enten er en liste over klientidentifikatorer som indikerer de påtenkte mottakerne av meldingen eller en liste av strømobjektnøkler. En nøkkel er et attributt for strømobjektet som kan settes av senderen. Klientene kan ønske å motta strømobjektene som bærer en bestemt nøkkel uten å vite objektidentifikatorene til de ønskede strømob-jektene. I et spill om Quake kan nøkler benyttes for å velge strømobjekter som hører til forskjellige rom. Strømob-jektene benyttes for å sende posisjonene til avatarene i spillet. En nøkkel tildeles hvert rom i spillet. Spillerne som sender strømobjektene, setter inn nøkkelen som tilhører rommet hvor avataren er lokalisert. Spillere som mottar data er "abonnenter" av strømobjekter med nøkler som hører til rom i hvilke de er satt inn i. Strømobjektnøkler kan alternativt benyttes for å identifisere et lag eller til å klassifisere objekter, for eksempel som farlige. Et strøm-obj ektfilter i den lokale applikasjonsaksesstjener mottar spillerens subskripsjoner for strømobjektnøkler og sørger for at spilleren får strømobjekter med de forespurte nøk-ler.

ATP-innholdspakken (CP - Content Packet) kan være av en av de følgende typer 1) basisobjekt, 2) strømobjekt, 3) kontrollmelding eller 4) klientmelding. Et basisobjekt, et strømobjekt og en klientmeldings CP inneholder applikasj onsnyt telast . Kontrollmeldingene inneholder en meldingstype og meldingsparametere. Applikasjonskontrollprotokollen spesifiserer formatet til meldingstypefeltet og parameterne i hver melding.

Sesjonsidentifikatorer, klientidentifikatorer og objektidentifikatorer er dynamiske adressefelter som beskrevet nedenfor. Klientgrupper og objektgrupper har det samme identifikatorformat som henholdsvis klienter og objekter.

De følgende navn og definisjoner benyttes i dette dokument. En applikasjonsobjektpakke er en ATP-pakke som inneholder et applikasjonsobjekt i innholdspakken. En applikasjons-kontrollprotokollpakke er en ATP-pakke som inneholder en kontrollmelding i innholdspakken. Å sende et basisobjekt, strømobjekt eller en klientmelding betyr alltid at en ATP-pakke med passende innholdspakketype sendes. En klientmel-dingspakke er en ATP-pakke som inneholder en mottakeradres-se og en klientmelding i innholdspakken.

ATP-brukseksempler følger:

a) Klient sender et basisobjekt til den lokale applika-sjonst jeneren. Objektidentifikatoren, men ikke klientidentifikatoren eller sesjonsidentifikatoren, legges inn i det valgbare ATP-hodet. Ingen ATP-målhoder er nødvendig. Objektnyttelasten legges inn i innholdslas-ten. Bruken av valgbare hoder og dynamiske adressefelt betyr at hodekostnaden kan bli så liten som fire bytes. Dette er essensielt siden objekter ofte sendes over en liten båndbreddeforbindelse. b) En klient sender en klientmelding til en annen klient.

Objektidentifikatoren og klientidentifikatoren til den

sendende klient legges inn i det valgbare ATP-hodet. Ingen sesjonsidentifikator er nødvendig. Et målhode som består av klientidentifikatoren til den mottagende klient benyttes. Meldingsnyttelasten legges inn i innholdspakken. Inngangsfilteret til applikasjonsruteren på den sendende siden legger til sesjonsidentifikatoren i målhodet. Dtgangsfilteret til applikasjonsruteren på den mottagende side fjerner sesjonsidentifika-

toren før den videresender pakken til den mottagende klient.

ATP bruker dynamiske adressefelt. Et dynamisk felt er en prefikskode med variabel lengde. En prefikskode er en kode hvor hvert kodefelt i en bitstrøm kan dekodes unikt uten referanse til tidligere kodeord. Et enkelt eksempel er al-fabetet {10, 110, 1110, }. Huffmankoder er valgbare (kor-test forventede lengde) prefikskoder for en gitt statistisk distribusjon av symbolet. Et alternativt format for dynamiske adressefelt er heltall av dynamisk størrelse. Heltall med dynamisk størrelse er velkjent i datavitenskapen. Heltall med dynamisk størrelse benyttes der små verdier er vanligst, men større verdier kan være mulig. For to-bytes heltall med dynamisk størrelse vil det mest signifikante bit fortelle størrelsen på heltallet - 1 betyr en byte og 0 betyr 2 bytes. For 4 byte heltall, forteller det mest signifikante bit størrelsen på heltallet - 01 betyr en byte, 10 betyr to bytes, 11 betyr 3 bytes og 00 betyr 4 bytes.

Dynamiske adressefelt kan benyttes i henhold til en av de to følgende fremgangsmåter: I den første fremgangsmåten har ATP felt for tre forskjellige identifikatorer 1) applikasjonssesjonsidentifikator 2) klientidentifikator og 3) objektidentifikator. Applikasjonssesjonsidentifikatoren er globalt unik og tildeles av en sentral autoritet slik som nettadministratoren eller lobbyaksestjeneren. Hver klient, applikasjonsruter, appli-kasjonst jener og eventuelt lokasjonsadministratorer har en klientidentifikator, og vil i det følgende kalles noder. En klientgruppeidentifikator har formatet til en klientidentifikator .

Klientidentifikatoren er unik bare i en bestemt applikasj onsses jon. En sentral autoritet slik som lobbyaksestjeneren eller en sentral kontrollenhet, tildeler klientidentif-katorer. Klientidentifikatorer identifiserer noden bare hvis applikasjonssesjonsidentifikatoren er kjent. ATP-en lagrer klientidentifikatoren i et dynamisk felt. Hver node i en applikasjonssesjon tildeles en klientidentifikator med så få bit som mulig. Ofte benyttede klientidentifikatorer kan få allokert de korteste kodene, for eksempel i henhold til Huffmankodingsprosedyren.

Objektidentifikatoren er unik for en gitt klient i en gitt sesjon. Klienten tildeler objektidentifikatoren. Objektidentifikatoren identifiserer objektet bare hvis sesjons-identif ikatoren og klientidentifikatoren er kjent. ATP-en lagrer objektidentifikatoren i et dynamisk felt. Hvert objekt tildeles en objektidentifikator med så få bit som mulig. Ofte benyttede objektidentifikatorer kan tildeles de korteste kodene, for eksempel i henhold til Huffmankodingsprosedyren.

Den andre metoden er den samme som den første med følgende unntak. Klientidentifikatoren består av to dynamiske felt. Det første feltet er identifikatoren til applikasjonsruteren som betjener klienten. Det andre dynamiske feltet er en klientindeks. Denne indeksen er valgt til å være så liten som mulig og er unik for klienten gitt at applikasjonssesjonsidentifikatoren og den lokale applikasjonsruterklient-identif ikatoren er kjent. Klientidentifikatoren til den lokale applikasjonstjener kan alternativt benyttes i stedet for klientidentifikatoren til den lokale applikasjonsruter.

Fordelen ved å bruke dynamiske adressefelt, og relativ adressering som beskrevet ovenfor, er at båndbreddebruken og forsinkelsen minimaliseres. Bare de relevante adressefelt sendes. Eksempler på dette er: 1) En klient tar bare del i én applikasjonssesjon. ATP-pakkene som inneholder objekter fra klientene, inneholder bare objektidentifikatorer. Applikasjonssesjonsidentifikatoren og klientidentifikatoren er ikke sendt, siden applikasjonsruteren vet dette implisitt. 2) ATP-pakkene som inneholder objektene som er sendt fra den lokale applikasjonstjener til klienten, trenger bare inneholde objektidentifikatoren og klientidentifikator en til klienten som eier objektet. 3) En klient som oppretter et nytt objekt, kan umiddelbart tildele en objektidentifikator. Sentral tildeling av globalt unike objektidentifikatorer vil kreve kommunikasjon med den sentrale autoritet før et nytt objekt kan opprettes.

Klientgruppeadresseringen håndteres i henhold til det føl-gende: En klientgruppe identifiseres i en ATP ved en klientidentifikator. Identifikatoren opprettes ved å bruke den samme metode som for andre klientidentifikatorer. Opprettelsen av en klientgruppe forespørres av en klient i løpet av applikasjonssesjonen eller opprettelsen av klientgruppen gjennomføres som en del av initialiseringen av sesjonen.

Hver ATP-pakke inneholder en Type Field i ATP-hodet. Type Field indikerer innholdets natur. Forskjellige koder i typefeltet indikerer for eksempel at innholdet er basisobjekt, strømobjekt, kontrollpakke eller en klientmelding. Applikasjonsruteren kan bruke typefeltet for normal ruting i noen tilfeller uten å lese og analysere adressefeltene. Eksempler på normal ruting basert på typefeltet er: 1) alle basisobjekter rutes til den lokale applikasjonstjener 2) kontroilpakkene med én spesifikk kode i typefeltet rutes til den lokale applikasjonstjener og kontrollpakkene med én annen spesifikk kode i typefeltet rutes til den lokale lo-kas j onsadministrator.

Figur 7 viser en applikasjonsruter 152 benyttet i utførel-sen diskutert i forbindelse med figur 6, og hvordan ATP-pakkene strømmer gjennom applikasjonsruteren. Applikasjonsruteren 152 består av et sett med inngangsfiltre 190, 192, en ruterkjerne 194 og et sett med utgangsfiltre 196, 198. Applikasjonsruteren har et inngangs- og et utgangsfilter for hver node med hvilke den kommuniserer. Ruterkjernen 194 består av et antall rutingstabeller 199 for å gjennomføre rutingen av ATP-pakkene.

Pakker kommer fra tre typer kilder; fra applikasjonstjeneren til den samme applikasjonsaksesstjener, og andre lig-nende enheter, for eksempel lokasjonsadministratoren, fra andre applikasjonsrutere og fra applikasjonsklienter koblet til denne applikasjonsruteren. Det er forskjellige rutingstabeller 199 for alle tre typer. Det fins ett innkom-mende filter 190, 192 og et utgående filter 196, 198 for hver forbindelse til en annen applikasjonsruter eller applikasj onsklient. For forbindelser til applikasjonstjener er det ikke nødvendig med noen inngangs- eller utgangsfilter. Filtrene samler sammen flere applikasjonspakker inn i transportpakker og håndterer også hjemsending for påliteli-ge pakker. Applikasjonsklientutgangsfiltrene 196, 198 fjerner redundant informasjon på klientlinjen og sørger også for lastbalansering for nedlinken til applikasjonsklienten 170.

Klienten 170 som er tilknyttet utgangsfilteret, eller en hvilken som helst annen klient som er autorisert, kan sende en subskripsjon for et strømobjekt eller en strømobjekts-nøkkel til utgangsfilteret til den mottagende klient. Subskripsjonen sendes som en kontrollmelding som indikerer innholdet i subskripsjonen og klientidentifikatoren til den mottagende klient. Utgangsfilteret vil skanne strømobjekte-ne som ankommer applikasjonsruterne. strømobjektene som matcher subskripsjonen, sendes til en klient, eventuelt etter å ha benyttet en "drop rate". Et strømobjekt matcher en subskripsjon enten hvis objektidentifikatoren til strømob-jektet er lik objektidentifikatoren som er gitt i subskripsjonen, eller hvis en strømobjektnøkkel som bæres av strøm-obj ektet matcher en strømobjektnøkkel som gitt i subskripsjonen.

Anta et tilfelle når klienten (som er tilknyttet utgangsfilteret) har "abonnert" på et strømobjekt og strømobjektet mottas fra den sendende klient. Klienten eller en hvilken som helst annen klient som er autorisert kan sette en "drop rate" som er tilknyttet et gitt strømobjekt. Denne "drop rate"-en sendes i en kontrollmelding til den lokale applikasj onsruter . Hvis drop raten er satt til en verdi 0 ^ R < 1 vil utgangsfilteret fjerne en fraksjon R av strømobjekte-ne. Hvis for eksempel R = 0,9 vil bare 10 % av pakker som har ankommet få lov til å passere ned til klienten.

Utgangsfilteret vil slette ATP-hodefeltene som ikke trenger å bli sendt til klienten. En direkte adressert melding fra en annen klient inneholder for eksempel applikasjonssesjonsidentifikatoren og klientidentifikatoren til den mottagende klient i hodet. Denne informasjonen er ikke nødven-dig for den mottagende klient og blir derfor slettet av applikasjonsruterutgangsfilteret.

Inngangsfilteret for en bestemt node, slik som en klient, mottar ATP-pakker som inneholder strømobjekter, basisobjekter, kontrollmeldinger og direkte adresserte klientmeldinger fra noden. Før ATP-pakkene sendes til rutingskjernen gjennomføres følgende operasjoner: 1) Inngangsfilteret sjekker om klienten har lov til å oppdatere et strømobjekt eller et basisobjekt eller om den sendende klienten har lov å sende en direkte adressert melding til klienten som er indikert i meldingen. Autoriseringssjekken gjennomføres ved å benytte autorisasjonstabeller som viser hva slags operasjoner som klienten har lov til å gjennomføre. Autorisa-sjonstabellene settes opp av klientene eller av LAS via lokasjonsadministratoren ved å benytte initialiseringsfiler. 2) Inngangsfiltre legger til adressen til den sendende klient i riktig ATP-felt. Denne adressen sendes ikke på kommunikasjonslinken mellom den sendende klient og applikasjonsruteren for å spare båndbredde. 3) Applikasjonsruteren lager lister over klientgrupper. Slike lister tilknytter en klientidentifikator som indikerer en klientgruppe til en liste over klientiden-tif ikatorer som indikerer klienter. Listen over klientgrupper settes opp av klienter eller av LAS via lo-kas jonsadministratoren. Hvis en ATP-pakke med en klientgruppe i mottakeradressefeltet mottas av inngangsfilteret, vil den gjøre én av følgende alternative operasjoner: A) Finne listen med klientidentifikatorer som hører til klientgruppen. B) Finne antall N med applikasjonsrutere som skal motta i det minste én kopi av ATP-pakken. C) Lage N kopier av ATP-pakken som legges inn i utgangsfilteret til hver av de mottagende applikasjonsruterne. Det er et flagg i ATP-hodet som indikerer at innholdet ikke skal distribueres til noen fjerntliggende mottaker, men bare til lokale klienter. Dette flagget settes i hver utgangspakke. Dette er den foretrukne operasjonsmodus. 4) Finne listen over klientidentifikatorer som hører til klientgruppen. Finne antallet N med applikasjonsrutere som skal motta i det minste én kopi av ATP-pakken. Lage N kopier av ATP-pakken som legges inn i utgangsfilteret til hver av de mottagende applikasjonsruterne. I hver pakke erstattes klientgruppeidentifikatoren med en liste over mottagende klienter hvor listen bare inneholder medlemmer av klientgruppen som er lokale klienter til den mottagende applikasjonsruter. Dupli-ser ATP-pakken slik at i hvert duplikat erstattes kli-entgruppeidentif ikatoren med én ny klientidentifikator som indikerer én av klientene i klientidentifikator-listen som er tilknyttet klientgruppen. 5) Et defaulthode (default header) lagres av inngangsfilteret for hvert strømobjekt som klienten som er til-

knyttet inngangsfilteret sender. Dette defaulthodet inneholder strømvektnøkler tilknyttet strømobjektet. Hvis klienten sender et eksplisitt hode som inneholder strømobjektnøkler, vil dette hodet erstatte defaulthodet som lagres av inngangsfilteret. Hvis klienten sender strømobjektet uten et hode som inneholder strømob-jektnøkler, vil inngangsfilteret legge til defaulthodet til strømobjektet før den sender det til ruterkjernen. Dette betyr at den sendende klient ikke trenger å sende en kopi av strømobjektnøklene med hver kopi av strømobjektet. Det er tilstrekkelig å sende et hode som inneholder strømobjektnøklene hver gang nøk-lene endres, samt første gang objektet sendes.

En regulær ATP-pakke bærer et innhold som enten er et applikasj onsob jekt (strøm eller basis), en kontrollmelding eller en klientmelding. En blandings-ATP-pakke består av et valgbart lite blandingshode, og i det minste én og vanligvis flere regulære ATP-pakker. En blandings-ATP-pakke sendes som nyttelast i en standard transportprotokoll. Vanligvis sendes blandings-ATP-pakker som nyttelast i UDP-pakker.

Metoden for å samle regulære ATP-pakker i blandings-ATP-pakkene er essensielt for å oppnå den korrekte balansen mellom båndbreddeeffektivitet og liten forsinkelse. Store blandings-ATP-pakker gir høy transmisjonsforsinkelse, men liten hodekostnad og dermed effektiv båndbreddeutnyttelse. Oppsamling av regulære ATP-pakker inn i blandings-ATP-pakker finner sted i flere moduler i systemet.

For oppsamling i applikasjonsklienten for å sende til den lokale applikasjonsruter, kan to alternative fremgangsmåter benyttes: I den første fremgangsmåten er oppsamlingen under direkte kontroll av applikasjonsprogrammet. Regulære ATP-pakker sendes til et utgangsbuffer. Applikasjonsprogrammet bestemmer når innholdet av bufferet skal settes inn i blandings -ATP-pakken og transmitteres til den lokale applikasj onsruter. I den andre fremgangsmåten gjennomføres oppsamlingen av en automatisk algoritme i klienten. Regulære ATP-pakker sendes til et utgangsbuffer av applikasjonsprogrammet. Algoritmen bestemmer når innholdet av bufferet skal settes inn i blandings-ATP-pakken og transmitteres til den lokale applikasjonsruter. Et eksempel på passende algoritme er: En blandingspakke sendes hvis bufferstørrelsen overskrider en gitt størrelse S. En blandingspakke sendes hvis tidsperioden siden den siste transmisjonen av en blandingspakke overskrider et gitt tidsintervall T. Parameterne S og T settes av applikasjonsprogrammet.

For oppsamling i applikasjonsruteren for å sende til en klient kan for eksempel den samme algoritmen som i den andre fremgangsmåten ovenfor benyttes. For oppsamling i applikasj onsruteren for sending til en applikasjonsruter, vil det å sende den største ATP-blandingspakken som er tillatt av det neste protokollnivået, for eksempel UDP vanligvis gå bra, siden kommunikasjonslinken mellom applikasjonsruterne kan antas å være svært raske, og regulære pakker sendes veldig ofte.

Hvis båndbredden er begrenset eller ATP-pakkene sendes sjelden, er det anbefalt å bruke den samme algoritmen som i fremgangsmåte 2 i den foregående seksjon for oppsamling i applikasj onsklienten.

Størrelsen S (i bit) bør være valgt slik at S<V*TO hvor V er kommunikasjonshastigheten til linken mellom de to applikasj onsruterne målt i bit per sekund og TO er den tillatte transmisjonsforsinkelsen, vanligvis 1-10 ms. Tidsinterval-let T bør være i intervallet 1-10 ms.

Klienter kan sende subskripsjoner for basisobjekter som kontrollmeldinger til den lokale applikasjonstjener. En subskripsjon spesifiserer de mottagende klienter, et mål for subskripsjonen og subskripsjonsparametrene. En subskripsjon er en instruksjon til applikasjonstjeneren om å sende en serie med basisobjekter til de mottakende klienter. En serie med oppdateringer for hvert basisobjekt sendes i henhold til parametrene av subskripsjonen og avhengig av hvordan kilden til basisobjektet oppdaterer den.

Klienten som sender subskripsjonen, er vanligvis den mottakende klient, men en klient kan også gjøre en subskripsjon på vegne av en annen klient. En subskripsjon kan også utstedes på vegne av en klient. Alle klienter i klientgruppen vil da motta resultatet av subskripsjonen.

Målet for subskripsjonen er et sett med basisobjekter identifisert av objektidentifikatorer i henhold til ATP-protokollen. Målet kan være beskrevet av 1) en objektidentifikator, 2) et sett med objektidentifikatorer, 3) en ob-jektgruppeidentifikator, 4) et mikset sett med objektiden-tif ikatorer og objektgruppeidentifikatorer, 5) generell Boolsk uttrykk som inneholder objektgrupper og objekter som operander og logiske operatorer AND, OR og NOT. Et riktig definert måluttrykk evalueres av applikasjonstjeneren ved å benytte informasjonen i objektdatabasen og objektgruppeda-tabasen. Resultatet av denne evalueringen er alltid et en-delig sett med basisobjekter.

Subskripsjonsparametrene kan benyttes til å spesifisere hvor ofte, hvor mange ganger og hvor lenge innholdet i subskripsjonen skal leveres. Dette kan spesifiseres som maksimumsraten som oppdaterte versjoner av objektet skal mottas på. Hvis eieren av objektet oppdaterer den med en lavere rate, vil hver nye versjon mottas så snart den er levert. Hvis objektet oppaterers fastere enn den valgte maksimumsraten, vil oppdateringene mottas med nøyaktig den raten som er valgt. Noen av de mellomliggende versjoner vil ikke bli mottatt i dette tilfellet.

En innholdstjener eller masterklient kan ha overordnet kjennskap til spillets tilstand. Det kan derfor være passende at masterklienten "abonnerer på" basisobjekter på vegne av en målklient. Masterklienten vil da bygge og legge inn subskripsjonen i systemet. Den lokale applikasjonsak-sesst jener leverer basisobjektene som er forespurt i subskripsjonen direkte til målklienten eller målklientgruppen.

En subskripsjon hører til en klient eller en klientgruppe. En subskripsjon refererer til et sett med spillobjekter. Dette settet kan uttrykkes som et generelt Boolsk uttrykk inkludert objektgrupper og objekter.

Applikasjonsaksesstjeneren (AAS) vil forsøke å levere objekter med subskripsjonsfrekvens. Leveringstiden er den in-verse av subskripsjonsfrekvensen. Objektene som eksisterer i databasen når subskripsjonen utstedes, vil leveres innenfor leveringstiden. Hvis et objekt i databasen modifiseres mens subskripsjonen er aktiv, vil AAS forsøke å levere den innenfor leveringstiden.

En subskripsjonsklasse er et positivt heltall. To metoder for å levere data i henhold til subskripsjonsklassen er beskrevet her.

Metode 1: Subskripsjoner med den høyeste klassen blir først tilfredsstilt fullstendig. Deretter vil AAS forsøke å til-fredsstille subskripsjonene i den nest høyeste klassen fullstendig. Dette betyr at subskripsjoner i lavere klasser ikke nødvendigvis vil bli tilfredsstilt. Hvis båndbredden er utilstrekkelig for å levere objekter innenfor en subskripsjonsklasse med den forespurte frekvens, vil AAS ska-lere alle frekvenser innenfor klassen slik at det blir mulig å levere den til klienten.

Metode 2: Tre forskjellige klasser benyttes. De forskjellige klassene er kalt 1=HIGH, 2=MEDIUM og 3= LOW. Med klasse 1 sendes objektet alltid med maksimumsraten til bufferet er fullt og raten faller til null. Med klasse 2 er objektets senderate proporsjonalt med bufferlasten. Jo mindre buffer-kapasitet jo lavere rate. I klasse 3 sendes objektet bare hvis det ikke er noen andre objekter i bufferet.

I én bestemt implementasjon kan applikasjonsobjektpakker inneholde flere nummererte nyttelaster. I dette tilfellet har subskripsjoner en valgbar vektparameter. Vektparamete-ren er et heltall. Vekt = n betyr at de første n nyttelaster i objektet er levert.

Noen objekter kan ikke oppdateres ved regulære intervaller, men i stedet et nøyaktig antall ganger. Derfor er det mulig å forespørre et bestemt antall oppdateringer for et bestemt objekt. Applikasjonstjeneren vil da sette en teller som er tilknyttet objektet til en heltallsverdi som er spesifisert i subskripsjonen. Telleren dekrementeres ved én enhet hver gang objektet leveres. Subskripsjonen fjernes hvis telleren = 0.

Klienten kan forespørre at objektet skal sendes ved den forespurte frekvens selv om den samme oppdateringen har blitt sendt tidligere. Dette gjøres ved å sette "forced sending" FS-flagget.

For å forhindre at informasjon som vedrører gamle subskripsjoner overlaster nettet, bør levetid, eller varighet av en subskripsjon settes. Subskripsjonen fjernes etter subskrip-sjonens livstid har utgått.

Strømobjektene distribueres mellom distribusjonsruterne ved å benytte en av de følgende fremgangsmåter: Fremgangsmåte 1) Et strømobjekt som mottas av en applikasj onsruter dupliseres og sendes til alle andre applikasj onsrutere som deltar i applikasjonssesjonen. Dette kan gjøres effektivt ved for eksempel å knytte alle applikasj onsrutere som tar del i applikasjonssesjonen til en IP-multicastadresse.

Fremgangsmåte 2) Hver applikasjonsruter mottar et sett med subskripsjoner for strømobjekter og strømobjektnøkler fra lokale klienter. Alle slike subskripsjoner samles opp til en samlesubskripsjon som inneholder alle strømobjekter og strømobjektnøkler som lokale klienter "abonnerer på" uten noen duplikasjoner. Strømobjekter, men ikke strømobjektnøk-ler, som er generert av lokale klienter, fjernes fra den oppsamlede subskripsjon. Den oppsamlede subskripsjon sendes til alle andre applikasjonsrutere. En applikasjonsruter som mottar en oppsamlet subskripsjon fra en annen applikasjonsruter og som finner at kilden til noen av strømobjektene og strømobjektnøklene i den oppsamlede subskripsjon er blant de lokale klienter, vil sende den delen av subskripsjonen til den "abonnerende" applikasjonsruteren.

Fremgangsmåte 3) Hver applikasjonsruter gjør klar et oppsamlet sett med subskripsjoner som i fremgangsmåte 2. Den oppsamlede subskripsjon sendes til en forelderapplikasjonsruter som har blitt tildelt av lokaladministratoren. Forelderapplikasjonsruteren leverer delsettet av den oppsamlede subskripsjon som er tilgjengelig, og inkluderer det gjenværende i dens egne oppsamlede subskripsjon som sendes til forelderapplikasjonsruteren som har blitt tildelt den førs-te forelderapplikasjonsruter. Dette forutsetter at admi-nistrasjonssystemet har organisert et hierarki av applikasj onsrutere for applikasjonssesjonen.

Basisobjekter er distribuert mellom applikasjonstjenere. En applikasjonstjener nås alltid via en av dens tilknyttede lokale applikasjonsrutere. Når en applikasjonstjener sender et basisobjekt til en annen applikasjonstjener, sender den første applikasjonstjener alltid basisobjektet med den andre applikasjonstjenerens identifikator i mottakerens adressefelt til ATP-pakken til en av de lokale applikasjonsruterne. Denne applikasjonsruteren vil sende objektet til en lokal applikasjonsruter for den andre applikasjonstjeneren. Den lokale applikasjonsruter for den andre applikasjonstjener vil sende objektet til den andre applikasjonstjener.

Basisobjekter distribueres mellom applikasjonstjenere som benytter en av de følgende metoder: Metode 1) Et basisobjekt som mottas av en applikasjonstjener dupliseres og sendes til alle andre applikasjonstjenere som tar del i applikasjonssesjonen. Dette kan alternativt gjøres effektivt ved å tilknytte en lokal applikasjonsruter for hver applikasjonstjener som tar del i applikasjonssesjonen med en IP-multicastadresse.

Metode 2) Hver applikasjonstjener mottar et sett med subskripsjoner til basisobjekter fra lokale klienter. Alle slike subskripsjoner oppsamles til en samlesubskripsjon som inneholder alle basisobjekter som lokale klienter "abonnerer på", men uten noen subskripsjonsparametere. Basisobjekter som genereres av lokale klienter fjernes fra den oppsamlede subskripsjon. Den oppsamlede subskripsjon sendes til alle andre applikasjonstjenere. En applikasjonstjener som mottar en oppsamlet subskripsjon fra en annen applikasj onst jener og som finner at kilden til et av basisobjektene i den oppsamlede subskripsjon er blant de lokale klienter, vil umiddelbart sende slike objekter til subskrip-sjonsapplikasjonstjeneren for å lagre den relevante delen av subskripsjonen. Alle ytterligere oppdateringer av de relevante objektene vil også sendes umiddelbart til subskrip-sjonsapplikasjonstjeneren.

Metode 3) Hver applikasjonstjener gjør klar et oppsamlet sett av subskripsjoner som i metode 2. Den oppsamlede subskripsjon sendes til en forelderapplikasjonstjener som har blitt tildelt av lokasjonsadministratoren. Forelderapplika-sj onsruteren leverer delsettet av den oppsamlede subskripsjon som er tilgjengelig og inkluderer de gjenværende i dens egen oppsamlede subskripsjon som sendes til forelder-applikasjonstjeneren som har blitt tildelt den første for-elderappl ikasj onst jener. Dette forutsetter at administra-sjonssystemet har organisert et hierarki av applikasjonstjenere for applikasjonssesjon.

Kontrolldata som må distribueres blant alle applikasjonsak-sesst jenere som tar del i en sesjon som for eksempel innbefatter klienter som slutter seg til og forlater og opprettelse og destruksjon av klientgrupper. Slike kontrolldata kan multicastes til alle applikasjonsrutere i sesjonen. Applikasjonsrutere vil enten terminere kontroilmeldingen eller sende den videre til den lokale applikasjonstjener eller lokasjonsadministrator som forespurt.

Noen klienter kan være registrert med en applikasjonsak-sesst jener som tilskuere (spectators). Tilskuere har ikke lov til å laste opp applikasjonshandlinger, men de kan laste opp en subskripsjon som er avhengig av tilskuerens me-ning om spillet.

Applikasjonsaksesstjeneren i henhold til oppfinnelsen kan også benyttes i hierarkiske systemer. Figur 8 viser et eksempel på en slik konfigurasjon hvor en høynivå applika-sjonsaksesst jener 201 betjener andre applikasjonsaksesstjenerenheter 203, 205, 207 som i sin tur tjener applikasjonsklienten 209. Høynivå applikasjonsaksesstjeneren 201 mottar ATP-pakker med spilldata og oppsamlede subskripsjoner fra nedstrøms applikasjonsaksesstjenerenheter som anses å være "klienter". Høynivå applikasjonsaksesstjenerenheten 201 kommuniserer med andre likestilte applikasjonsaksesstjenerenheter og eventuelt med applikasjonsaksesstjenerenheter som er på et enda høyere nivå i hierarkiet. Hierarkiske applikasjonsaksesstjenersystemer benyttes for å opprette en hierarkisk distribuert representasjon av spilltilstanden for en applikasjon som involverer et stort antall klienter. Fjerntliggende applikasjonstjenerenheter kan være organisert i et multicastingtre og i det tilfellet vil det være ett sorteringsbuffer per multicastinggruppe. En enkel dist-ribusjonsstrategi hvor all informasjon sendes til alle fjerntliggende applikasjonsaksesstjenerenheter kan benyttes. I det tilfellet er det bare en buffer.

Et sett med applikasjonsklienter kan ha bredbåndforbindel-ser som tilveiebringer lavforsinkelsesaksess slik at ingen applikasjonsaksesstjener er nødvendig. Et typisk eksempel er at alle spillere er på samme LAN. Hvis spillapplikasjonen og APl-en fortsatt forventer en applikasjonsaksesstjener, vil det være mulig å kjøre en applikasjonsaksesstjener funk sjon i programvaren på klientmaskinen.

En applikasjonsaksesstjenerenhet kan også være plassert i en hvilken som helst mellomliggende posisjon i nettet. Dette betyr at "link"-protokollen mellom klient og applika-sjonsaksesst jener eventuelt kan være UDP/IP eller TCP/IP. Alternativt kan en sentral spilltjener Bom kjører en inn-ringningsspilltjeneste bruke applikasjonsaksesstjenerenheter som komponenter. Den sentrale lokasjonen vil da bestå av et sett med modempooler som er koblet til applikasjons-aksesst jenerenhetene og applikasjonslobbytjenerne. Dette vil være en effektiv og skalerbar arkitektur for å bygge en sentral lokasjon, men den vil ikke ha fordelene med tidlig oppsamling av spilltrafikk.

Claims (20)

1. Tjenerenhet som kan kobles til i det minste en første og en andre klientenhet {11, 12, 13, 14, 15) og som er tilpasset til å aktivere kommunikasjon mellom den første og den andre klientenhet gjennom tjenerenheten for å kjøre en distribuert interaktiv applikasjon som har en tilstand som kan endres av både den første og andre klientenheten, karakterisert ved : - et første mottaksmiddel (51, 53) for å motta applikasjonstilstandsinformasjon om tilstanden til applikasjonen fra i det minste den første klientenheten, - et tilstandsinformasjonslagringsmiddel (55) for å lagre applikasjonstilstandsinformasjon, - et andre mottaksmiddel (59) for å motta prioritetsinformasjon fra i det minste den første klientenheten om applikasjonstilstandsinformasjon som skal sendes til den første klientenheten, et prioritetsinformasjonslagringsmiddel (61) for å lagre den mottatte prioritetsinformasjon, et første transmisjonsmiddel (63, 65) som samarbeider med tilstandsinformasjonslagringsmiddelet og priori-tetsinf ormas jonslagringsmiddelet for å transmittere applikasjonstilstandsinformasjon til den første klientenhet avhengig av prioritetsinformasjonen.

2. Tjenerenhet i henhold til krav 1, karakterisert ved at den videre omfatter et andre transmisjonsmiddel (63, 65) for å transmittere applikasjonstilstandsinformasjon og/eller prioritetsinformasjon mottatt fra i det minste den første klientenheten til i det minste den andre tjenerenheten.

3. Tjenerenhet i henhold til krav 1, karakterisert ved at den videre omfatter en subskripsjonsliste for å lagre subskripsjonsinformasjon mottatt fra nevnte i det minste en første klientenhet gjennom det andre mottaksmiddel (59), nevnte subskripsjonsinformasjon identifiserer hvor ofte informasjon relatert til et bestemt objekt skal mottas i den første klientenheten.

4. Tjenerenhet i henhold til et av de foregående krav, karakterisert ved at den videre omfatter en subskripsjonsliste for å lage subskripsjonsinformasjon mottatt fra nevnte i det minste en første klientenhet gjennom det andre mottaksmiddel, nevnte subskripsjonsinformasjon identifiserer antall ganger informasjon relatert til et visst objekt skal mottas i den første klientenhet.

5. Tjenerenhet i henhold til et av de foregående krav, karakterisert ved at det andre mottaksmiddel er tilpasset til å motta prioritetsinformasjon relatert til nevnte første klientenhet fra i det minste en tredje node, som representeres som en klientnode, og videresender eller ikke videresender applikasjonstilstandsinformasjon med opprinnelse i nevnte tredje node til i det minste nevnte første klientenhet avhengig av nevnte priori-tetsinf ormas jon.

6. Tjenerenhet i henhold til et av de foregående krav, karakterisert ved at tilstandsinformasjonslagringsmiddelet er tilpasset til å kvitte seg med lagret tilstandsinformasjon etter en forhåndsdefinert tids-periode.

7. Tjenerenhet i henhold til et av de foregående krav, karakterisert ved at nevnte tilstandsinformasj onslagringsmiddel er tilpasset til å lagre applikasj onstilstandsinf ormas jonen i form av egenskaper til objekter, nevnte objekter innsetter applikasjonstilstanden.

8. Tjenerenhet i henhold til krav 7, karakterisert ved at nevnte tilstandsinformasj onsmiddel er tilpasset til å lagre referansepakker eller datagrammer som beskriver tilstanden til et objekt ved et gitt tidspunkt.

9. Tjenerenhet i henhold til krav 8, karakterisert ved at nevnte tilstandsinformasj onslagringsmiddel er tilpasset til å lagre tilleggspakker som beskriver endringen av tilstanden til objektet siden en bestemt forutgående pakke, og informasjon som identifiserer nevnte forutgående pakke.

10. Tjenerenhet i henhold til et av de foregående krav, karakterisert ved at den videre omfatter et registreringsmiddel for å registrere autoriseringsinfor-masjon for nevnte i det minste en første klientenhet, nevnte autorisasjonsinformasjon indikerer applikasjonstil-standsobjektene som nevnte første node er autorisert til å endre.

11. En klientenhet som kan kobles til en applikasjonsaksesstjenerenhet (1, 3, 5), applikasjonsaksesstjenerenheten er tilpasset til å lagre og eksekvere en distribuert interaktiv klientapplikasjonsprogramvare som er tilpasset til å distribuere en interaktiv applikasjon, består av: inngangsmiddel (111, 113, 115, 101) som samarbeider med klientapp-likas jonsprogramvaren, transmisjonsmiddel (105, 107) for å sende applikasjonstilstandsinformasjonen til applikasjons-tjenerenheten, mottaksmiddel (105, 107) for å motta appli-kas jonstilstandsinf ormas jon fra applikasjons-aksesst j enerenheten, en prosesseringsenhet (101) for beregning, karakterisert ved at for å gjøre det mulig for i det minste to klientenheter å samtidig påvirke og bidra til tilstanden til applikasjonen: inngangsmiddelet (111, 113, 115, 101) legger i det minste inn applikasjonstilstandsinformasjon fra applikasjonsaksesstjenerenheten (1, 3, 5) for den distribuerte interaktive applikasjon, og prosesseringsenheten (101) er tilpasset til å beregne en andre tilstand for applikasjonsprogramvaren fra applikasj onstilstandsinf ormas j onen mottatt fra applikasjonstje-nerenheten, den andre tilstanden brukes for å påvirke ekse-kveringen av klientapplikasjonsprogramvaren.

12. Klientenhet i henhold til krav 11, karakterisert ved at den videre omfatter prioritetssettingsmiddel for å sette prioritetsinformasjon for å spesifisere i det minste ett annet applikasjonstil-standsobjekt om hvilken tilgjengelig informasjon skal mottas så snart som mulig og et transmitteringsmiddel for å transmittere nevnte prioritetsinformasjon fra nevnte prioritetssettingsmiddel til nevnte applikasjonsaksesstjenerenhet.

13. Klientenhet i henhold til krav 11 eller 12, karakterisert ved at den videre omfatter et prioritetsdatamiddel for å sette prioritetsdata for å spesifisere i det minste én annen node som skal motta til-standsinf ormas j onen fra klientenheten så snart som mulig.

14. Klientenhet i henhold til et av kravene 11-20, karakterisert ved at nevnte transmisjonsmiddel for å transmittere applikasjonstilstandsinformasjon er tilpasset til å ordne informasjon i applikasjonsobjektpakker, hver pakke er relatert til en objektutgjørende del av applikasjonen, før pakkene transmitteres til applika-sjonsaksesst jenerenheten, og nevnte mottaksmiddel er tilpasset til å trekke ut informasjon om applikasjonsobjekter fra pakker mottatt fra applikasjonsaksesstjenerenheten.

15. Kommunikasjonsnett, karakterisert ved at den omfatter i det minste én tjenerenhet i henhold til et av kravene 1-10.

16. Kommunikasjonsnett i henhold til krav 15, karakterisert ved at den videre omfatter i det minste én klientenhet i henhold til et av kravene 11-14 .

17. Kommunikasjonsnett i henhold til et av kravene 15-16, karakterisert ved at den videre omfatter i det minste en andre applikasjonsaksesstjener og koblingsmiddel som kobler sammen nevnte første og andre applika-sjonsaksesst jenere, hvori kommunikasjonsressurser kan være reservert på nevnte koblingsmiddel.

18. Kommunikasjonsnett i henhold til et av kravene 15-17, karakterisert ved at det videre omfatter i det minste en tredje applikasjonsaksesstjener som kommuniserer med nevnte første applikasjonsaksesstjener, men ikke med nevnte andre applikasjonsaksesstjener, på en slik måte at et hierarki av applikasjonsaksesstjenere oppnås i nettet.

19. Kommunikasjonsnett i henhold til et av kravene 15-18, karakterisert ved at det videre omfatter i det minste én lokasjonsadministrator tilpasset til å kontrollere i det minste én applikasjonsaksesstjener.

20. Kommunikasjonsnett i henhold til krav 19, karakterisert ved at den består av en lobbyaksestjener tilpasset til å bidra med et grensesnitt mellom i det minste en applikasjonslobbytjener og nevnte i det minste én lokasjonsadministrator.