Veel data sturen, beste manier?

[Verwijderd]

Ik ben bezig met een project waar een (trackmania) gameserver om de ~5 minuten een lijst met alle spelers informatie over een baan en servernaam stuurt. In deze lijst met spelers zit weer een lijst van gereden tijden. Verder heb ik door een extra class/tabel: Votes weer een hoop verwijzingen(vote heeft 3 velden, speler, baan en cijfer). Op een server kunnen wel eens 50 spelers of meer zitten(meestal zijn het er rond de 20).

Hoe stuur ik zoveel data in 1x? Wat is het meest effectieve protocol? Of moet ik het maar allemaal in een grote String pleuren om het vervolgens gewoon via een socket te versturen als rauwe data? Ik heb al wat gekeken naar XMLRPC en naar het versturen met JSON, maar ik kom er gewoon niet uit wat het beste is.

De reden dat ik het eens in de 5 minuten wil sturen en niet live is trouwens dat ik als ik het live stuur(dus iedere keer als speler joined stuurt ie speler data bijvoorbeeld, en bij iedere finish meteen de tijd) omdat ik dan een heel grote overhead krijg als je het geheel bekijkt. En ik wil het zo efficient mogelijk houden.

Alvast bedankt

EDIT: mocht het trouwens niet duidelijk zijn, alle data wordt naar 1 grote centrale server gestuurd

[ Voor 4% gewijzigd door Verwijderd op 19-03-2010 15:54 . Reden: onduidelijkheid ]

[beany]

