SE521442C2 - Server för att möjliggöra kommunikation mellan klientenheter genom att köra en distribuerad tillämpning vars tillstånd kan ändras av klientenheterna - Google Patents

Description

20 25 30 ; . , = , . , _. a .eo a: 521 442 2 Uppringda nät använder typiskt sett klient-server-synkronisering. I detta fall är den centrala servern en uppenbar flaskhals i systemet. Centrala klient-server-spel kan ha 2-25 0 spelare. Det högre antalet gäller för servrar där uppdateringshastigheten är så låg som 2Hz. Servem mottar data från alla spelare. Den måste ta reda på vilken in- formation varje spelare behöver och skicka den. Den centrala servern medför la- tenstid både på grund av det ökade avståndet och på grund av fördröjning som orsa- kas av databehandling och köordningen i servern. Antag t.ex. en situation där kli- enterna beflnner sig på USA:s västkust medan servern finns på USA:s ostkust. Cirka 80ms fördröjning på grund av avstånd och flera tiotals millisekunder på grund av databehandling orsakas av klient-server-synkroniseringen.

Klient-server-synkronisering är därför inte lämplig för realtidstillämpningar med ett stort antal spelare där fördröjningen är viktig.

Synkronisering mellan jämlika element innebär att alla klienter skickar tillämp- ningsdata direkt till alla andra klienter. Denna modell används ofta för spel som spelas över det publika Intemet. Spelutvecklare tillhandahåller en gratis tillämp- ningslobbyserver ”application lobby server” där spelare möts för att sätta upp spel och för att gå med i pågående spel. När ett spel har startat spelas det med synkroni- sering mellan jämlika element utan att några resurser från spelutvecklaren server används.

Synkronisering mellan jämlika element har uppenbara problem med ökande storlek eftersom belastningen i nätet är proportionell med kvadraten av antalet spelare.

Bandbredden för klientåtkomst och kapacitetskrav för CPU är proportionell med antalet spelare. Nyttolasten i varje paket är 10-40 bytes vilket innebär att protokol- lets administrativa tilläggsinforrnation (overhead) vanligtvis är högre än 50%. Små spelpaket ger mer tilläggsinforrnation. Med kompressionsmetoder kan den administ- rativa tilläggsinformationen reduceras betydligt. 10 15 20 25 521 442 3 Spel med synkronisering mellan jämlika element drabbas av oförutsägbara fördröj- ningar och kollapsar ofta på grund av att synkroniseringen tappas.

Synkroniseríng mellan jämlika element lämpar sig därför bäst för små nät, med kommunikation över relativt korta avstånd och mellan ett begränsat antal användare.

På grund av restriktionerna som bl.a. synkroniseringsmetoderna medför är kommu- nikation mellan flera deltagare med goda realtidsegenskaper inte möjlig med nuva- rande teknik.

Uppfinningens syfte Det är ett syfte med den föreliggande uppfinningen att förbättra realtidsegenskaper- na i kommunikationsnät, i synnerhet för kommunikation i samverkan mellan ett stort antal deltagare.

Sammanfattning av uppfinningstanken Detta syfte uppnås enligt uppfinningen genom en serverenhet anslutningsbar till åt- minstone en första och en andra klientenhet och anordnad att möjliggöra kommuni- kation mellan den första och den andra klientenheten genom serverenheten för att köra en distribuerad tillämpning vars tillstånd kan ändras både av den första och den andra klienten, vilken serverenhet är kännetecknad av att den innefattar: första mottagarorgan för att motta tillståndsinformation avseende tillämpningens tillstånd från åtminstone den första klienten, tillståndslagringsorgan för att spara tillståndsinformationen andra mottagarorgan för att motta prioritetsinformation från åtininstone den första klienten, avseende tillståndsinformation som skall sändas till den första klienten, prioritetslagringsorgan för att lagra den mottagna prioritetsinformationen, 10 15 20 25 30 521 442 4 första sändarorgan samverkande med tillståndslagringsorganet och prioritetslag- ringsorganet för att sända tillståndsinformation till den första klienten i beroende av prioritetsinformationen.

