Dedicated Server API Client Communication

[reaby]

SO many thanks

[oliverde8]

I had to do it for testing so why should you do the same job again? And as I know the changes I made, it's easier for me to find possible issues. ^^

Hey, I saw that you replaced the \Maniaplanet\DedicatedServer\Structures\Player classes by \ManiaLive\Data\Player class
But this class doesen't exist neither in the original Manialive repo nor in yours. So I suppose you forget to push something?

Edit didn't saw your other branch in it

[Jojo_44]

The interrupts coming frome line 264 in the GbxRemote.php:

Code: Select all

		$data = '';
		while(strlen($data) < $size)
		{
			$buf = fread($this->socket, $size - strlen($data));
			if($buf === '' || $buf === false)
				return false;
			$data .= $buf;
		}

Since you have a non-blocking fread it can happen that it trys to read something from the stream when no bytes are available. But you return false in that case(line 264 first if case). I don´t know why you have a if there anyway but I think you should remove the if(line 264/265).

Btw it would be nice if you can update the composer json because the current one is pointing to the original dedicated library because of the fork you did I guess.

Jojo

[The_Big_Boo]

Since you have a non-blocking fread it can happen that it trys to read something from the stream when no bytes are available. But you return false in that case(line 264 first if case). I don´t know why you have a if there anyway but I think you should remove the if(line 264/265).

It's actually a blocking fread: it returns false when it times out, which is after 5s by default but can be configured. I don't think a server controller can afford waiting minutes... 5s without a single byte when you're waiting for an immediate answer is not that short.

Btw it would be nice if you can update the composer json because the current one is pointing to the original dedicated library because of the fork you did I guess.

The goal is still to merge my fork back in the original.

[Jojo_44]

Since you have a non-blocking fread it can happen that it trys to read something from the stream when no bytes are available. But you return false in that case(line 264 first if case). I don´t know why you have a if there anyway but I think you should remove the if(line 264/265).

It's actually a blocking fread: it returns false when it times out, which is after 5s by default but can be configured. I don't think a server controller can afford waiting minutes... 5s without a single byte when you're waiting for an immediate answer is not that short.

Are you sure ? What´s the reason behind this comparison in the if statement ?

Code: Select all

$buf === ''

Jojo

[The_Big_Boo]

From stream_select documentation

The streams listed in the read array will be watched to see if characters become available for reading (more precisely, to see if a read will not block - in particular, a stream resource is also ready on end-of-file, in which case an fread() will return a zero length string).

Though fread should return false when reaching eof in our case, better safe than sorry.

[Jojo_44]

Yes so according to the log I think he´s calling GetMapList() which is the most time consuming method for the dedi server because the dedi reads the matchsettings file from the disk. After that fread gets called instantly but since GetMapList() can take 2sec to transmit all data to the client there´s a point where maybe half of the data was read but furthermore no data available(End of file). End of file means fread returns empty string and empty string means you return false what also means you throw an Exception. That´s what I think causes the interrupts but of course I´m not sure

Jojo

[The_Big_Boo]

After that fread gets called instantly but since GetMapList() can take 2sec to transmit all data to the client there´s a point where maybe half of the data was read but furthermore no data available(End of file). End of file means fread returns empty string and empty string means you return false what also means you throw an Exception.

For a stream, eof means the connection was closed. As long as the connection is alive, eof isn't supposed to be reached even if there are no data available. Moreover, the exception was thrown while trying to read the header, thus the 8 first bytes of answer, and it seems it's the most common case (maybe even the only case) of "random" interrupt exception.

Which lets these theories:
- the dedicated didn't receive the request
=> so the connection is indeed interrupted
- the dedicated didn't answer at all
=> the only reason I can think of is reaching a bit more than 2 billions requests, which is highly unlikely (though easily fixable)
- the dedicated didn't answer in time
=> was it too busy with something else?
- the response was read but not recognized
=> pretty unlikely as only the GbxRemote is using the socket and it waits for the answer immediately after sending the request
- the response was never received
=> so the connection is indeed interrupted