Den här sidans innehåll är bevakat av både Steam Support och Steam-användarsamhället - alla länkar till externa sidor bör behandlas med försiktighet.
Steam Support kommer aldrig av någon anledning att begära ditt Steam-kontos lösenord, inte heller kommer du någonsin att bli ombedd att mata in ditt lösenord på någon webbsida.
Detta är en kort beskrivning av hur servrar och klienter interagerar, FPS, ping- (FPS) boosters och hur alla delarna arbetar ihop.
Motorn
Half-Life Multiplayer Game Engine är sammansatt av en server och en eller flera klienter upp till maximalt 32 som kommunicerar interaktivt, delvis i realtid över Internet. Kommunikation mellan servern och klienterna använder sig av UDP-protokollet som är väldigt lämpligt för denna typ av kommunikation (mer om TCP/UDP senare).
Servern är en renderingsmaskin utan någon grafik. Klienten är en rederingsmaskin med grafiska och akustiska undersystem som även interagerar med spelaren via ett tangentbord, en mus, joystick eller vad spelaren nu använder.
I normala fall körs servern på en förinställd renderingscykel på 100FPS (Frames Per Second, bildrutor per sekund) eller 10 ms per ruta. Med olika avsiktliga och tillfälliga innovationer tillgängliga kan servern köras med mycket kortare cykler, upp till maximalt 1000FPS. Det finns några begränsningar i hårdvaran och operativsystemet för hur hög FPS en server kan uppnå.
Att köra servern i 500FPS eller 1000FPS har ingen direkt påverkan på klientdatorernas FPS, varje dator renderar rutor självständigt.
Serverns FPS-takt ställs in med hjälp av CVAR-kommandot sys_ticrate (min 0, max 1000).
Om datorn som servern körs på är kraftfull nog, och man kör den i en högre FPS (upp till den maximala inställningen 1000), så kommer det att leda till flera fördelaktiga saker. Låt oss ta en titt på vad som händer här och varför det händer.
Servern kör en bana, cachar resurser, renderar rutor, tar emot statusuppdateringar från klienterna och skickar ut uppdateringar till klienterna.
Klienten kör samma bana (kontrollsummorna måste stämma överens), renderar dess egna rutor, skickar och tar emot uppdateringar från servern. Klienten visar även rutorna grafiskt och akustiskt (det gör inte servern) och arbetar interaktivt med spelaren.
Dessutom renderar klienten alla animationer och positioner för modeller, sprites, ljud, animerade texturer (såsom vatten) och rörliga enheter inom spelarens synfält. Detta inkluderar vapen och avfyrade skott.
Servern håller reda på alla dessa saker men behöver inte rendera någonting för dom, bara uppdatera klienten om lägesförändringar och händelser.
Så vi ser att det i själva verket finns två olika och självständiga (men ändå av varandra beroende) renderingssystem som kommunicerar fram och tillbaka.
Låt oss säga att Servern renderar rutor i 500FPS. Det betyder att en bild av allt som händer finns tillgänglig att skicka till klienten varannan millisekund (1000FPS är varje millisekund).
Klienten interagerar i själva verket med servern på två olika sätt. Klienten skickar uppdateringar av klientens position och handlingar 30 gånger per sekund (cl_cmdrate är som standard 30) och skickar en begäran om en fullständig uppdatering från servern 20 gånger per sekund (cl_updaterate är som standard 20). Vi ignorerar cl_cmdrate-kommandot tillsvidare då det inte kräver ett svar från servern.
Så med en cl_updaterate på 20 innebär det att ungefär var 50:e ms kommer klienten att begära en uppdatering från servern. Vi lägger sedan till restiden (1/2 ping) från klient till server och sedan är det (med servern som renderar vid 500FPS) som mest en fördröjning på 2 ms innan den uppdateringen renderas och skickas tillbaka till klienten med ytterligare 1/2 pings fördröjning.
Vid 100FPS är det en maximal fördröjning på 10 ms för att detta skall hända.
Då alla klienter renderar och begär uppdateringar självständigt, kommer varje klient att slumpmässigt (gentemot varandra) skicka dessa uppdateringar till servern, så se på det här som en "storm" av uppdateringsförfrågningar som alla kommer fram vid olika tider till servern.
Takten i vilken dessa uppdateringar skickas fram och tillbaka kontrolleras av CVAR-kommandot "rate" på klientsidan (0 till maximalt 20000) och av kommandona sv_minrate och sv_maxrate på serversidan. Serversidans inställningar är tak för allt som klienten ställer in. Rate (takt) mäts i bytes per sekund. Med en rate av 7500 skickar en spelare och tar emot i genomsnitt 7,5Kbyte per sekund till/från servern.
Om servern körs i 100FPS så är det en period på 10 ms under vilken dessa förfrågningar ackumuleras medan servern renderar datan och sedan skickar ut uppdateringarna till alla klienter i den nuvarande kön. Om servern klarar av att rendera den nuvarande rutan innan slutet på sys_ticrate-intervallet så vilar den i praktiken resten av tiden.
Detta betyder att om det är många klienter så kommer servern behöva skicka ut en stor ström av data var 10:e ms, vilket kan lägga stor press på serverupkopplingen.
Om servern körs i 1000FPS så kommer servern i själva verket, så fort en klient skickar in en uppdateringsbegäran, kunna leverera uppdateringen för just den klienten nästa omedelbart, vilket resulterar i många mindre, mer jämnt fördelade strömmar av data genom serveruppkopplingen (det totala genomsnittet är dock detsamma).
Detta gör i själva verket tre saker, det minskar kravet på uppkopplingen (så du kan ha mindre stockning), det sänker något det relativa ping-tillägget som varje klient ser (från 10 ms till 1 eller 2 ms) och viktigast av allt, det håller klienterna något mer uppdaterade om vad som händer, vilket förbättrar nogrannheten och minskar nätverksfördröjningar (lagg).
(OBS: servern kan i själva verket skicka ut den nuvarande förrenderade rutan så fort som den tar emot en förfrågan från klienten och inte vänta på nästa ruta. Jag har inte kunnat verifiera detta på något sätt annat än genom min erfarenhet, och sättet som jag beskriver det på är så som det ser ut att bete sig funktionellt).
Så som slutsats:
- Servern renderar rutor i 100, 500 eller 1000FPS, uppdateringar är tillgängliga var 10:e ms, varannan ms eller varje ms. Klienter renderar rutor vid (som standard) 100FPS och visar rutor vid (vanligen) 30 till 100 FPS, beroende på processor och grafikhårdvara som de har och på vad som händer på kartan.
- Klienter skickar uppdateringsinformation (cl_cmdrate, korr. av övers.) till servern (som standard) 30 gånger per sekund.
- Klienter begär uppdateringar från servern (cl_updaterate, korr. av övers.) (som standard) 20 gånger per sekund (vilket är 50 ms mellan uppdateringar). Servern skickar ut uppdateringsinformation till klienten. Under det 50 ms-intervallet (och pingrestiden), renderar klienten synliga rutor, förutspår händelser och interagerar med spelaren tills uppdateringen tas emot.
- Klienter skickar data till servern och servern skickar data till klienten med samma takt som är inställd med klientsidans CVAR-kommando rate, begränsad av Serverns CVAR-kommando sv_maxrate.
- Servrar som kör med en högre FPS kommer att kunna skicka uppdateringsinformation till klienten tidigare och något minska stockningen på serveruppkopplingen.
- Klienter kommer att skicka till servern och ta emot från servern samma mängd data oavsett vilken FPS som servern körs vid. Detta antar självklart att servern har resonliga begränsningar satta (sv_maxupdaterate).
- Server CVAR-kommandona sv_maxrate och sv_maxupdaterate sätts omedelbart i kraft, det kan förekomma en liten fördröjning innan ändringarna syns (om det finns någon som helst effekt som kan ses).
|