Detta möjliggör att hela tillståndet för tillämpningen kan lagras i en eller flera en- heter i nätet, vilket tar bort behovet för varje klient att spara hela tillståndet och därigenom reducerar behovet för minneskapacitet hos varje klient och även band- bredden som behövs för kommunikation med varje klient. Om varje del av tillämp- ningens tillstånd lagras i mer än en nod eller klient i nätet uppnås en back-up- funktion. Hanteringen av prioritetsinformationen reducerar mängden information som skall sändas till varje användare, vilket minskar överföringsfördröjningen och även hjälper varje användare att analysera informationen, eftersom endast den vikti- gaste informationen för en viss användare visas för användaren. Varje klient kan be- stämma för egen del vad som är viktigt.

Syftet uppnås också enligt uppfinningen genom en klientenhet, anslutningsbar till en tillämpningsserverenhet vilken tillämpningsserverenhet är anordnad att lagra och exekvera en distribuerad interaktiv klienttillämpningsmjukvara anpassad för distribuerad interaktiv tillämpning, innefattande: inmatningsmedel vilka samverkar med klienttillämpningsmjukvaran; överföringsmedel för att sända tillämpningstillståndsinformation till serverenheten, mottagningsorgan för att mottaga tillämpningstillståndsinformation från tillämpningsserverenheten och en behandlingsenhet för att beräkna, kännetecknad av att: för att möjliggöra för åtminstone två klientenheter att samtidigt påverka och bidraga till tillämpningens tillstånd: inmatningsmedlen är anordnade att mata in åtminstone ti1lämpningstillståndsinformation från tillämpningsserverenheten för den distribuerade interaktiva tillämpningen, och behandlingsenheten är anordnad att beräkna ett andra tillstånd för tillämpningsmjukvaran från 10 15 20 25 30 521 442 5 tillämpningstillståndsinformationen som mottagits från tillämpningsserverenheten, varvid det andra tillståndet används för att påverka exekveringen av klienttillämpningsmjukvaran.

F örfarandet och anordningen enligt uppfinningen är speciellt användbara for distri- buerade interaktiva tillämpningar, i synnerhet sådana som innebär realtidskommuni- kation.

Enligt en föredragen utföringsform innefattar klientenheten vidare prioritetsorgan for att sätta prioritetsinformation för att specificera åtminstone ett objekt i den dis- tribuerade interaktiva tillämpningen från vilket tillgänglig information skall mottas så snart som möjligt och organ för att sända prioritetsinformationen till tillämp- ningsservern.

I en fóredragen utforingsform är mottagarorganet anordnat att motta viktighetsin- formation avseende den forsta klienten från åtminstone en andra klient. Viktighets- informationen kan sändas till den första klienten, eller tillstândsinformation avseen- de den andra klienten kan sändas till åtminstone den forsta klienten i beroende av viktighetsinformationen. Viktighetsinformationen kan också användas för att ange att viss tillståndsinformation inte skall sändas till den första klienten. Viktighetsin- formationen kan användas för att ändra en prioritetslista for klienter.

I nämnda föredragna utföringsform innefattar klientenheten vidare organ för att sätta viktighetsdata för att specificera åtminstone en annan klient som skall motta tillståndsinformation från klienten så snart som möjligt.

Det är fördelaktigt om sändarorganet i klientenheten för att sända tillståndsinforma- tion är anordnat att arrangera information i objektinformationspaket, varvid varje paket avser ett objekt som utgör en del av tillämpningen, innan paketen sänds till serverenheten, och mottagarorganet är anordnat att extrahera information från paket 10 15 20 25 521 442 6 som mottas från serverenheten. Tillämpningsservern är oberoende av tillämpningen och kan därför stödja ett brett spektrum av olika tillämpningar.

