live stats gameserver, EOF stop??

[Mickman]

Ik heb een script geschreven die gegevens ophaalt van een game server, in dit geval een RTCW server.

Het gegevensophalen gaat goed, maar bij de output blijft hij eindeloos lang doorgaan, terwijl er helemaal niets meer komt.

je kunt hem proberen op http://www.vriendencafe.nl/~wolf/checkserver.php

Je ziet dan de live data van de server, maar daarna blijft het script verder gaan, terwijl hij (volgens mijn script) zou moeten stoppen bij de EOF (End Of File).
hieronder mijn code (deel daarvan)

$fp = fsockopen("udp://195.130.132.153", 27960, &$errno,
// deel weggelaten
fwrite($fp,"ÿÿÿÿgetstatus");
while (!feof($fp))
{
$tmp = fread($fp,1);
if ($tmp != "")
{
echo($tmp);
flush();
$buffer .= $tmp;
}
}
fclose($fp);

[ACM]

Maar komt er wel een EOF??
Als er een continue datastroom van je server komt kan ik me voorstellen dat die eof er nooit is?

[Mickman]

Op een gegeven moment komt er geen data meer en dan moet hij kappen. Maar hoe krijg ik dat voor elkaar.

[Mickman]

Ik neem aan dat ik op een gegeven moment alle data die ik nodig heb opgehaald heb. Dus dan kan het script stoppen, maar moet ik daarvoor nog een extra commando gebruiken om naar de server te sturen?

[ACM]

Ik ken RTCW niet, als er een of andere waarde altijd als laatste komt kan je daar natuurlijk op vergelijken en dan de boel afsluiten.

Of je eerst wat moet schrijven naar RTCW voor een EOF moet je zelf maar even uitzoeken, ze hebben er vast wel docs over?

[Soultaker]

Oh jee. De topicstarter wil gebruik maken van een netwerkprotocol, maar heeft geen idee wat UDP is. Dat kan natuurlijk niet goed gaan.

UDP is een stateless protocol, waarbij elke keer gegevens als pakketje data binnenkomen. Aangezien het protocol stateless is, wordt er nooit een verbinding gemaakt tussen de twee eindpunten (sockets) en kun je dus ook niet zien wanneer deze verbinding beëindigd is (want dat wordt 'ie helemaal niet).

De enige garantie die je hebt, is dat wanneer je gegevens binnenkrijgt, alle gegevens die je tegelijkertijd ontvangt bij hetzelfde pakketje data horen (ook in PHP, vermoed ik). Om te weten wanneer je klaar bent, moet er dus in de pakketjes data iets staan dat het einde van een transactie aangeeft. Het UDP protocol zelf biedt geen mechanisme om dat in te schatten, dus zal feof het ook niet kunnen bepalen.

Ik weet niet hoe het protocol werkt dat je gebruikt, maar er zijn verschillende mogelijke oplossingen. De simpelste is, een vaste tijd op antwoorden te wachten (een paar seconden ofzo), maar dit is vrij lomp en eigenlijk alleen goed als er geen andere mogelijkheid is. Het zou ook kunnen dat de server alle relevante informatie in een enkel pakketje stopt, in welk geval je kan stoppen zodra je data ontvangen hebt (je hebt dan dus geen while lus meer nodig). Denk er wel aan, dat je nog steeds een timeout nodig hebt, aangezien UDP het aankomen van data niet garandeerd. De derde mogelijkheid is, dat de server in de overgestuurde data aangeeft of er nog meer pakketjes volgen.


_{Literatuur:
Kurose & Ross, Computer Networking (Addison Wesley)}

[Mickman]

Je hoeft mij niet te vertellen dat UDP zo lekker betrouwbaar is. Ik leer uit dezelfde boeken als jij zo te zien .

Het gaat mij er om dat het script moet stoppen nadat alles binnen is. Je zou weleens gelijk kunnen hebben dat de server iets meestuurd waardoor ik weet dat ik moet stoppen. Dat zal ik dan ergens anders moeten uitvinden.

Ik heb weleens van een fransoos gehoord dat ik een 'non-printable string(nps)' moest meesturen aan het einde van de fwrite(). "anyway you must send 1 byte containing the number 10" dat zei hij.
dat zou ik dan in deze constructie moeten doen:
fputs($fp, "ÿÿÿÿgetstatus" + $nps);
maar dat wil ook niet werken

[Soultaker]

Op maandag 08 juli 2002 23:46 schreef Mickman het volgende:
Je hoeft mij niet te vertellen dat UDP zo lekker betrouwbaar is. Ik leer uit dezelfde boeken als jij zo te zien .

In dat geval zou je moeten wéten dat er geen zinnige implementatie van feof op een UDP stream mogelijk is.

Het gaat mij er om dat het script moet stoppen nadat alles binnen is.

Zoveel is duidelijk.

Je zou weleens gelijk kunnen hebben dat de server iets meestuurd waardoor ik weet dat ik moet stoppen. Dat zal ik dan ergens anders moeten uitvinden.

Je code lijkt nogal op het protocol dat Q3 gebruikt (logisch, natuurlijk). Volgens mij was het daar zo dat elke server een enkele reply stuurde. Bij een broadcast wachtte je dan gewoon een paar seconde op alle mogelijke replies. In het geval van een enkele, specifieke server zou je dan na de eerste reply klaar zijn (natuurlijk wel een timeout definiëren voor het geval het mis gaat).

[Mickman]

Maar dat betekent dat ik moet weten wanneer de server klaar is met z'n reply. Zou ik dan daarom aan het einde van de fwrite() een non-printable string moeten neerzetten zodat fread() ook kapt?

[Soultaker]

Op dinsdag 09 juli 2002 18:02 schreef Mickman het volgende:
Maar dat betekent dat ik moet weten wanneer de server klaar is met z'n reply. Zou ik dan daarom aan het einde van de fwrite() een non-printable string moeten neerzetten zodat fread() ook kapt?

Wat is dat toch met die non-printable string? Wat bedoel je daar ueberhaupt mee en waarom zou dat hier nuttig zijn?

Wat je moet doen, is de protocolspecificatie er op naslaan om te onderzoeken om welke van de al eerder genoemde situaties het gaat:

1. De server stuurt een enkel (of vast aantal) bericht(en).
2. De server stuurt in 'n bericht mee of er nog berichten volgen.
3. De server doet niets van dit alles.

De oplossingen liggen dan voor de hand:
1. Na een enkel bericht te hebben ontvangen, niet opnieuw gaan wachten op nieuwe berichten.
2. Alleen als er nog berichten volgen opnieuw gaan wachten.
3. Elke keer opnieuw wachten op nieuwe berichten.

In alledrie de gevallen moet je er rekening mee houden dat de server wel eens geen berichten naar je terug zou kunnen sturen. Zorg er dus voor, dat je na x seconden de operatie afbreekt, ook al heb je nog geen antwoord ontvangen.

Verder ga ik het niet voor je voorkauwen. Als je meer achtergrondinformatie wilt, moet je toch Kurose & Ross maar doorlezen (die schijn je in je bezit te hebben), dan weet je waarschijnlijk meer dan je ooit nodig hebt over netwerken en netwerkprotocollen.