in 1 string, in 1 transactie, gecomprimeerd(allerlei taal-platformen hebben daarvoor support of er zijn wel lib's voor te vinden).

Maar wat is er mis met realtime? De data die per keer verstuurd wordt is kleiner, dus dat gaat sneller. En heb je al bekeken hoeveel data het nou eigenlijk is? 50 spelers: 50kb ? 500kb? 5mb?

[zwippie]

Om hoeveel KB data gaat het eigenlijk (gemiddeld)?

[Verwijderd]

JSON lijkt mij minder wenselijk, omdat dit ten eerste al minder leesbaar is, en dit is javascript object notation. En ik neem aan dat je de data via php/asp ontvangt.

XMLRPC & SOAP zijn 2 die je hier uitstekend voor kunt gebruiken. Er is hier volgens mij niet echt een beste.

[zwippie]

Verwijderd schreef op vrijdag 19 maart 2010 @ 16:00:
JSON lijkt mij minder wenselijk, omdat dit ten eerste al minder leesbaar is, en dit is javascript object notation. En ik neem aan dat je de data via php/asp ontvangt.

XMLRPC & SOAP zijn 2 die je hier uitstekend voor kunt gebruiken. Er is hier volgens mij niet echt een beste.

JSON onleesbaar? Integendeel, zou ik zeggen. Met json_decode (PHP) heb je je data ook zo in een variabele, ik neem aan dat ASP ook wel zoiets heeft.

Meestal is je data als JSON object ook kleiner dan als een XML object, helemaal als je het ook nog eens in een SOAP envelope moet wrappen.

[ Voor 5% gewijzigd door zwippie op 19-03-2010 16:04 ]

[Kettrick]

zwippie schreef op vrijdag 19 maart 2010 @ 16:03:
[...]

JSON onleesbaar? Integendeel, zou ik zeggen. Met json_decode (PHP) heb je je data ook zo in een variabele, ik neem aan dat ASP ook wel zoiets heeft.

met een xml/soap parser heb je het ook zo weer in een variabele, het gaat juist om de leesbaarheid van het interface bericht. Hoe belangrijk dat is is weer een andere discussie

Meestal is je data als JSON object ook kleiner dan als een XML object, helemaal als je het ook nog eens in een SOAP envelope moet wrappen.

JSON is inderdaad wat lichter, maar dat komt vooral door de notatie . De vier regels die een gemiddelde SOAP envelope/body gebruikt zijn niet echt spannend als je met veel data bezig bent.

[Janoz]

Als het je vooral om de snelheid en besparen van bandbreedte gaat dan is het schrijven naar een raw socket natuurlijk het snelste. Ik zou het dan niet in een lange string gooien, maar in een byte array. Het nadeel daarvan komt al snel om de hoek kijken aangezien je een eigen protocolletje moet ontwikkelen om aan te geven wleke byte wat is in die stream, maar vaak is dat met fixed length velden, en variabele length velden die vooraf gegaan worden door 1 of 2 bytes met de lengte van het variabele deel ook weer zo op te lossen. Als je dat eenmaal goed op kom je bij je volgende probleem aan. Foutafhandeling.

Al met al is het nog wel een redelijke kluif om je communicatie compleet bugloos te krijgen. De vraag is dan ook of dit wel de moeite waard is. Is er daadwerkelijk al een probleem? Of vermoed je dat het misschien een probleem zou kunnen worden?

Resumerend, ik krijg op dit moment het idee dat je denkt een probleem op te gaan lossen waarvan je eigenlijk nog helemaal niet weet of deze er ook daadwerkelijk is.

[frickY]

JSON en XML zijn praktisch als het ook nog enigzins human-readable moet zijn.
Verzin in dit geval gewoon een eigen formaatje waarin je de waarden met een speciaal teken scheid, gooi het resultaat door gzip, en gooi dat via HTTP over de lijn.
Foutafhandeling laat je gewoon aan TCP over

[ Voor 10% gewijzigd door frickY op 19-03-2010 16:45 ]

[YopY]

Janoz schreef op vrijdag 19 maart 2010 @ 16:25:
Als het je vooral om de snelheid en besparen van bandbreedte gaat dan is het schrijven naar een raw socket natuurlijk het snelste. Ik zou het dan niet in een lange string gooien, maar in een byte array. Het nadeel daarvan komt al snel om de hoek kijken aangezien je een eigen protocolletje moet ontwikkelen om aan te geven wleke byte wat is in die stream, maar vaak is dat met fixed length velden, en variabele length velden die vooraf gegaan worden door 1 of 2 bytes met de lengte van het variabele deel ook weer zo op te lossen. Als je dat eenmaal goed op kom je bij je volgende probleem aan. Foutafhandeling.

Al met al is het nog wel een redelijke kluif om je communicatie compleet bugloos te krijgen. De vraag is dan ook of dit wel de moeite waard is. Is er daadwerkelijk al een probleem? Of vermoed je dat het misschien een probleem zou kunnen worden?

Resumerend, ik krijg op dit moment het idee dat je denkt een probleem op te gaan lossen waarvan je eigenlijk nog helemaal niet weet of deze er ook daadwerkelijk is.

Wat Janoz hier eigenlijk probeert te zeggen is "Premature optimization is the root of all evil". Zoals Beany ook al aangeeft, hoeveel gegevens hebben we het hier over? Hoe vaak en naar wie wordt het verstuurd? Zorg eerst dat je weet wat er verstuurd wordt, ga dan pas kijken hoe je dit het snelst en/of meest compact kunt versturen.

Het snelst is vaak een byte stream, maar zoals aangegeven, daar zit weer extra werk in met het bedenken, implementeren en onderhouden van een protocol. JSON of XML zijn goed ingeburgerde 'talen', maar daarbij heb je weer extra overhead.

[Janoz]

frickY schreef op vrijdag 19 maart 2010 @ 16:44:
JSON en XML zijn praktisch als het ook nog enigzins human-readable moet zijn.
Verzin in dit geval gewoon een eigen formaatje waarin je de waarden met een speciaal teken scheid, gooi het resultaat door gzip, en gooi dat via HTTP over de lijn.
Foutafhandeling laat je gewoon aan TCP over

Er zijn meer fouten mogelijk dan de fouten die TCP foor je fixed, vooral wanneer je een eigen protocol gebruikt (waarbij bugs in de implementatie, maar ook specificatie kunnen zitten)

[Verwijderd]

Ok, hoor al wat interessante dingen. De grootte waaraan je moet denken: 50 spelers, iedere speler qua spelergegevens ongeveer 0.5kb. Dan heb je voor iedere speler ook nog aantal tijden, ik gok zo gemiddeld een stuk of 10. Een tijd is gemiddeld 0.1kb(ook checkpoint tijden worden bijgehouden). Dus iedere speler heeft 1.5kb aan data. Dan heb je nog in totaal 1kb aan challenge informatie. Dus in totaal kom je uit op zo'n 76kb rauwe informatie. Nu ik het zo bekijk lijkt het inderdaad misschien wat weinig XD.

Het probleem met live alles sturen is dat je steeds headers hebt, uiteindelijk kan ik denk ik best wel een wat grotere server aanschaffen. Maar op 't begin heb ik nog niet zo'n grote. Dus ik wil liever niet live beginnen.

Human-readable hoeft eigenlijk absoluut niet. Dit is puur een communicatielaag, de gebruiker gaat van deze laag absoluut niks zien.

Ik doe trouwens alles in Java, maar dat moet geen probleem zijn. Het gaat uiteindelijk gebruikt worden voor een site waarop voor iedereen statistieken zijn te vinden, met 2 miljoen trackmania spelers(ok ok, niet iedereen actief) zal dat redelijk groot worden dus. Misschien wil ik later een keer de mogelijkheid aan andere ontwikkelaars geven om stats op hun site te plaatsen dmv een API. Maar dat komt allemaal later pas.

[ Voor 27% gewijzigd door Verwijderd op 19-03-2010 18:53 ]

[matthijsln]

Verwijderd schreef op vrijdag 19 maart 2010 @ 18:49:
Het probleem met live alles sturen is dat je steeds headers hebt, uiteindelijk kan ik denk ik best wel een wat grotere server aanschaffen. Maar op 't begin heb ik nog niet zo'n grote. Dus ik wil liever niet live beginnen.

Live kan prima, maar je moet natuurlijk niet voor elke update een nieuwe TCP verbinding maken of een HTTP request doen...

Verder zou dat weinig met de performance van je server te maken hebben, eerder met network roundtrips

[Confusion]

Google gebruikt hier intern Protocol Buffers voor.

[Verwijderd]

matthijsln schreef op vrijdag 19 maart 2010 @ 20:50:
[...]


Live kan prima, maar je moet natuurlijk niet voor elke update een nieuwe TCP verbinding maken of een HTTP request doen...

Verder zou dat weinig met de performance van je server te maken hebben, eerder met network roundtrips

Ok, dan wordt het live . Dan maar ipv upgraden als het kan andersom doen: downgraden als 't niet lukt.

[Hydra]

Verwijderd schreef op vrijdag 19 maart 2010 @ 18:49:
Dan heb je nog in totaal 1kb aan challenge informatie. Dus in totaal kom je uit op zo'n 76kb rauwe informatie. Nu ik het zo bekijk lijkt het inderdaad misschien wat weinig XD.

Euh, dat is helemaal niks. Een service die ik geschreven heb stuurt dagelijks 90MB aan XML een bus op. Heck, de meeste webpages zijn groter! De engelse wikipedia hoofdpagina is 300kB incluus alle scrips e.d.

[r0bert]

Gewoon je databaseserver instellen voor remote connections en optimaliseren voor véél verbindingen (of misschien kun je iets met keepalive). Niet spannender maken dan het is, simpel is het keyword.

[EDIT]

Nou ben ik wel heel erg benieuwd: ga je een eigen recordsysteem maken voor TM?

[pasz]

Confusion schreef op vrijdag 19 maart 2010 @ 20:54:
Google gebruikt hier intern Protocol Buffers voor.

Ziet er goed uit. Jammer dat er geen .NET api bestaat. Eens kijken of het geport kan worden.

[Basti504]

Nu vraag ik me af hoe dit gaat werken aangezien ik redelijk lang een trackmania server gehad heb. Moet je op de TM-server een plugin gaan installeren op de controller (ASECO, FAST) die dan de player/time/enz. data naar jou centrale server stuurt? Of werkt het op een andere manier, ben wel benieuwd hoe.

Het is wel een mooi idee.

[Verwijderd]

Basti504 schreef op zondag 11 april 2010 @ 11:47:
Nu vraag ik me af hoe dit gaat werken aangezien ik redelijk lang een trackmania server gehad heb. Moet je op de TM-server een plugin gaan installeren op de controller (ASECO, FAST) die dan de player/time/enz. data naar jou centrale server stuurt? Of werkt het op een andere manier, ben wel benieuwd hoe.

Het is wel een mooi idee.

Ja, ik schrijf voor XAseco, FAST en Aseco een plugin(probeer het natuurlijk in de standaardzip te krijgen ) en die stuurt me alle data. Verder haal ik wat extra info op van tmx en de trackmania stats servers

[Skinny]

pasz schreef op zondag 11 april 2010 @ 10:17:
[...]


Ziet er goed uit. Jammer dat er geen .NET api bestaat. Eens kijken of het geport kan worden.

Zelf gebruik ik al een tijdje protobuf-net en tot zover naar volle tevredenheid.

[edit]Wellicht mosterd na de maaltijd, maar voor de volledigheid toch even vermeld.

[ Voor 11% gewijzigd door Skinny op 01-05-2010 20:48 ]