Tillämpningsserverenheter som arbetar tillsammans kan kommunicera över ett re- serverat (virtuellt) nät. Det totala bandbreddskravet för en tillämpning kan uppskat- tas av näthanteringssystemet och tillräckliga nätresurser kan tilldelas till det reserve- rade nätet som kopplar samman tillämpningsenheterna. Nya tillämpningar tillåts en- dast om det finns tillgängliga resurser. Näthanteringssystemet styr också strategier for omsändning och duplicering för tillämpningsserverenhetema. Multicasting och resursreserveringsprotokol1 kan användas på den sammantagna trafiken mellan till- lämpningsserverenheter. Fördelen med detta system är att resursreservering på spe- larnivå inte behövs. Tillämpningsklienter kan vanligtvis hantera ett och annat tappat paket om övergripande prestanda är bra. Med användning av tillämpningsservern enligt uppfinningen tappar en klient aldrig synkroniseringen permanent, eftersom tillämpningsserverenheterna alltid upprätthåller spelets tillstånd.

Kortfattad beskrivning av ritningarna Anordningen och förfarandet enligt uppfinningen kommer att beskrivas mer i detalj i det följande, med hänvisning till ritningarna, på vilka: Figur 1 visar en utföringsform av ett nät enligt uppfinningen; Figur 2 visar en tillämpningsserver enligt en utföringsforin av uppfinningen; Figur 3 visar en utforingsform av en tillståndspost enligt uppfinningen; Figur 4 visar en tillämpningsklient enligt en utföringsfomi av uppfinningen; Figur 5 visar kominunikationsstackar som används enligt en utföringsform av upp- finningen; Figur 6 är en schematisk bild av en hierarkisk struktur av tillämpningsservrar som används i en utföringsform av uppfinningen.

Detaljerad beskrivning av utfóringsformer 10 15 20 30 521 442 7 Figur 1 visar en utföringsform av ett kommunikationsnät enligt uppfinningen. Enligt uppfinningen innefattar nätet åtminstone en tillämpningsserver. I figur 1 visas en första 1, en andra 3 och en tredje 5 tillämpningsserver, sammankopplade genom ett nät 7, t.ex. ett reserverat telekommunikationsnät. Det kan också vara en annan typ av nät, men nät i vilka det inte är möjligt att reservera nätresurser, såsom Internet, är mindre lämpade. Ett antal klienter 11, 12, 13, 14, 15 är också anslutna till nätet 7.

En klient kan ansluta sig till lämplig tillämpningsserver 1, 2 eller 3, på vilket som helst känt sätt, såsom kommer att diskuteras i mer detalj i det följande.

Klienter kommunicerar med varandra genom tillståndsservrar i syfte att köra en distribuerad interaktiv tillämpning, vari ett stort antal deltagare samtidigt påverkar och bidrar till tillämpningens tillstånd, t.ex. ett fleranvändarspel i realtid. Mellan varje klient och tillämpningsservem till vilken den är ansluten finns vanligtvisen förbindelse med låg kapacitet, såsom en modemförbindelse. Mellan två tillämp- ningsservrar, å andra sidan, kommer förbindelser med hög och variabel kapacitet att finnas. Tillämpningsservem enligt uppfinningen är därför anordnad att hantera in- formationen om tillämpningens tillstånd på ett sådant sätt att mängden information som sänds till varje klient reduceras, genom att sända till varje klient endast den in- formationen som är mest relevant för klienten. Mellan tillämpningsservrama är överföringskapaciteten vanligtvis inte något problem, därför kan mer information sändas mellan tillämpningsservrama.

En eller flera tillämpningslobbyservrar 21 av känd typ, kan också finnas i nätet.

Dessa servrar innefattar typiskt sett funktioner som tillåter klienterna att registrera sig för en viss typ av tjänst, hantera debiteringsfunktioner, osv.

