Dedicated Server API Client Communication

[The_Big_Boo]

I just think it can get sometimes weird [...] if the Method names are differing from the official DedicatedServer Method names

this.
imo the dedi-api is an interface to the dedi and not a framework that does additional logic

Then we should:
- add all the *ToId or *Id methods
- split methods which automatically calls the *ToLogin variant when a player/login is provided, something chatSend and chatSendServeMessage were already doing (but there are lots of other cases where it's done)
- remove structures classes
- remove callVoteKick, callVoteBan, callVoteNextMap, callVoteRestartMap, writeFileFromFile and tunnelSendDataFromFile methods which doesn't exist at all in the official API

Imo, if people want to use only the "official" methods then they don't need the Connection class and should use only the Xmlrpc classes. The Connection class is here to help by providing documentation and autocompletion while coding but also by adding this additional logic when you don't want to bother with similar method names doing almost the same thing.

Thanks to additional logic, there are around 250 methods in the Connection class (excluding those which aren't making call to the dedicated, like factory and such) compared to the almost 300 from the official API. I don't understand why you're suddenly worried about differing method names while there were already tens of them that you weren't complaining about...


Edit: about unpack, whatever the time it takes, there are no other function anyway.
Edit2: and it really is 5ms in your screen, it's a dot not a comma.

[The_Big_Boo]

The second one is clearly a real interruption (eof is true) so nothing wrong on the library side.

For the first one, you can try to set a higher timeout (though 5 seconds is supposed to be enough for simple requests like the one failing here). Could you possibly include the server status with exceptions (the last StatusChanged callback values)?

[The_Big_Boo]

Actually, maybe we could try something different than the timeout for once ^^. Can you add the following after the loop in GbxRemote::write (should be line 289)

Code: Select all

fflush($this->socket);

It shouldn't be needed to explicitely flush the socket (and I'm not even sure which underlying buffer this function is flushing), but let's do it anyway just in case.

[The_Big_Boo]

Let's make another try, with the version I just pushed. Relevant changes:
- setting stream read buffer to 0 because of this comment (though it concerns non-blocking sockets and the "unexplainable problems" are not given... but why not?)
- making the requestHandle goes back to original value when overflowing (though reaching more than 2 billion calls to the dedicated is quite unlikely)

As the fflush, it probably won't make any difference but I'm now out of ideas...


Also, the exceptions will now clearly say when it's a timeout.

[The_Big_Boo]

I´ve used cdata as escaping option for the last 2 years which is a pretty cool trick I think. If you use /verbose_rpc_full it´s waaay better to read instead of the entities. Would be cool if you can change that.

I found an issue with cdata... The xmlrpc library doesn't escape the "]]>" sequence so a cdata section can be closed sooner than it should and make the whole request fails, or can even be used to inject xml in some cases.

So, I had two solutions:
- putting back 'markup' as escaping option instead of cdata
- walking through arguments to escape "]]>"

I chose first because it's obviously way faster (which is the point of using the extension in the first place) so from now, if you need to debug requests I recommend you to disable the xmlrpc extension and use the fallback xmlrpc encode/decode methods instead.