[C++] Simple Spel server.

[xehbit]

Hallo Tweakers,

Na een lange tijd zoeken op google, en het vragen bij mensen heb ik me laten vertellen dat een spel server 2 verschillende sockets gebruikt TCP en UDP. Dat de TCP voor de 1e verbinding zorg en dat dan de UDP het op een of andere manier het over neemt. Nu ben ik het echt eventjes kwijt. Al dat ge-google en rond vragen begint me onderhand een beetje te irriteren dat ik elke keer weer een ander verhaal hoor. Want hoe zit het nu echt?

Ook kan ik niet echt makkelijk artiekelen/tutorials/source's vinden die een soort gameserver nabootst. Heeft er iemand enig idee hoe ik hier uit kan komen??

[NMe]

Err...hangt van het spel af en wat de connectie met de server precies moet doen, lijkt me? Waar hebben we het precies over en waarom wil je het weten? "Een spel" maakt niet verbinding op een vaste manier...

[xehbit]

NMe schreef op woensdag 06 oktober 2010 @ 13:54:
Err...hangt van het spel af en wat de connectie met de server precies moet doen, lijkt me? Waar hebben we het precies over en waarom wil je het weten? "Een spel" maakt niet verbinding op een vaste manier...

Ik zal even navragen hoe het precies zat, eerst met TCP en dan met UDP als ik het goed had. Momentje a.u.b.

[danslo]

TCP en UDP zijn aparte protocollen (geen sockets) en zijn los van elkaar te gebruiken. Dit lijkt me behoorlijke basiskennis en zelfs wikipedia zal voldoen om daar meer over te weten te komen.

Dat gezegd te hebben: als je hier al problemen mee hebt zie ik de toekomst somber voor je in Simpel zal het in ieder geval niet worden. Als ik je verhaal goed begrijp is dat je een bestaande server wilt gaan emuleren, daar komt nog wel meer bij kijken dan enkelweg wat netwerk kennis en (waarschijnlijk) magere kennis over C++.

[Anoniem: 289377]

Weet je het verschil tussen TCP en UDP? Misschien kun je dan zelf ook een beetje bedenken hoe het zit.

Wat ze waarschijnlijk bedoelen is dat je eerst met TCP een verbinding op zet om de administratieve rompslomp te regelen en daarna de game data met UDP verstuurd omdat TCP te veel overhead heeft (en het niet uitmaakt als er af en toe een pakketje kwijt raakt).

Maar je verhaal is compleet onduidelijk. Wat wil je nu precies bereiken?

[RobIII]

Dragon707 schreef op woensdag 06 oktober 2010 @ 13:56:
[...]

Ik zal even navragen hoe het precies zat, eerst met TCP en dan met UDP als ik het goed had. Momentje a.u.b.

Dat is één van de mogelijkheden ja. En waarschijnlijk heb je het dan over UDP hole punching of wat Kamose zegt als ik even in mijn glazen bol moet kijken.