Enligt uppfinningen finns mjukvaran som behövs för tillämpningen i klienten ll, 12. 13, 14, 15. För att använda kommunikationsfimktionerna enligt uppfinningen måste användaren därför säkerställa att han har den nödvändiga tillämpningsmjuk- varan. Tillämpningsmjukvaran kan hämtas på vilket som helst känt sätt, t.ex. laddas 10 15 20 25 30 521 442 8 ner från Intemet eller installeras från CD-ROM. Om det behövs för tillämpningen måste han också registrera sig med lobbyservem. Typiskt sett tillhandahåller lobby- servem 21 en adress, vanligtvis en IP-adress till en eller flera tillämpningsservrar 1, 3, 5, men denna adress kan också erhållas på annat sätt.

Användaren ansluter sig till en tillämpningsserver på känt sätt, vanligtvis genom att mata in IP-adressen till tillämpningsservern eller en grupp av tillämpningsservrar.

Flera algoritmer finns för att välja den lämpliga av ett antal noder i nätet som identi- fieras av samma adress. Tillämpningsservem mottar information från användaren och börjar sända information till användaren, såsom kommer att beskrivas i mer detalj i det följande. I stället för att klienten loggar in på tillämpningsservern kan lobbyservem också sända klienters nätadresser till tillämpningsservrar.

Tillämpningen antas bestå av en uppsättning objekt som styrs av deltagarna. Ett ob- jekt är en enhet i tillämpningen som styrs av en mänsklig deltagare eller som på an- nat sätt inte kan alstras lokalt i varje tillämpningsklient. Tillämpningsobjekt kan vara saker som deltagama intuitivt känner igen såsom objekt eller spelfigurer men de kan också vara bakgrundsdatastrukturer såsom omgivningsvariabler som styrs av spelama. Ett tillämpningsobjekt styrs av en eller flera spelare. Varje objekt har ty- piskt en uppsättning egenskaper och attribut som kan ändras medan tillämpningen körs. I ett spel kan dessa egenskaper vara en ñgurs styrka och andra förmågor, eller en bils maxhastighet, och attributena kan vara, t.ex. saker som samlas av figuren.

Informationen som mottas från användaren kommer vanligtvis att innefatta tre olika typer av information utöver administrativ tilläggsinformation: tillståndsinformation, prioritetsinfonnation och viktighetsinformation. Tillståndsinformationen är infor- mation om objektet eller objekten som styrs av användaren och som skall sändas till andra användare av tillämpningen. Prioritetsinformationen anger klientens priorite- ringar avseende olika tillämpningsobjekt som tillhandahålls av tillämpningsservrar- na. Till exempel skall information från en viss grupp av andra användare mottas på 10 15 20 521 442 9 en gång, eller så ofta som möjligt, medan information från en annan grupp av an- vändare inte är så brådskande. Flera prioritetsnivåer kan sättas, t.ex. i form av ac- ceptabel fördröjning. Viktighetsinfonnationen som alstras av en klient kan användas för att överpröva eller ändra en annan klients prioritetslista så att den andra klienten kommer att motta information om objekt som inte finns på dess prioritetslista, eller för att säkerställa att klienten inte mottar viss information. Alla tre typer av infor- mation kommer att diskuteras i mer detalj i det följande.

Såsom ett exempel kommer en tillämpning av ett realtidsspel som spelas av ett stort antal användare att beskrivas. Sådana spel spelas i dag med ett begränsat antal spela- re som finns relativt nära varandra, t.ex. i ett lokalt nät (Local Area Network - LAN). När det spelas över ett globalt nät (Wide Area Network - WAN) kan ett så- dant spel i framtiden omfatta flera tusen spelare, typiskt sett fördelade över en stor spelplan eller virtuellt geografiskt område. Med känd teknik är detta inte möjligt med acceptabel kvalitet, såsom diskuterat ovan.

