Hey, specialists from Nakama. I have got a game which uses socket functionality like tournaments and stuff. According to the documentation and recent forum posts that I found on the Internet there is no sense in using an http client for sending rpcs in case some of the socket functionality is already in use, because in this case it is easier to send rpcs directly from the socket rather than using the http client.
So I decided to stick with this option. Recently, I realized that now since I use the socket to which I can send messages at any rate a new question arises - how to control the order of commands? While an http client is “send a message, wait for a response, send a message” type of a guy, a socket is “send a message A, send a message B, get response from message B, send a message C, get response from message A, get response from message B” type of a guy. This makes me think that I need a queue of some sort on the client and on the server, because the order of commands matters a lot.
The question then is, do you guys have a solution for that or may be there is no need to have this kind of message control when using Nakama server?
We believe you don’t need such message control mechanism. Usually, clients have ways of reuse the connections unless it’s specified. Can you share where you saw that information?
Regardless, it should be fine to use a client for RPC even if you have a socket open unless you have a reason not to do it. Please give us a bit more information about what you’re doing, and we may be able to offer more guidance.
Sure, I will try my best to describe what is a problem I am trying to solve. I want to build a game in which a player does not get blocked every time when there is a client to server interaction. Say, I want to upgrade my sword and then equip it. I click a button that says “upgrade” and a moment later a nasty spinner appears on the screen effectively blocking an entire screen. So I wait until this spinner gets away and only after that will I be able to click “equip”.
I want to move away from this behavior, giving my players an ability to execute next command even if the previous one is still processed by the server. No spinners, no problems in this case. But this mechanics requires some mechanism that retains the order in which commands get executed, right?
At first sight, an asynchronous programming model should help compose those computations without blocking however this doesn’t reduce the latency on the client/server interaction. If there is a explicit player interaction between each individual computation, the whole procedure is pretty much synchronous by nature.
What will happen if one of those enqueue computation fails? Do you have to cancel all the others that follow, always?
You know, you are right. Indeed, it makes a lot of sense to just let those requests be ordered and executed one by one, because that is what the client expects. When it comes to the cancelling all the other requests - it is a pretty tough task Thanks for clarifying that!
Thanks for clarifying that!