Maar wat ik niet snap is waarom je je niet even verdiept in de materie (en dan heb ik het over TCP/UDP maar ook sockets programming in 't algemeen). Want als je die moeite even zou nemen had je ook geweten waar je (en men) over praat. Beginnen aan een dergelijk project zonder te weten waar je over babbelt is hetzelfde als van een brug af springen zonder te weten hoe diep 't water is waar je in springt

[ Voor 9% gewijzigd door RobIII op 06-10-2010 14:04 ]

[.oisyn]

Dragon707 schreef op woensdag 06 oktober 2010 @ 13:56:
[...]

Ik zal even navragen hoe het precies zat

Dat kun je wel gaan navragen, maar NMe heeft gewoon gelijk. Er is niet een vaste manier. Wat een game doet hangt af van de eisen die hij stelt aan het netwerkverkeer.

[Bozozo]

Ik denk dat Beej's guide een goed startpunt is... die is vrij duidelijk en compact. Lees in ieder geval de introductie, dan krijg je een goed beeld van de terminologie en de grote lijnen van socket communicatie.

[Ventieldopje]

Zou eerst maar eens na gaan denken als je een spel wilt schrijven wat ze van elkaar moeten weten, daarna kun je na gaan denken over hoe dat te gaan doen en dit zal helemaal af hangen van wat voor spel je wil gaan maken

[roy-t]

Ik denk dat je bedoelt dat een spel<->spelserver verbinding meestal bestaat uit zowel een TCP als UDP verbinding.

UDP is sneller, maar het is niet altijd zeker of de data aankomt, dit gebruik je voor informatie die graag snel en vaak wilt versturen maar die maar eventjes waarde heeft (bijvoorbeeld positie van de speler). Voordeel: meer pakketjes per seconden. Nadeel: in code rekening houden met missende pakketten.

TCP is langzamer (klein beetje maar) maar komt wel gegarandeerd aan. Hiermee verstuur je dus data zoals chatberichten heen en weer, dat is data die je niet meteen hoeft te hebben, maar waarvan je wel zeker wilt weten dat iedereen het krijgt. Voordeel: betrouwbaar. Nadeel: iets langzamer.


Maar goed, als je nog niet het verschil tussen TCP en UDP wist hoef je je er absoluut nog geen zorgen over te maken en kun je gewoon TCP gebruiken totdat het een bottleneck wordt of veel lag veroorzaakt. (Wat het meestal niet zal doen).

[Hydra]

Begin gewoon lekker met TCP/IP. Veel shooters en andere low-latency spellen gebruiken UDP maar dat levert je een hoop issues op (hoe je bijvoorbeeld packets die wegvallen of in de verkeerde volgorde aankomen afhandelt). Als je dit soort vragen moet stellen kun je beter eerst met een simpel TCP/IP socket servertje die je telnet invoer echo'd beginnen.

[NC83]

roy-t schreef op woensdag 06 oktober 2010 @ 22:40:
Ik denk dat je bedoelt dat een spel<->spelserver verbinding meestal bestaat uit zowel een TCP als UDP verbinding.

UDP is sneller, maar het is niet altijd zeker of de data aankomt, dit gebruik je voor informatie die graag snel en vaak wilt versturen maar die maar eventjes waarde heeft (bijvoorbeeld positie van de speler). Voordeel: meer pakketjes per seconden. Nadeel: in code rekening houden met missende pakketten.

TCP is langzamer (klein beetje maar) maar komt wel gegarandeerd aan. Hiermee verstuur je dus data zoals chatberichten heen en weer, dat is data die je niet meteen hoeft te hebben, maar waarvan je wel zeker wilt weten dat iedereen het krijgt. Voordeel: betrouwbaar. Nadeel: iets langzamer.


Maar goed, als je nog niet het verschil tussen TCP en UDP wist hoef je je er absoluut nog geen zorgen over te maken en kun je gewoon TCP gebruiken totdat het een bottleneck wordt of veel lag veroorzaakt. (Wat het meestal niet zal doen).

Dat hangt dus ook gewoon van het spel af aangezien je natuurlijk TCP over UDP kunt emuleren voor data die je zeker wil laten aan komen.

Zoals .oisyn and NME al aangeven het hangt af van het spel welke communicatie protocol owrdt gebruikt.

[Hydra]

roy-t schreef op woensdag 06 oktober 2010 @ 22:40:
Ik denk dat je bedoelt dat een spel<->spelserver verbinding meestal bestaat uit zowel een TCP als UDP verbinding.

UDP is sneller, maar het is niet altijd zeker of de data aankomt, dit gebruik je voor informatie die graag snel en vaak wilt versturen maar die maar eventjes waarde heeft (bijvoorbeeld positie van de speler). Voordeel: meer pakketjes per seconden. Nadeel: in code rekening houden met missende pakketten.

En niet te vergeten; pakketjes die in de verkeerde volgorde aankomen. QuakeWorld lostte dat op door elk UDP pakketje een sequence number mee te geven. Als je een pakketje met nummer N kreeg, en daarna een pakketje met een nummer lager dan N, dan werd dat pakketje gewoon weggegooid. Daarnaast zat er ook een resend-request mechanisme in voor pakketjes die aan 'moeten' komen. QuakeWorld gebruikte alleen UDP. Ik vind zowel TCP/IP als UDP gebruiken een beetje 'lui' eerlijk gezegd.

TCP is langzamer (klein beetje maar) maar komt wel gegarandeerd aan. Hiermee verstuur je dus data zoals chatberichten heen en weer, dat is data die je niet meteen hoeft te hebben, maar waarvan je wel zeker wilt weten dat iedereen het krijgt. Voordeel: betrouwbaar. Nadeel: iets langzamer.


Maar goed, als je nog niet het verschil tussen TCP en UDP wist hoef je je er absoluut nog geen zorgen over te maken en kun je gewoon TCP gebruiken totdat het een bottleneck wordt of veel lag veroorzaakt. (Wat het meestal niet zal doen).

Het probleem met TCP/IP is de manier waarop omgegaan wordt met missende pakketjes. Als pakket 1, 2 en 3 wel aankomen, 4 niet, en 5, 6, en 7 weer wel, dan krijg je 1 2 en 3 binnen in je applicatie, maar je TCP/IP stack gaat vragen aan de andere kant om nummer 4 te resenden en tot dat dat pakketje binnen is krijg je verder geen data binnen. En dat leidt tot vervelende lagspikes. Daarom wordt voor shooters waar latency enorm belangrijk is en of een update aankomt veel minder meestal voor UDP gekozen.

[Janoz]

Als dergelijke timingsissues een rol gaan spelen dan is de keuze tussen UDP en TCP wel het minste van je problemen. Ik vermoed dat, gezien de vraagstelling van de topicstarter, hij niet zo heel veel raad zal weten met een extrapolerende gamestate.

Verder vraag ik me af waarom je TCP zou willen emuleren over UDP. Waarom zou je de controles die al (erg efficient op een laag niveau) geïmplementeerd zijn op nieuw implementeren op een hogere laag?

[Hydra]

Janoz schreef op donderdag 07 oktober 2010 @ 10:51:
Verder vraag ik me af waarom je TCP zou willen emuleren over UDP. Waarom zou je de controles die al (erg efficient op een laag niveau) geïmplementeerd zijn op nieuw implementeren op een hogere laag?

Because it's fun Voor een FPS gameserver heb je trouwens geen volledige TCP stack nodig, er zijn een paar pakketjes (spawn en chat messages) die aan 'moeten' komen maar dat is erg simpel te regelen. Updates van entities zijn allemaal niet zo'n ramp als er een keer eentje uitvalt. Gebruik maken van zowel TCP als UDP is kwa code waarschijnlijk complexer dan een simpel Ack/resend systeem. Ik heb zo iets jaren terug een keer in Java gedaan (wie is er nu niet ooit met een 2D shooter begonnen ) en het is vrij triviaal.

Maar ik denk dat de TS (die schittert in afwezigheid) eerst maar eens moet proberen een simpele TCP server op te zetten die z'n telnet invoer echoed.

[.oisyn]

Oh kom op, het opzetten en onderhouden van een TCP verbinding is minstens zo triviaal. Het enige voordeel om geen TCP te gebruiken is omdat het weer wat firewall rules scheelt, maar daar schijnen de huidige games maling aan te hebben (waarbij je een stuk of 15 ports moet forwarden om een server te kunnen runnen)

[ Voor 5% gewijzigd door .oisyn op 07-10-2010 11:24 ]

[Hydra]

.oisyn schreef op donderdag 07 oktober 2010 @ 11:24:
Oh kom op, het opzetten en onderhouden van een TCP verbinding is minstens zo triviaal. Het enige voordeel om geen TCP te gebruiken is omdat het weer wat firewall rules scheelt, maar daar schijnen de huidige games maling aan te hebben (waarbij je een stuk of 15 ports moet forwarden om een server te kunnen runnen)

Breek me de bek niet open Ik vind dat trouwens wel een argument voor het gebruik van alleen UDP. Kijk, het maakt gewoon heel weinig uit, het is meer een kwestie van voorkeur of je voor alleen UDP of UDP + TCP gaat m.i. De TS moet in ieder geval lekker eerst met TCP beginnen

[.oisyn]

Daar kan ik het niet anders dan mee eens zijn

Overigens heb ik voor de network layer van Coronel Indoor Kartracing ook geen TCP gebruikt hoor