Varje spelare berörs omedelbart av de saker som händer nära honom. Ju längre bort en annan spelare är ju mindre viktiga är ändringar avseende denna spelare. Till ex- empel kan en spelare vara involverad i en kamp med en första fientlig spelare, en vänligsinnad spelare kan komma till undsättning och en andra fientlig spelare kan försöka stoppa den vänligsinnade spelaren. Samtidigt kommer andra spelare att göra saker som kan komma att bli intressanta senare, men för tillfället är spelarens hu- vudproblem att överleva kampen. Därför måste den första fientli ga spelarens rörel- ser visas omedelbart. Den vänligsinnade spelarens och den andra fientliga spelarens rörelser bör också ges hög prioritet. medan saker som händer längre bort bör ges lägre prioritet.

I det ovan diskuterade exemplet kommer givetvis konfigurationen av spelare att ändras så att vid en annan tidpunkt kommer information från andra spelare att ha 10 15 25 30 521 442 10 högst prioritet, vanligtvis användama som befinner sig närmast användaren vid en given tidpunkt.

Tillämpningsservern har också en klientbehörighetslista. Varje klient har rätt att ändra tillståndet för en uppsättning spelobjekt. Klientbehörighetslistan har en post för varje klient där numren på de objekt som styrs av klientema lagras. Tillämp- ningsservern kontrollerar behörighetema varje gån g den mottar objekttillståndsin- formation från en klient. Speltillståndet kommer att uppdateras endast om en identi- ' fierare som finns i informationspaketet överensstämmer med ett av numren i klien- tens post i behörighetslistan, i annat fall ignoreras informationen. Objekttillståndsin- formation som kommer från andra tillämpningsserverenheter verifieras inte, efter- som tillämpningsservern som sände ut denna information redan har kontrollerat be- hörigheterna.

Tillämpningsservem hanterar kommunikation med tillämpningsklienter. Den mottar information om varje klients handlingar som påverkar tillämpningens tillstånd och annan information. Den sänder också tillståndsinformation från andra deltagare till deltagare enligt deras prioriteringar. Varje tillämpningsklient sätter prioriteringar avseende vilken tillämpningsinformation som skall mottas och sänder ut inforrna- tion om dessa prioriteringar till tillämpningsservem. Tillämpningsservern lagrar och uppdaterar en post med prioriteringar för klienterna som är anslutna till tillämp- ningsservem. Varje klients prioriteringar används för att bestämma vilka data som skall sändas till denna klient.

Varje tillämpningsserver kommunicerar också med andra tillämpningsserverenheter, och sänder ti1lämpningstillståndsinfonnation och sammanställda prioriteringar till dem och mottar samma typ av information från dem. Sammanställda prioriteringar är summan av alla önskemål om tillämpningsobjekt från klienter som tillhör en viss tillämpningsserver. Till exempel kan tillämpningsservem använda multicast till andra tillämpningsserverenheter. Detta säkerställer att varje tillämpningsserverenhet 10 15 20 25 30 521 442 ll mottar alla nödvändiga uppdateringar och att speltillståndet distribueras effektivt över tillämpningsserverenheterna.

Vanligtvis paketeras informationen som skall sändas till de andra tillämpningsserv- rama enligt ett lämpligt protokoll och sänds utan att prioriteras eller sorteras på nå- got sätt. Det skulle givetvis vara möjligt att välja ut infonnationen som skall sändas till varje tillämpningsserver i beroende av användarnas prioriteringar.

Tillämpningsservem lagrar och uppdaterar också en komplett kopia eller delkopia av tillämpningstillståndet. Tillämpningsserverenhetema som tilldelats till en till- lämpning måste tillsammans lagra hela tillämpningstillståndet. I det enklaste fallet lagrar varje tillämpningsserver hela tillämpningstillståndet, men det är också möjligt att dela upp informationen mellan tillämpningsservrama, med eller utan överlap- pande information. Sådana lösningar kräver speciell mjukvara for att hantera fördel- ningen av den aktuella mjukvaran till varje tillämpningsserver.

