Page 1 of 12

Re: Dedicated Server API Client Communication

Posted: 14 Apr 2014, 10:28
by The_Big_Boo
The best that could be done is to rewrite the XML-RPC class from scratch anyway... There is too much useless or badly written code to maintain and debug it efficiently.

Re: Dedicated Server API Client Communication

Posted: 14 Apr 2014, 11:23
by Jojo_44
I have rewritten it myself already but I´ve never tested it much. However it works fine on all my pages so far.

https://github.com/Jojo44/GBXRemote

(not ready for server controllers yet though because I didn´t need it)

Jojo

Re: Dedicated Server API Client Communication

Posted: 14 Apr 2014, 12:56
by The_Big_Boo
Jojo_44 wrote:(not ready for server controllers yet though because I didn´t need it)
It can still be a good start for anyone who would like to make a version for server controllers, though adding callback support isn't straightforward and using xmlrpc could be a bad idea (because it's still experimental and not necessarily available).

Re: Dedicated Server API Client Communication

Posted: 16 Apr 2014, 02:13
by The_Big_Boo
I finally decided to do it from scratch myself, here's the repo: https://github.com/NewboO/dedicated-server-api

After a few tests (and some with ManiaControl), it was apparently working fine. However, there are important things to know:
- I removed the linux 64bits workaround for stream_select as it's seems to be fixed since PHP 5.3, though it was never confirmed
- I'm using a different method for message handles but I'm running a 32bits PHP so it may fail with a 64bits PHP
- I put some quite random values for timeouts at the moment which needs some tweaking, but they'll all be configurable anyway (no more weird multiplications)

I hope for making a pull request as soon as I'm confident it's stable enough so feel free to test it!

Re: Dedicated Server API Client Communication

Posted: 16 Apr 2014, 10:10
by Jojo_44
It looks nice and I think if you are on a shared host it´s the best way to go with atm. But you only use fsocken because on most shared website hosters plain sockets are forbidden. However for servercontrollers this doesn´t matter because they are running on full machines(or virtual). So if you compare the code:

Code: Select all

if(($mix = socket_recv($this->socket, $mixbuffer, 8, MSG_WAITALL)) === false)
        {
            throw new Exception(socket_strerror(socket_last_error()));
        }
vs

Code: Select all

while(strlen($data) < $size)
		{
			$buf = fread($this->socket, $size - strlen($data));
			if($buf === '' || $buf === false)
				throw new TransportException('Connection interrupted while reading data', TransportException::INTERRUPTED);
			$data .= $buf;
		}
I think the socket version is much cleaner. I agree with Lukas that the xmlrpc extension should be no problem if you use the library only for servercontrollers. Sure you are right if you wanna use the lib to display some infos on your hp it´s a bad idea. I would like to see maniacontrol with my socket solution + xmlrpc extension vs your solution. I think it would be interesting to see if you gain any speed improvements or not.

Another thing in my mind is to kick out xmlrpc entirely to get rid of the xml overhead. Basically all gamemodes are sending informations in json but currently you have to parse xmlrpc + json. That´s bad, I would like to see a new api version only with json. But I think Nadeo has other priorities atm.

Jojo

Re: Dedicated Server API Client Communication

Posted: 16 Apr 2014, 12:38
by The_Big_Boo
I knew this would come up :P I actually didn't make my mind yet about sockets:
- functions to use, it's not only about availability on most hosts but also behaviours on different OSes
- blocking/non-blocking, though blocking should be best
- timeout, my loop is actually countering it, which is why it's less clean but I could have written the following

Code: Select all

    $data = fread($this->socket, $size);
     if(strlen($data) < $size || $data === false)
        throw new TransportException('Connection interrupted while reading data', TransportException::INTERRUPTED);
However, supporting shared hosts is important too. Even if this library is mostly used in server controllers, it's aimed to be useful for websites too like the DedicatedManager or anything else.



About xmlrpc extension, I was actually thinking about checking if the extension is loaded to use it in priority so everyone would be happy ^^ It's obviously way faster than my solution, but I wanted a better alternative than the current one. I compared the 3 with both a small and a large request and here are the average on 1000 executions each:

Code: Select all

               | current |    mine |  xmlrpc
--------------------------------------------
decode (small) | 0.234ms | 0.052ms | 0.019ms
encode (small) | 0.035ms | 0.019ms | 0.011ms
--------------------------------------------
decode (large) | 4.117ms | 0.902ms | 0.183ms
encode (large) | 1.403ms | 0.658ms | 0.097ms
Though I cannot reach the speed of C with pure PHP, I'm still proud of the improvement compared to the current solution :)

Re: Dedicated Server API Client Communication

Posted: 16 Apr 2014, 13:25
by Jojo_44
Thanks for the comparison, very interesting to see. I think as you said if you add a check if the xmlrpc lib is available to use instead of the self written one you would have the best solution in terms of compatibility + speed. Like so:

Code: Select all

if(!extension_loaded("xmlrpc"))
        {
            // use your own xmlrpc lib
        }
        else
        {
          // use the extension
        }
Jojo