The last few days I’ve been slowly adding support for what I call “generic RPCs” to czrpc . Lack of a better name, maybe.
It allows a client to call RPCs without knowing the server interface.
This is implemented by having the client pack the rpc data as string (the rpc name), followed by a vector of variants for parameters.
The server then checks if that RPC exists and if the vector of variants can be converted to the required parameters. If all is good, it calls the required function and returns the result as a variant.
This is of course not as efficient as using strongly typed RPCs since it adds both CPU and bandwidth overhead. Also, you won’t catch at compile time any errors you might have. Although the server will just reject any invalid calls.
There are of course some limitations. The variant class I’m using can only wrap a few types. If the RPC you want to call has some parameters or return type that can’t be converted from/to the variant type, then you can’t call that RPC as a generic RPC. The server will fail to match the parameters, and thus returns an error to the client.
Now, why do I need this feature?
Like I mentioned before, the game I’m working on (G4) needs to run a few servers, such as Database Server, Login Server, Servers for the in-game computers, Gameplay Server, etc.
With generic RPCs, I can easily control the servers during development from a dumb console application that all it does is keep track of connections to servers and send any commands I type.
Changes to the server(s) interface doesn’t require me to update any tools to control them.
What you see above…
- Two sample servers running (A chat server, and a calculator server)
- Two chat clients (One connected as Rui, the other as Bill)
- These are proper clients, and use efficient strongly typed RPCs
- At the button you see the completely generic client.
- It has a couple of internal commands to maintain a list of named connections
- It connects to both servers.
- RPC calls are done by typing “ConnectionName.RpcName Param1, Param2, …”
Need to write some more unit tests, and proper documentation.