Tillämpningsservem kommunicerar med lobbyservem for att sätta upp tillämpning- en, lägga till och ta bort deltagare medan tillämpningen körs och hantera fel och problem i nätet.

Tillämpningsservem hanterar också kommunikationsprotokoll, tex. Intemet Proto- col (IP), och utväxlar uppdateringar av tillämpningstillståndet med andra tillämp- ningsserverenheter.

Figur 2 visar en tillämpningsserver enligt en utforingsforrn av uppfinningen, med dess funktionella enheter. Denna tillämpningsserver kan realiseras i hårdvara eller mjukvara. I anslutning till figur 2 Ges endast en allmän beskrivning. Lämpliga for- mat och protokoll kommer att diskuteras senare.

Tillämpningsservem mottar data från varje klient i nätet. och från andra enheter, så- som andra tillämpningsservers, genom ingângsbuffertar 5 l. Det finns en ingångs- 10 15 20 25 30 521 442 12 buffert för varje klient, varje annan tillämpningsserver och lobbyserver, även om endast en ingångsbuffert visas i figur 2, för översiktlighetens skull.

Data som mottas från klienterna kan innefatta tre typer av data: Tillståndsdata avse- ende tillämpningens tillstånd, data avseende klientens prioriteringar och annan styrinformation. Tillståndsdatat passerar genom en tillståndsobjektpaketförbindelse 5 3ltill en tillståndspost 55. Tillståndsposten 55 innehåller alla tillståndsdata för alla relevanta objekt, såsom kommer att beskrivas i mer detalj nedan. Tillståndsposten har också information om viktigheten av tillståndsdata för varje klient. Viktighets- data sätts av en klient om data är viktiga för en annan klient, men denna andra klient inte vet om detta och därför inte kan sätta sina egna prioriteringar. Viktigheten be- stäms därför av den sändande klienten och kan vara olika för olika mottagande kli- enter. Tillämpningsservem informerar den mottagande klienten om vikti ga, eller brådskande, data väntar. Viktighetsinforrnationen kan också användas för att förbju- da att viss information sänds till en eller flera klienter.

Grupper av klienter kan definieras, varvid en grupp till exempel innefattar deltagar- na i en arbetsgrupp, eller i fallet med ett spel, i samma lag. I detta fall kan prioritets- data och/eller viktighetsdata också specificeras för grupper av användare, inte bara för individuella användare.

Styrdata, i synnerhet data som inte behöver hanteras i realtid, såsom information av- seende tillagda eller borttagna tillämpningsobjekt, sänds från ingångsbufferten 51 till tillämpningsserverns styrenhet 57. I en hårdvarurealisering kan styrenheten 57 vara en mikroprocessor. Styrdata som hanteras av styrenheten kan avse exempelvis skapande och lörstörande av spelare och objekt, och grupper av spelare och objekt.

Prioritetsdata sänds genom en rörledning (pipeline) 59 för tillämpningsprioritets- styrprotokollmeddelanden till en klientprioritetslista (Client Priority List - CPL) 61 vilken innehåller prioriteringama för varje klient som betjänas av tillämpningsser- 10 15 20 30 521 442 13 vem. Prioritetslistan sparas i klientprioritetslistan 61 och kan uppdateras av klien- terna och av tillämpningsservems styrenhet. Styrenheten kan t.ex. bestämma att pri- oritetslistan för en klient skall uppdateras på grund av ett viktighetsmeddelande som mottagits från en annan klient.

