I’m using Nakama in .Net/Unity application to build a mobile application.
My question is: do Nakama.Socket.RpcAsync and Nakama.Client.RpcAsync have the same functionality? Which one is recommended to use?
I’m a game developer so I don’t know much about networks. I see that Client.RpcAsync uses HttpAdapter while Socket.RpcAsync uses SocketAdapter. I read that socket takes more time to establish connection compared to http, but once the connection is established, it uses less network traffic than http, and is much faster. I also read that in OSI model, http starts on the 7th layer while socket starts from the 5th layer. Which should mean that socket is much faster.
@codedrunk The choice between socket.RpcAsync and client.RpcAsync is not really about speed. It’s true that once the socket is established messages can be sent and received without the overhead of SSL negotiation on each request but SSL negotiation on HTTP requests is also how most of the internet works day to day so the overhead isn’t great relative to practical usage.
The choice between which to use depends on whether your game already requires a socket to be active for other features like chat, multiplayer, in-app notifications, etc. My suggestion is to start with client.RpcAsync always and consider using socket.RpcAsync when the game design will naturally take advantage of the socket for other features.
Also don’t forget to consider that an active socket connection requires heartbeats between client->server and server->client which is done automatically. This improves the time to detect the in-active socket (half-closed) but incurs a small amount of battery drain on mobile. This is true of any socket-based network connectivity.
Hope this helps.
4 Likes
Does using socket RPC increase the server load? I mean, if the socket is already being used by other real-time features and we also use the socket for RPC, does it increase the server load compared to the client RPC?
No, it should be the opposite, as @novabyte mentions this would prevent the overhead of SSL negotiation, but given that it’s such a common operation these days it’s very heavily optimized, so the difference shouldn’t be meaningful.
2 Likes
May i aks one more question about the Socket RpcAsync. does the socket RPC can help guarantee the RPC reach server is ordered?
such as Send RpcA with d1 at T1 and then Send RpcA with d2 at T2, then could we expect the sever to receive the data d1 and then receive data d2 always?
@mengxin yes, the RPC invoked within the same socket are processed in-order.
1 Like
Thanks for your quick reply!