Socket.RpcAsync vs. Client.RpcAsync

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.

2 Likes