Varje klient styr vilken information den skall motta genom att sända prioritetsmed- delanden till tillämpningsservem. Flera olika prioriteringsstrategier kan tillämpas av tillämpningsklienterna när tillämpningsserversystemet används. En enkel metod är att tillämpningsklienter sänder en numrerad lista på objekt till klientprioriteringslis- tan 61. Om alla objekt i listan har uppdaterats kan de kvarvarande objekten uppdate- ras, t.ex. i ordningsföljd, så kallad ”round robin”. Prioritetslistan för en viss klient innefattar en lista på alla objekt för vilka en prioritet har satts av denna klient. Där- utöver innefattar listan i tillämpningsservem företrädesvis en flagga för varje objekt vilken anger om ny information för objektet har mottagits. Flaggan används för att bestämma huruvida information om ett visst objekt behöver sändas till klienten. När information har sänts till klienten återställs flaggan. När en ny uppdatering för ett objekt mottas av tillämpningsservem sätts flaggan igen.

Klientprioriteringarna kan också definieras med ett tidsintervall för varje objekt.

Klienten skulle då sända en serie önskemål, exempelvis på formatet mer>, , , <flaggor>. En enkel lista kan helt enkelt ha formatet , . Tillämpnings- servern kommer att försöka sända uppdateringar till klienten så att varje objekt upp- dateras åtminstone en gång under varje tidsintervall med prioritet som angiven i

Claims (17)

10 15 20 25 34 Patentkrav

1. Serverenhet anslutningsbar till åtminstone en första och en andra klientenhet (l l,l2,l3, 14,15) och anordnad att möjliggöra kommunikation mellan den första och den andra klientenheten genom serverenheten för att köra en distribuerad tillämp- ning vars tillstånd kan ändras både av den första och den andra klienten, vilken serverenhet är kännetecknad av att den innefattar: första mottagarorgan (51, 53) för att motta tillståndsinformation avseende tillämp- ningens tillstånd från åtminstone den första klienten, tillståndslagringsorgan (55) för att spara tillståndsinforrnationen andra mottagarorgan (59) för att motta prioritetsinforrnation från åtminstone den första klienten, avseende tillståndsinformation som skall sändas till den första kli- enten, prioritetslagringsorgan (61) för att lagra den mottagna prioritetsinformationen, första sändarorgan (63, 65) samverkande med tillståndslagringsorganet och priori- tetslagringsorganet för att sända tillståndsinforrnation till den första klienten i bero- ende av priorítetsinfonnationen.

2. Serverenhet enligt krav 1, vidare innefattande andra sändarorgan (63, 65) för att sända tillståndsinformation och/eller prioritetsinformation mottagen från åtminstone den första klienten till åtminstone en annan serverenhet.

