Pro duobus proximis hebdomadibus laboravi in ββinstrumento meo pro ludo. Antea nihil omnino de retis in ludis sciebam, ideo multum lego articulos et multa experimenta feci ad omnes conceptus intelligendas et mea propria networking machina scribere potero.
In hoc duce, varias notiones tecum communicare libet quam discere debes antequam machinam tuam scriberes, ac optimas facultates et vasa addiscendi.
In universum genera duo principalia architecturae retis sunt: ββparis et clientis. In architectura pari ad parem (p2p) data transfertur inter quaelibet paria histrionibus connexa, cum in architectura clientis, notitia tantum inter histriones et ministratorem transfertur.
Quamvis architectura pari-paris adhuc in ludis quibusdam adhibeatur, clientis est vexillum: facilius efficiendum est, minorem latitudinem canalis requirit, faciliusque contra fraudem tueri facit. Ergo in hac consequat versari nos architecturae clientis.
Praesertim maxime interest apud auctores auctoritatis: in huiusmodi systematis semper ius est. Verbi gratia, si histrio putat se esse in coordinatis (10, 5), et dicit ei servo se esse apud (5, 3), tunc clienti locum suum substituere debet cum eo qui a servo relatus est, et non vice. converso. Ministris auctoritative utens faciliorem reddit cheaters cognoscere.
Systemata alearum ludi Network tres principales partes habent:
- Protocollum transportandum: quomodo notitia inter clientes et servitorem transfertur.
- Applicationem protocollo: quod ab clientibus ad servitorem et a servo ad clientes transmittitur et in qua forma.
- Applicatio logicae: quomodo notitia translata adhibetur ad statum clientium et servientium update.
Magni interest ut partes uniuscuiusque partis et provocationes cum eis associatas comprehendant.
Transporto protocol
Primus gradus est eligere protocollum ad notitias transportandas inter servitorem et clientes. Protocolla interretialia duo huic sunt: ΠΈ . Sed tabulam onerariam tuam creare potes quae in uno eorum fundata est, vel bibliotheca ea utitur, quae illis utitur.
Comparatio TCP et UDP
Et TCP et UDP sunt secundum . IP fasciculum e fonte ad recipientem transmitti permittit, sed non spondet missum citius aut serius ad recipientem perventurum, semel saltem perventurum, et in recta serie deveniet ordo. Praeterea, fasciculus non potest continere nisi modicam quantitatem notitiae, a valore datae .
UDP tenui iacuit super IP est. Ergo easdem habet limitationes. E contra, TCP multae notae sunt. Certum et ordinatum nexum inter duos nodos cum errore recognitionem praebet. Hinc TCP valde commodum est et in multis aliis protocollis adhibetur, v.g. , ΠΈ . Sed haec omnia pretio veniunt; .
Ut cur haec munera latency causare possint, opus est intelligere quomodo opera TCP. Cum nodi missio fasciculum ad nodi recipiendum transmittit, expectat ut agnitionem recipiat (ACK). Si post aliquod tempus non recipiat illud (quia amissus est fasciculus vel agnitio vel propter aliam causam), tunc resiudit fasciculum. Praeterea, TCP cautiones sarcinae recipiuntur in recto ordine, donec amissam fasciculum recipiatur, omnes aliae fasciculi discurrere non possunt, etiam si iam ab hospite recepto receptae sunt.
Sed ut probabiliter existimare potes, latency in lusoribus lusoribus magni momenti est, praesertim in generibus agendo refertis sicut FPS. Inde est quod multi ludi UDP cum suo protocollo utuntur.
Protocollum indigena UDP fundatum efficacius esse potest quam TCP ob varias causas. Exempli gratia, notare potest aliquas fasciculas sicut creditas et alias creditas. Ergo non curat an infidelis fasciculus ad recipientem perveniat. Vel potest processus multiplicis notitiae rivorum ita ut amissus fasciculus in uno rivo reliquos rivos non retardet. Exempli gratia, filum pro ludio ludius input et aliud filum pro nuntiis chat. Si nuntius nuntius non necessarius amittitur, initus non retardet quod urget. Vel protocollum proprietatis efficeret fidem aliter quam TCP ut plus efficiens in environment video venatus.
Si ergo TCP tantum sugit, tum onerariam nostram protocollum in UDP creabimus?
Est paulo voluptua. Etiamsi TCP fere suboptimal pro ludum network systemata, potest bene operari pro specifica venatione tua, et te servabit tempus pretiosum. Exempli gratia, latency lis non potest esse pro ludo vel ludo qui in LAN retiacula tantum ludere potest, ubi latency et fasciculus iacturae multo humiliores sunt quam in interreti.
Multi ludi prosperi, in quibus Mundus Warcraft, Minecraft et Terraria, utuntur TCP. Maxime autem FPSs suis UDP-fundatis protocolla utuntur, sic de illis infra plura loquemur.
Si volueris uti TCP, fac debilitatum eo quod buffers prius mittens, id quod auget latency.
Plus discere de differentiis inter UDP et TCP in contextu lusorum ludorum, legere potes articulum Glenn Fiedler. .
sua protocol
Visne igitur tabulam onerariam tuam creare, sed nescis unde incipias? Fortunatus es quod Glenn Fiedler duo mirabilia de hoc articulo scripsit. Multum in eis reperies dolorum cogitationes.
Primus articulus 2008, facilius quam secundum, MMXVI. Tibi commendo ut a seniore incipias.
Nota Glenn Fiedler magnum esse propositum utendi protocollo protocollo in UDP posito. Et perlectis eius articulis, sententiam eius probabiliter adhibebis quod TCP gravia vitia in ludis video, et protocollum tuum efficere voles.
Sed si novus es ad networking, fac tibi gratiam et utere TCP vel bibliothecam. Ad effectum mittendum protocollum tuum exercendum, multum ante discere debes.
Network bibliothecas
Si quid efficacius quam TCP eges, sed per hassle exsequendi protocollum tuum ire non vis et in multam singula iens, bibliotheca retis uti potes. Sunt earum amet;
- Glenn Fiedler
- quae iam non sustinetur, sed bifida Similis etiam activae est.
- Est bibliotheca creatus est in pluribus FPS
- Valvae
Non omnia expertus sum, sed ENet malo quia facile est uti et certa. Praeterea clarum documentum et documentum pro tironibus habet.
Transporto Protocollum: conclusio
Summatim: duo oneraria principalia sunt protocolla: TCP et UDP. TCP multas notas utiles habet: commendatio, fasciculus ordinis conservatio, error deprehensio. UDP non habet haec omnia, sed TCP natura sua latentiam auxit, quod ludis ingratum est. Hoc est, ut latentiam humilem curet, protocollum tuum creare ex UDP vel bibliothecam uti potes, quae protocollum in UDP onerariam instruit et pro lusoribus lusoriis video accommodatus.
Electio inter TCP, UDP et bibliotheca ex pluribus causis pendet. Primo, ex necessitate ludi: an humili latendo eget? Secundo ex applicatione protocolli requisita: nunquid certa protocollo eget? Ut in altera parte videbimus, fieri potest applicationem protocolli ad quod protocollum infidelis satis convenit. Denique etiam experientiam retis machinam elit considerare oportet.
Habeo consilium:
- Protocollum onerariis abtrahe a reliqua applicatione quam maxime ut facile restitui possit sine omni codice rescripto.
- Noli nimis optimize. Si peritus networking non es et certus non es an consuetudo UDP-fundatur in tabulas onerarias, incipere potes cum TCP vel bibliotheca quae fidem praebet, et deinde examinis ac mensurae effectus. Si problemata oriuntur et confidis causam esse protocollum onerariam, tunc tempus erit ad creandum protocollum tuum transportandum.
In fine huius partis commendo ut legas by Brian Hook, which covers many of the topics discuss here.
application protocol
Nunc notitias inter clientes et servitorem commutare possumus, quaenam notitia transferendi et qua forma sit diiudicare oportet.
Ordo ordo est ut clientes input vel actiones mittant servo, et minister statum hodiernam ludum clientibus mittit.
Servo mittit non statum plenum, sed statum eliquatum cum entibus quae prope ludio ludius sita sunt. Hoc autem facit propter tria. Primo, status perfectus nimis magna frequentia transferri potest. Secundo, clientes sunt maxime interested in notitia visualium et audio, quia maxime simulatur logica lusus servo in ludo. Tertio in ludis scaenicis non indiget certa notitia cognoscendi, verbi gratia, positio inimicum in altera parte chartae, alioquin olfacere potest, et scire exacte ubi eum moveat.
Serialization
Primus gradus est notitias convertere quas volumus mittere (input vel statum ludum) in formam tradendi aptam. Hic processus dicitur .
Cogitatio statim in mentem venit uti forma lectibili humano, ut JSON vel XML. Sed hoc omnino inefficax erit, et alveum maxime dissipabit.
Commendatur uti forma binaria potius, quae multo magis compacta est. Hoc est, paucas bytes tantum continebunt. Difficultas hic considerare quae diversis computatoribus differunt.
Ad datam serialize, bibliothecam uti potes, exempli gratia:
- Sandstorm comitatu
- Shane Grant et Ranulphus Voorhees
Modo fac bibliothecam archivum portatilem et curas de endianness creat.
Vel solutio est ut ipsum efficias, non valde difficile est, praesertim si accessum ad codicem tuum centrico uteris. Praeterea optimizations quae non semper fieri possunt cum bibliotheca utendo tibi praestabit.
Glenn Fiedler duos articulos de serialization scripsit: ΠΈ .
pressio
Datae copiae inter clientes et ministratores translatae per Sedem canalis concluditur. Compressio data tibi permittit ut plures notitias in singulis snapshots transferas, frequentiam renovationis auge, vel solum exigentias canalis minuere.
Bit packaging
Ars prima est fascia freni. Constat prorsus utendo numero frumentorum quae necessaria sunt ad valorem desideratum describendum. Exempli gratia, si enum haberes qui 16 valores diversos habere potest, pro toto byte (8 bits), uti potes tantum 4 frusta.
Glenn Fiedler explicat quomodo hoc efficiendum in secunda parte articuli .
Bit sarcina opera maxime bene cum sampling, quod erit locus sequentis sectionis.
Sampling
Est ars pressio damnosa quae utitur tantum copia valorum possibilium ad valorem encode. Facillima via ad discretizationem deducendi est per numeros punctum rotundum fluctuans.
Glenn Fiedler (iterum!) ostendit quomodo sampling ad praxim in suo articulo ponatur .
Compressio algorithms
Altera ars pressionis algorithms iactura erit.
Hic, ut mea fert opinio, tres algorithmarum maxime interesting quas scire debes:
- cum codice prae-computato, qui valde celeriter est et bonos fructus producere potest. Solebat comprimi fasciculas in Quake3 networking machinam.
- Est algorithmus generalis-propositum compressionis quae numquam quantitatem datae auget. Quomodo tu vides? adhibitus in variis applicationibus. Redundare potest pro adaequationis civitatibus. Sed utile esse potest si bona, texta vel loca longa clientibus e servo mittere debes.
- - Probabiliter haec pressio simplicissima algorithmus est, sed efficax est ad certa genera notitiarum, et adhiberi potest ut antecedens gradus ante zlib. Maxime convenit ad com- pressionem locorum ex tegulis vel voxels in quibus multa elementa adjacentia repetuntur.
Delta compressionem
Ultima compressionis ars est della compressione. Consistit in eo quod solae differentiae inter statum hodiernum et statum ultimum clientem acceptum transmittuntur.
Primum in machina retis Quake3 usus est. Hic sunt duo articuli explicandi quomodo utatur;
- Brian Hook
- Fabien Sanglars [ articulos on HabrΓ©, sectio "exemplar Network"]
Quo etiam usus est Glenn Fiedler in secunda parte sui articuli .
encryption
Insuper notitiarum translationem inter clientes et servitorem encryptare debes. Huius rei plures sunt rationes;
- secreto/secreto: nuntia tantum ab ipso recipiente legi possunt, et nulla alia persona retis olfacere poterit eas legere.
- authenticas: qui histrionis partes agere vult, clavem suam cognoscere debet.
- Pseudolo praeventionis: Multo difficilius erit malignis scaenicis suos fasciculos fraudatos creare, debebunt schema encryption effingere et clavem invenire (quae cum singulis connexionibus mutantur).
Valde suadeo utens bibliothecae ad hanc rem. Moneo utens quia praecipue simplex est et optimas habet tutorias. Maxime interesting est consequat on quae dat tibi novas claves cum quolibet nexu novo generare.
Applicationem Protocollum: conclusio
Hoc concludit applicationem protocolli nostri. Compressionem credo omnino libitum esse et consilium uti solum in ludo et banda inquisita dependet. Encryption, ut mea fert opinio, facienda est, sed primo prototypo carere potes.
Applicationem logicam
Nunc in clientelam statum renovare possumus, sed in quaestiones late patentes decurrere possunt. Lusor, peracta inputatione, exspectandum est ludum statum ut update a servo videndum quid labefactum in mundo habuit.
Praeterea, inter duas res publicas updates, mundus est omnino stabilis. Si status renovationis status gravis est, motus valde hilares erunt.
Plures sunt artes ad ictum huius problematis reducere, easque in sequenti sectione contegam.
Latency politioris Techniques
Omnes artes in hac sectione descriptae in serie singillatim discutiuntur Gabrielis Gambetta. Hanc optimam capitulorum seriem valde commendamus. Etiam demo interactive includit quod permittit videre quomodo hae artes in usu operantur.
Prima ars est initus effectus directe applicare non expectato responsionem a servo. Dicitur clientis parte forecasting. Tamen, cum cliens condicionem accipit a servo, verificandum est eius vaticinium verum esse. Si autem hoc non sit, iustus debet mutare statum suum secundum id quod accepit a servo, quia servo imperiosus est. Haec ars primus usus est in Quake. Plura de eo legere potes in articulo Fabien Sanglars [ on HabrΓ©].
Secunda technicae artis institutio ad motum aliarum rerum inter duas status updates lenire solebat. Dupliciter solvit hanc quaestionem: interpolationem et extrapolationem. In interpolationis casu duo ultimi status sumuntur et transitus ab uno ad alterum ostenditur. Incommodum est quod parvam moram facit, quia semper videt id quod antea factum est. Extrapolatio est de praenuntiatione ubi entia nunc fundantur in ultimo statu a cliente recepto. Incommodum est quod, si ens totaliter directionem motus mutaverit, magnus error erit inter praesagium et situm actualem.
Aliquam, ars antecedens utilis tantum in FPS est TARDO ultricies. Cum pigra recompensatio utens, servi ratio clientis moras accipit cum in scopo iaculatur. Exempli causa, si histrio chirographum suum in velo suo faciebat, re vera scopum suum in alio loco morae exstitit, tum iniquum esset negare lusorem ius occidendi propter moras. Ideo ministrans rewinds tempus remittit ad momentum scaenicus accensus ad simulandum quod lusor in tegumentum suum videbat et de conflictu inter iacula eorum et scopum sistebat.
Glenn Fiedler (ut semper!) scripsit articulum anno 2004 in quibus fundamentum posuit simulationum physicarum synchronorum inter servitorem et clientem. Anno 2014 novam articulorum seriem scripsit quae alias artes ad simulationes physicas synchronisndas descripsit.
Sunt etiam duo vasa in wiki valvae; ΠΈ quae moras emenda.
Ne fraudantes
Duae sunt artes principales ad fallendum prohibendum.
Primum: difficiliorem reddens cheaters malitiosorum facis. Ut supra, encryption bene efficiendum est.
Secundo: servitor auctoritatis auctoritatis tantum mandata/input/actiones recipere debet. Cliens rempublicam mutare non poterit in servo praeter input mittendo. Quotiescumque autem servo inputationem acceperit, considerare debet an valeat antequam eo utatur.
Applicationem logicam: conclusionem
Commendo te deducendi viam ad latencias altas simulandi et rates refice humiles ut mores ludi tui in condicionibus egentibus probare possis, etiam cum client et cultor in eodem computatro currunt. Vehementer hoc simpliciorem redderet exsecutionem technicae morae delenimenta.
Aliae Resources utiles
Si alias facultates in retis exemplaribus explorare velis, eas hic reperire potes.
- β eius totum blog lectu dignum est, multae ibi vasa magna sunt. Articuli omnes in retis technologiae colliguntur.
- by M. Fatih MAR est index comprehensivus articulorum et videos in machinarum venationibus online.
- Π Multi etiam sunt utiles nexus.
Source: www.habr.com