3. Serverenhet enligt något av föregående krav, varvid tillståndsinformationslag- ringsorganet är anordnat att lagra tillståndsinformation för tillämpningen i terrner av egenskaper för objekt, vilka obj ekts tillstånd sammantaget utgör tillämpningens till- stånd. 10 l5 20 25 30 en in n i n ._ _ i f= T, r I I .. ,-.« | v, ,- _ á - 1. ¿. _ ,( ' ' 'b - _ - i , , ~ v in a . , N"h' -V n , 35

4. Serverenhet enligt krav 3, varvid tillståndsinformationslagringsorganet är anord- nat att lagra grundpaket (AOPl1) eller datagram som beskriver hela tillståndet för ett objekt vid en viss tidpunkt.

5. Serverenhet enligt krav 4, varvid tillståndsinforrnationslagringsorganet är anord- nat att lagra inkrementella paket (AOPl2, AOP13) vilka beskriver ändringen av objektets tillstånd sedan ett visst tidigare paket och information som identifierar det tidigare paketet.

6. Serverenhet enligt något av föregående krav, varvid det andra mottagarorganet (55) är anordnat att motta viktighetsdata från åtminstone den andra klienten, avse- ende tillståndsinforrnation som skall sändas till den första klienten, och det första sändarorganet (63, 65) är anordnat att sända tillståndsinfonnation till den första kli- enten i beroende av viktighetsinfonnationen.

7. Serverenhet enligt något av föregående krav, vidare innefattande registreringsor- gan för att registrera behörighetsinforrnation för den åtminstone ena första noden, vilken behörighetsinformation anger vilka tillämpningsobjekt den första noden är behörig att ändra.

8. Serverenhet enligt något av föregående krav, varvid tillståndsinformationslag- ringsorganet är anordnat att slänga bort lagrad tillståndsinformation efter en för- handsbestämd tidsperiod.

9. En klientenhet, anslutningsbar till en tillämpningsserverenhet (1, 3, 5) vilken tillämpningsserverenhet är anordnad att lagra och exekvera en distribuerad interaktiv klienttillämpningsmjukvara anpassad för distribuerad interaktiv tillämpning, innefattande: inmatningsmedel (lll, ll3, ll5, 101) vilka samverkar med klienttillämpningsmjukvaran; överföringsmedel (105, 107) för att sända 10 15 20 25 30 VÛÅ1ÛOQ tlip; 5 1 :::::«¿«:m._e- _ _: . .. :- 36 tillämpningstillståndsinformation till serverenheten, mottagningsorgan (105, 107) för att mottaga tillämpningstillståndsinforrnation från tillämpningsserverenheten och en behandlingsenhet för att beräkna, kännetecknad av att: för att möjliggöra för åtminstone två klientenheter att samtidigt påverka och bidraga till tillämpningens tillstånd: inmatningsmedlen (111, 113, 115, 101) är anordnade att mata in åtminstone tillämpningstillståndsinforrnation från tillämpningsserverenheten (1, 3, 5) för den distribuerade interaktiva tillämpningen, och behandlingsenheten (101) är anordnad att beräkna ett andra tillstånd för tillämpningsmjukvaran från ti1lämpningstillståndsinformationen som mottagits från tillämpningsserverenheten, varvid det andra tillståndet används för att påverka exekveringen av klienttillämpningsmjukvaran.

10. Klientenhet enligt krav 9, vidare innefattande prioritetsorgan (101) för att alstra prioritetsinformation avseende tillståndsinformation som skall sändas till den första klientenheten från tillståndsserverenheten.

11. Klientenhet enligt krav 9 eller 10, vidare innefattande viktighetsdataorgan (101) för at sätta viktighetsdata för att specificera åtminstone en annan nod som skall motta tillståndsinformation från klienten så snart som möjligt.

12. Klientenhet enligt något av kraven 9-1 1, varvid sändarorganet för att sända till- ståndsinforrnation är anordnat att ordna informationen i tillståndsobjektpaket, där varje paket avser ett objekt som utgör en del av tillämpningen, innan paketen sänds till tillämpningsservern och mottagarorganet är anordnat att extrahera information om tillämpningsobj ekt från paket mottagna från tillämpningsservem.

13. Kommunikationsnät kännetecknat av att det innefattar åtminstone en serveren- het (l, 3, 5) enligt något av kraven l-8. 10 15 521 442ï:?'@¥1 37

14. Kommunikationsnät enligt krav 13, vidare innefattande åtminstone en klienten- het (11,12,13,14,15) enligt något av kraven 11-14 ansluten till serverenheten.

15. Kommunikationsnät enligt kraven 12-14, vidare innefattande åtminstone en lob- byserver.

16. Kommunikationsnät enligt något av kraven 12-15, vidare innefattande åtminsto- ne en andra serverenhet och anslutningsorgan som förbinder den forsta och den andra serverenheten med varandra, varvid kommunikationsresurser kan reserveras på anslutningsorganet.

17. Kommunikationsnät enligt något av kraven 12-16, vidare innefattande en tredje tillämpningsserver, vilken kommunicerar med den andra tillämpningsservern, men inte med den andra tillämpningsservem, på ett sådant sätt att en hierarki av tillämp- ningsservrar uppstår i nätet.